ハッシュベース署名

ハッシュベース署名とは？

ハッシュベース署名とは、楕円曲線、整数の素因数分解、離散対数ではなく、主に暗号学的ハッシュ関数を基盤として安全性を確保するデジタル署名方式です。

秘密署名鍵の保有者は、この方式を使って、暗号資産のトランザクション、ブロックチェーン上のメッセージ、ソフトウェアアップデート、その他のデータがその鍵によって承認されたことを証明できます。

検証者は対応する公開鍵を使い、署名対象のデータが変更されていないこと、また署名が正当な署名者によって作成されたことを確認できます。

ハッシュベース署名は、耐量子デジタル署名技術の有力な方式と見なされており、暗号資産分野で特に重要です。

現在のブロックチェーン署名は一般に、十分な計算能力を持つ量子コンピューターに脅かされる可能性がある数学的問題に依存しています。

一方、ハッシュベース方式は暗号学的ハッシュ関数の安全性に依存します。量子コンピューティング環境でも、十分に大きなセキュリティパラメーターを使えば、これらの関数は引き続き利用可能だと一般に考えられています。

米国国立標準技術研究所（NIST）は、Stateless Hash-Based Digital Signature Algorithm（SLH-DSA）をFIPS 205として標準化しました。

XMSSやLMSなどのステートフル方式は、NIST Special Publication 800-208で扱われています。

ハッシュベース署名は、暗号資産のマイニングで使うハッシュ、ウォレットアドレス、トランザクション識別子、通常のメッセージハッシュとは異なります。

ハッシュを基盤とする構成要素から作られた、完全な公開鍵署名システムです。

暗号資産でデジタル署名が重要な理由

デジタル署名は、ユーザーが秘密鍵を明かさずにトランザクションを承認できるため、暗号資産に欠かせません。

ウォレットから暗号資産を送る際、通常は秘密鍵を使ってトランザクションデータに署名します。

ネットワーク参加者は、トランザクションを有効として受け入れる前に、公開情報を使って署名を検証します。

有効な署名があることで、必要な署名鍵を管理する人物がトランザクションを承認したと確認できます。

署名はトランザクションの完全性も保護します。署名対象のデータを変更すると、検証に失敗するはずです。

デジタル署名は、バリデーターのメッセージ、ガバナンス投票、スマートコントラクトの操作、クロスチェーンメッセージ、ソフトウェアのリリース、オラクルの更新、マルチシグ承認にも使われます。

Bitcoinの公開ドキュメントでは、Bitcoinネットワークの概要において、送信アドレスに関連付けられたデジタル署名によってトランザクションの真正性を保護すると説明されています。

ハッシュベース署名は、将来の量子攻撃に対する保護を強化しながら、同様の承認機能を担える可能性があります。

ハッシュベース署名の仕組み

ハッシュベース署名システムでは、まず秘密のランダム値を生成し、それを秘密署名情報の一部として使います。

署名者は暗号学的ハッシュ関数をこれらの値に適用し、対応する公開値を作成します。

メッセージに署名する際、システムはメッセージダイジェストに従って、選択された秘密値を公開するか処理します。

検証者は公開された値をハッシュし、結果が想定される公開情報と一致するか確認します。

基本的なワンタイム署名システムでは、秘密鍵ごとに安全に認証できるメッセージは1つだけです。

Merkleツリーを使うと、多数のワンタイム公開鍵を1つのコンパクトなルート値で表現できます。

Merkleツリーのルートは、メインの公開鍵として機能します。

署名にはワンタイム署名と認証パスが含まれ、ワンタイム公開鍵がコミット済みのMerkleツリーに属することを示します。

より高度なシステムでは、複数のツリー、ワンタイム署名、少数回署名、疑似乱数鍵生成、階層構造を組み合わせ、多数の署名に対応します。

暗号学的ハッシュ関数とは？

暗号学的ハッシュ関数は、ほぼあらゆる長さのデータを、固定長の出力に変換します。

出力は一般にハッシュ、ダイジェスト、またはメッセージダイジェストと呼ばれます。

安全なハッシュ関数では、出力から元の入力を復元することが困難である必要があります。

また、異なる2つの入力から同じ出力を生み出すことも困難でなければなりません。

入力がわずかに変化しても、ダイジェストは大きく異なる値になる必要があります。

暗号資産ネットワークでは、トランザクション識別子、ブロックコミットメント、Merkleツリー、Proof of Work方式、アドレス生成など、さまざまな用途にハッシュ関数を使います。

ハッシュベース署名方式は、こうした関数を公開鍵認証の基盤として利用します。

署名の安全性は、選択したハッシュ関数、パラメーターのサイズ、ドメイン分離、実装品質、鍵管理のルールに左右されます。

ハッシュベース署名とハッシュ処理の違い

トランザクションをハッシュ化することと、署名することは同じではありません。

通常、公開データのハッシュは誰でも計算できます。

デジタル署名には、正当な署名者だけが保有すべき秘密情報が必要です。

通常のメッセージハッシュはデータが変更されたことを示せますが、誰がデータを承認したかは証明できません。

ハッシュベース署名は、秘密の署名情報、公開検証データ、安全なハッシュ処理を組み合わせて認証を行います。

暗号資産システムでは、ハッシュと署名が異なるセキュリティ目的で使われるため、この違いを理解することが重要です。

ワンタイム・ハッシュベース署名

ワンタイム署名方式は、1つの秘密鍵で1つのメッセージだけに安全に署名するよう設計されています。

初期の例の一つに、Lamportワンタイム署名方式があります。

Lamport秘密鍵には多数のランダムな秘密値が含まれます。

公開鍵には、それらの秘密値のハッシュが含まれます。

メッセージダイジェストに応じて、署名で公開する秘密値が決まります。

検証者は公開された値をハッシュし、公開鍵と照合します。

大きな制約は、同じ秘密鍵で複数のメッセージに署名すると、追加の秘密情報が漏れることです。

鍵を十分に再利用すると、攻撃者が偽造署名を作成できる可能性があります。

そのため、ワンタイム署名は強力な暗号学的構成要素である一方、多数の鍵を生成・認証するシステムが必要です。

Winternitzワンタイム署名

Winternitzワンタイム署名では、基本的なLamport署名の大きな構造ではなくハッシュチェーンを使い、署名サイズを小さくします。

Winternitzパラメーターは、署名サイズと計算量のトレードオフを生みます。

パラメーターを大きくすると署名要素の数を減らせる場合がありますが、ハッシュ処理は増えます。

WOTS+はWinternitz方式を改良した構成で、XMSSやSLH-DSAなどの現代的なハッシュベースシステムで使われています。

RFC 8391のXMSS仕様では、WOTS+はXMSSおよびそのマルチツリー版の主要な構成要素とされています。

WOTS+はワンタイム署名方式であるため、多数の署名機会を管理する大規模なMerkleツリー構造の中で通常使われます。

ハッシュベース署名におけるMerkleツリー

Merkleツリーとは、複数のデータ項目を1つのルートハッシュでコミットするための、ハッシュ値のツリーです。

各リーフは、ワンタイム署名の公開鍵を表すことができます。

リーフのハッシュ値をペアにして結合・ハッシュし、親ノードを作ります。

1つのMerkleルートが残るまで、この処理を繰り返します。

Merkleルートは、ツリー内のすべてのワンタイム公開鍵に対するコンパクトなコミットメントとして機能します。

署名者が1つのリーフを使うと、署名にはMerkle認証パスが含まれます。

認証パスには、選択したリーフからルートを再構築するために必要な隣接ハッシュが含まれます。

検証者はワンタイム署名を確認し、既知のルートに到達するまでMerkleパスを計算します。

この設計により、1つの短い公開コミットメントで多数のワンタイム鍵を認証できます。

ステートフル・ハッシュベース署名

ステートフル・ハッシュベース署名では、すでに使われたワンタイム署名鍵やリーフのインデックスを署名者が記録しておく必要があります。

各署名後に、状態を確実に更新しなければなりません。

同じワンタイム鍵を再利用すると、方式の安全性が著しく損なわれる可能性があります。

そのため、バックアップ、複数端末、並列署名者、フェイルオーバーサーバー、信頼性の低いストレージを使うシステムでは、ステートフル方式の運用が困難です。

古い状態のバックアップを復元すると、すでに使用済みの署名情報を誤って再利用する場合があります。

同じ秘密鍵の複製を使う2台の署名端末が、同じインデックスを選ぶこともあります。

そのためNISTは、ステートフル方式には慎重な状態管理が必要であり、制限のない一般用途には適さないと警告しています。

署名状態を安全に保護し、確実に同期できる管理環境での利用に適しています。

ステートレス・ハッシュベース署名

ステートレス・ハッシュベース署名では、次に使うワンタイム鍵を示すカウンターを署名者が管理する必要はありません。

そのため、バックアップ、分散システム、複数の署名セッションで利用しやすくなります。

標準化された主なステートレス・ハッシュベース署名アルゴリズムはSLH-DSAです。

SLH-DSAは、NISTの耐量子暗号標準化プロセスに提出されたSPHINCS+を基にしています。

SLH-DSAは疑似乱数による選択と階層化されたハッシュツリー構造を使用し、ステートフル方式で問題となる致命的なワンタイム鍵の再利用を回避します。

ステートレス設計は運用上の安全性を高める一方、署名が大きくなり、計算量も増えます。

署名時の乱数や実装ルールが不適切に扱われると安全性が損なわれる可能性はありますが、状態の巻き戻しによってステートフル方式の鍵再利用と同じように直ちに破綻することはありません。

ステートフル署名とステートレス署名の違い

ステートフルとステートレスのハッシュベース署名の最も重要な違いは、使用済みの署名インデックスを署名者が追跡する必要があるかどうかです。

状態を完璧に管理できれば、ステートフル方式は効率的で、十分に理解された署名を実現できます。

ステートレス方式は、恒久的なカウンターの同期を必要としないため、運用上より安全です。

ステートフル方式は、署名頻度が低く、厳格な管理が可能なファームウェア署名、認証局、管理されたインフラに適する場合があります。

ステートレス方式は、分散型アプリケーション、一般的なソフトウェア、確実な状態同期が難しい環境に向く場合があります。

ブロックチェーンのバリデーターネットワークでは、分散署名、フェイルオーバー、バックアップ復旧、高頻度のメッセージ生成を考慮する必要があります。

こうした条件では、状態管理が設計上の最重要課題の一つになる可能性があります。

XMSS

XMSSはeXtended Merkle Signature Schemeの略称です。

RFC 8391として標準化され、NIST SP 800-208で承認されたステートフル・ハッシュベースのデジタル署名システムです。

XMSSはWOTS+ワンタイム署名とMerkleツリーを使って、より大規模な署名システムを構築します。

署名のたびに、ツリー内の特定のリーフを消費します。

署名者は同じリーフを2度使わないようにしなければなりません。

XMSSの安全性は、主に定義された暗号学的ハッシュ関数の性質に依存する安全性証明を基盤としており、強固な基盤を持っています。

XMSSの公開鍵は比較的小さい一方、署名は現在の暗号資産アカウントで一般的に使われる署名よりかなり大きくなります。

XMSSは、署名サイズの最小化より長期的な耐量子性が重要で、署名者の状態を安全に管理できる場合に有用です。

XMSSマルチツリー

一般にXMSSMTと表記されるXMSS Multi-Treeは、複数のXMSSツリーを階層的に構成します。

上位レベルのツリーで、下位レベルのツリーのルートに署名します。

この設計により、非常に大きなツリーを1つだけ使わずに、より多くの署名に対応できます。

また、鍵の利用期間を通じて計算をより効率的に分散できる場合があります。

下位レベルのワンタイム鍵は安全に再利用できないため、署名者は引き続き状態を追跡しなければなりません。

XMSSMTはRFC 8391およびNISTのステートフル・ハッシュベース署名に関する推奨に含まれています。

LMS

LMSはLeighton-Micali Signatureの略称です。

NISTに承認された、もう一つのステートフルなMerkleツリー署名システムです。

この方式はRFC 8554で規定されています。

LMSはLM-OTSというワンタイム署名方式を使い、多数のLM-OTS公開鍵をMerkleツリーで認証します。

XMSSと同様、LMSでも署名者はワンタイム署名インデックスの再利用を防ぐ必要があります。

その安全性は、多くの従来型公開鍵システムが使う数論的な仮定ではなく、暗号学的ハッシュ関数に基づいています。

LMSは、署名操作を一元管理できるコード署名やファームウェア認証などの用途で検討されることがよくあります。

階層署名システム

一般にHSSと呼ばれる階層署名システムは、複数のLMSツリーを階層的に組み合わせます。

最上位のLMS鍵が、下位のLMSツリーの公開鍵に署名します。

その後、下位ツリーが通常のメッセージに署名します。

この構造はより多くの署名に対応し、下位鍵のワンタイムリーフを使い切った際に鍵を交換できます。

HSSによって状態管理が不要になるわけではありません。

稼働中のLMSツリーごとに、使用済み署名インデックスを正確に追跡する必要があります。

HSSとLMSはRFC 8554で併せて標準化され、NIST SP 800-208でも承認されています。

SLH-DSA

SLH-DSAはStateless Hash-Based Digital Signature Algorithmの略称です。

NISTは2024年8月13日に最終版のFIPS 205標準を公開しました。

このアルゴリズムは、NISTの耐量子暗号標準化プロセスで評価されたSPHINCS+を基にしています。

SLH-DSAは、Merkleツリーのハイパーツリー、WOTS+、FORSと呼ばれる少数回署名の構成要素を使用します。

署名者の状態を恒久的に管理する必要がないため、XMSSやLMSよりバックアップや分散運用が容易です。

SLH-DSAは、SHA-2またはSHAKEハッシュ関数に基づく複数のパラメーターセットをサポートし、異なるセキュリティ水準と性能目標に対応します。

処理速度の速いパラメーターセットは一般に署名が大きくなり、署名サイズの小さいセットでは処理時間が長くなります。

SLH-DSAは保守的な耐量子セキュリティを提供しますが、多くの現行ブロックチェーンで使われる署名より大幅に大きな署名を生成します。

SPHINCS+とSLH-DSA

SPHINCS+は、NISTの耐量子暗号コンペティションに提出されたアルゴリズムです。

SLH-DSAは、その提出案を基に標準化された方式です。

両者は関連していますが、技術的な実装において常に完全に互換性のある名称として扱うべきではありません。

FIPS 205に準拠するとするシステムは、標準化されたSLH-DSAの要件と承認済みのパラメーターセットを実装する必要があります。

開発者は、従来のSPHINCS+実装が自動的にSLH-DSAと一致すると想定せず、正式な標準に従うべきです。

FORS

FORSはForest of Random Subsetsの略称です。

SLH-DSAで使われる少数回署名の構成要素です。

FORSはメッセージダイジェストを複数の小さなツリーからの選択に変換します。

選択された秘密値と認証パスが署名の一部になります。

FORSから得られる公開値は、その後、より大きなSLH-DSAハイパーツリーを通じて認証されます。

FORSは、単純なワンタイム鍵カウンターを管理せずに多くのメッセージへ署名できるよう、ステートレス方式を支えます。

通常の楕円曲線署名よりSLH-DSAの署名データがかなり大きくなる理由の一つです。

ハッシュベース署名が耐量子方式と見なされる理由

現在の公開鍵署名の多くは、離散対数問題や関連する数論的問題を解くことの難しさに依存しています。

十分な能力を備えた誤り耐性量子コンピューター上では、Shorの量子アルゴリズムにより、こうした問題を効率的に解ける可能性があります。

ハッシュベース署名は、同じ問題に依存していません。

その安全性は主に、原像計算困難性、第二原像計算困難性、衝突困難性、疑似乱数生成、その他のハッシュ関数の性質に結び付いています。

量子アルゴリズムによって、ハッシュ探索の実効的な安全性が低下する可能性はあります。

Groverのアルゴリズムは、特定の総当たり探索を二乗根分の時間で行える可能性があります。

十分に大きなハッシュ出力と保守的なパラメーターを使うことで、この影響に対処できます。

そのため、ハッシュベース署名は量子耐性または耐量子と呼ばれますが、数学的に攻撃が不可能とされているわけではありません。

暗号資産の署名に対する量子リスク

大規模な誤り耐性量子コンピューターは、現在の暗号資産ネットワークで使われる複数の署名アルゴリズムを脅かす可能性があります。

公開鍵情報から秘密鍵を復元できる攻撃者は、不正なトランザクションを承認できる可能性があります。

バリデーターの署名、ブリッジの署名者、マルチシグシステム、ガバナンスアカウント、長期間使われるトレジャリー鍵も標的になり得ます。

脅威は、一般的なウォレットに保管されたコインだけに限られません。

コンセンサスプロトコルやクロスチェーン通信システムも、同様の量子アルゴリズムに脆弱な署名方式に依存している場合があります。

現在、主要なブロックチェーンの鍵に対するこうした攻撃に必要な規模と誤り訂正能力を備えた量子コンピューターが実証された例はありません。

ただし、ウォレットソフトウェア、コンセンサスルール、ハードウェア端末、アプリケーション、カストディ手続き、ユーザー資産のすべてを協調して更新する必要があるため、ブロックチェーンの移行には何年もかかる可能性があります。

NISTは耐量子暗号プログラムを通じ、組織が脆弱な暗号方式を特定し、移行計画の策定を始めるよう推奨しています。

ハッシュベース署名とEthereum

Ethereumは現在、十分な能力を持つ量子コンピューターへの耐性を想定して設計された署名システムを使っていません。

コンセンサスレイヤーではBLS署名を使い、一般的な外部所有アカウントでは通常、楕円曲線署名を使います。

Ethereum Foundationの最新の耐量子ロードマップでは、leanXMSSと呼ばれるハッシュベース方式にバリデーター署名を置き換える案が検討されています。

ロードマップでは、leanXMSSを研究テーマとして扱っており、メインネットへの移行が完了したとはしていません。

ハッシュベースのバリデーター署名は、現在のBLS署名より大幅に大きいため、スケーリング上の大きな課題を伴います。

Ethereumの研究者は、多数の大きな署名をより小さな証明で検証できるよう、証明の集約を検討しています。

Ethereumの耐量子研究ポータルでは、ハッシュベース署名、暗号方式の切り替えやすさ、バリデーター認証、証明ベースの集約に関する取り組みが紹介されています。

Ethereumの最終的な変更には、研究、実装、テスト、コミュニティレビュー、プロトコルアップグレードの調整が必要です。

ハッシュベースのバリデーター署名

バリデーターは、ブロック提案、アテステーション、ファイナリティ、コンセンサスへの参加に関するメッセージへ頻繁に署名します。

後継の署名方式は、ネットワーク帯域やストレージに過剰な負担をかけず、大量のメッセージに対応する必要があります。

バリデーターがバックアップシステムを稼働させたり、別のマシンに切り替えたりする場合、ステートフル署名には追加のリスクがあります。

状態の同期が不適切だと、ワンタイム署名鍵を再利用する可能性があります。

ステートレス署名では同じ問題を避けられますが、署名が大きくなり、検証に必要な計算量も増えます。

そのため、ブロックチェーンの研究者は、ハッシュベースのバリデーター署名を実用化するため、集約、再帰的証明、専用ハードウェア、プロトコルの再設計を研究しています。

ハッシュベース署名と暗号資産ウォレット

ブロックチェーンが必要な検証ルールをサポートすれば、暗号資産ウォレットはハッシュベースの署名鍵を使ってトランザクションを承認できます。

ウォレットは適切な秘密鍵を生成し、署名を計算し、必要な状態を追跡し、互換性のあるトランザクションを構築する必要があります。

ステートフルなウォレット署名では、バックアップや複数端末の利用に大きな課題が生じます。

古いバックアップを復元したユーザーが、使用済みの署名インデックスを誤って再利用する可能性があります。

同じステートフル鍵を使うモバイルウォレットとハードウェアウォレットの間で、状態に矛盾が生じる場合もあります。

ステートレス・ハッシュベース署名はバックアップしやすい一方、トランザクションが大幅に大きくなり、処理コストも高くなる可能性があります。

ウォレットの開発者は、シード生成、鍵のローテーション、アドレス設計、ハードウェア対応、ユーザーによる復元、従来の署名システムからの移行も考慮しなければなりません。

ハッシュベース署名とスマートコントラクトウォレット

スマートコントラクトウォレットは、ブロックチェーン上のすべてのアカウントに対する基本署名ルールを変更せずに、新しい署名アルゴリズムをサポートできる場合があります。

コントラクトに、ハッシュベース公開鍵を独自に検証するロジックを組み込めます。

ユーザーがハッシュベース署名を送信し、コントラクトがプログラムされたルールに従って検証します。

この方法を使えば、ネットワーク全体の移行前に耐量子アカウントを試験できる可能性があります。

ただし、オンチェーンでの検証には多数のハッシュ処理が必要となり、ブロックスペースや実行リソースを大きく消費する場合があります。

開発者は、セキュリティ上の利点と、トランザクションコスト、コントラクトの複雑さ、サービス拒否攻撃のリスクを比較する必要があります。

将来的には、証明システムによって、より大きなハッシュベース署名が有効であることを示すコンパクトな証明をコントラクトが検証できる可能性があります。

ハッシュベース署名とアカウント抽象化

アカウント抽象化では、アカウントが単一の固定された署名アルゴリズムだけに依存せず、プログラム可能な承認ルールを使えるようになります。

抽象化されたアカウントは、従来型の署名、ハッシュベース署名、マルチシグのポリシー、または別の認証システムが生成する証明を受け入れられる可能性があります。

プロトコルレベルで耐量子署名が必須となる前に、ユーザーがアカウントの検証ロジックを更新できれば、耐量子方式への移行が容易になる可能性があります。

ただし、アカウント抽象化には、アップグレード鍵、復旧モジュール、検証コントラクトが新たな攻撃経路を生み出す可能性があるため、セキュリティ上の責任も伴います。

復旧モジュールや管理者鍵を迂回される可能性があれば、耐量子署名を使っていてもアカウントは保護されません。

ハッシュベース署名とマルチシグのセキュリティ

マルチシグでは、複数の承認済み鍵による操作の承認が必要です。

ハッシュベース署名を独立した署名方式としてマルチシグに含めることができます。

ハイブリッドポリシーでは、従来型署名とハッシュベース署名の両方を要求する場合があります。

一方の暗号方式が破られても他方が安全であれば、この方法で保護できます。

ただし、ハイブリッドシステムはトランザクションを大きくし、検証を複雑にし、復旧手順を難しくします。

すべての署名が必要なのか、どちらか一方が有効なら十分なのかを明確に定める必要があります。

フォールバックルールの設計が不適切だと、より強い署名方式の利点が失われる場合があります。

ハイブリッド署名

ハイブリッド署名は、2つ以上の暗号アルゴリズムによる署名を組み合わせます。

一方の要素に現行の楕円曲線アルゴリズムを使い、もう一方にSLH-DSAなどの耐量子方式を使う場合があります。

一方のアルゴリズムが将来破られた場合にも安全性を維持することが目的です。

NISTの耐量子暗号に関するFAQでは、データやデジタル証明書に対する二重署名方式が扱われています。

ハイブリッド方式への移行により、新しいアルゴリズムが何十年にもわたって使われた実績を得る前から、それだけに依存することを避けられます。

一方で、実装の複雑さが増し、2つの検証結果をどう組み合わせるかを定めるルールも必要です。

どちらか一方の署名が検証できればトランザクションが有効となる場合、弱い方の方式を破るだけでアカウントを攻撃できる可能性があります。

両方の署名を必須とする場合、アカウントは両システムの可用性と正しい動作に依存します。

ハッシュベース署名とブロックスペース

ハッシュベース署名は、コンパクトな楕円曲線署名よりも多くのブロックスペースを消費する場合があります。

容量や集約方法が変わらなければ、トランザクションが大きくなることで、1つのブロックに含められるユーザー操作の数が減ります。

データ量の増加は、帯域幅、ストレージ、伝播時間、過去データの同期要件も増加させる可能性があります。

すべての検証ノードが同じデータを処理するLayer 1ブロックチェーンでは、こうしたコストが特に重要です。

ゼロ知識証明や専用プロトコルによる署名集約を使えば、すべてのノードが直接検証するデータ量を減らせる場合があります。

ただし、集約自体にも追加の暗号学的仮定、証明コスト、遅延、実装の複雑さが伴います。

署名サイズ

署名サイズの大きさは、ハッシュベース署名の主な実用上の短所の一つです。

SLH-DSAの署名は、パラメーターセットによって数千バイトから数万バイトになる場合があります。

XMSSやLMSの署名も、一般的な楕円曲線署名よりかなり大きくなります。

ソフトウェアのアップデートやルート証明書など、頻度の低い用途では大きな署名を許容できる場合があります。

一方、データの1バイトごとにネットワークや手数料のコストが生じる、大量のブロックチェーントランザクションへの適用は困難です。

パラメーターを選ぶ際は、署名サイズ、署名速度、検証速度、署名可能な最大回数、セキュリティ水準のバランスを取る必要があります。

公開鍵のサイズ

ハッシュベース署名の公開鍵は、Merkleルートで多数のワンタイム鍵をコミットできるため、比較的小さくできる場合があります。

これは、すべてのワンタイム公開鍵を個別に保存する方法に比べて大きな利点です。

公開鍵を小さくしても署名のコストがなくなるわけではありません。認証パスとワンタイム署名のデータは引き続き提供する必要があります。

ブロックチェーンシステムでは、公開鍵のサイズがアカウント作成、状態の保存、トランザクションの証明データ、証明の構築に影響します。

秘密鍵のサイズ

基本的なハッシュベース秘密鍵には、多数のランダムな秘密値が含まれる場合があります。

現代的な方式では、その多くを小さなマスターシードから疑似乱数で生成するのが一般的です。

これにより保存要件を減らせる一方、シードの機密性が非常に重要になります。

マスターシードが侵害されると、そこから派生したすべてのワンタイム署名鍵が危険にさらされます。

ステートフル方式では、秘密シードと現在の署名インデックスの両方を保持しなければなりません。

最新の状態を保存せずにシードだけをバックアップすると、復元時に鍵を再利用する危険があるため注意が必要です。

署名速度

ハッシュベース署名では、多数のハッシュ計算やツリー処理が必要です。

一部のパラメーターセットは、署名サイズが大きくなる代わりに署名速度を高めるよう設計されています。

ほかのパラメーターセットでは署名サイズを抑える一方、計算量が増えます。

ステートフルシステムでは、ツリーノードや認証パスを事前計算して署名速度を高める場合があります。

事前計算によって、追加のストレージと状態管理が必要になります。

ブロックチェーンウォレットやバリデーターは、厳格な時間制限内に署名を生成できるか評価する必要があります。

検証速度

検証にも複数のハッシュ計算が必要です。

ハッシュ処理は一般に単純で、広く実装されており、ハードウェアによる高速化にも適しています。

ただし、各ブロックで大きな署名を何千件も検証すると、全体のコストは依然として大きくなる可能性があります。

攻撃者が、形式上は有効でも処理コストの高いトランザクションを大量に送信する場合があるため、ブロックチェーンは最悪時の検証負荷を考慮する必要があります。

実際の検証コストに応じて、手数料ルールやトランザクション制限を定める必要がある場合があります。

状態管理のリスク

状態管理は、XMSS、LMS、XMSSMT、HSSにおける運用上の主要リスクです。

署名者は、クラッシュや停電が起きても維持される方法で、署名処理の前または処理中に、使用済みのワンタイムインデックスをすべて記録しなければなりません。

新しい状態を保存できないまま署名を生成してしまわないよう、更新処理は不可分である必要があります。

バックアップから古いインデックスで署名できないようにしなければなりません。

高可用性システムでは、複数のマシンが同じインデックスを使わないよう調整する必要があります。

単調増加カウンターを適用したり署名状態を隔離したりするために、安全なハードウェアを使う場合があります。

NISTのステートフル方式に関する推奨では、厳格な鍵管理と状態管理が可能な環境での利用に限定されています。

サイドチャネル攻撃への対策

ハッシュベース署名は、ハッシュ関数が比較的単純で規則的な処理で実装できるため、有用な場合があります。

そのため、複雑な数論的アルゴリズムと比べ、一部のタイミング攻撃、電力解析、電磁波サイドチャネルへの耐性を高めやすい場合があります。

ただし、自動的にサイドチャネル攻撃への耐性が得られるわけではありません。

秘密情報に応じて変化する分岐、メモリアクセス、乱数生成、故障注入、鍵管理コードから、情報が漏れる可能性は残ります。

ハードウェアウォレットやバリデーターの実装では、必要に応じてレビュー済みの定時間処理技術を使わなければなりません。

乱数の要件

ハッシュベース秘密鍵やシードの生成には、安全な乱数が不可欠です。

秘密値が予測可能だと、攻撃者に署名鍵を再構築される可能性があります。

複数対象への攻撃から保護したり、決定論的な関係を隠したりするため、署名ごとの乱数を使う方式もあります。

数学的には安全なアルゴリズムであっても、乱数生成器が破損していれば安全性が損なわれます。

ウォレットは、タイムスタンプ、ユーザーが選んだフレーズ、一般的なアプリケーションの乱数関数ではなく、信頼できる暗号学的乱数源を使って鍵情報を生成すべきです。

鍵の枯渇

ステートフルなハッシュベース鍵で安全に署名できる回数には上限があります。

その上限は、選択したMerkleツリーの高さや階層によって異なります。

利用可能なワンタイム鍵をすべて使い切ったら、その鍵ペアを廃止しなければなりません。

設計上の上限を超えて鍵を使うと、鍵の再利用や無効な署名につながる可能性があります。

システムは残りの署名可能回数を監視し、上限に達する前に鍵をローテーションする必要があります。

多数のメッセージに署名するブロックチェーンバリデーターには、特に慎重な容量計画が必要です。

鍵のローテーション

鍵のローテーションとは、古い署名鍵を新しい鍵に置き換えることです。

ステートフルツリーの枯渇が近い場合、パラメーターが変更された場合、鍵が漏えいした可能性がある場合などに、ハッシュベース方式ではローテーションが必要となる場合があります。

可能であれば、古い鍵を使って新しい公開鍵を認証すべきです。

ブロックチェーンプロトコルでは、アカウント、バリデーター、ブリッジ、ガバナンスシステムが承認済みの鍵を更新する方法を定める必要があります。

移行手続きでは、攻撃者が自分の鍵を後継鍵として登録できないようにしなければなりません。

ローテーションの完了前に古い鍵を失った場合に備えて、ユーザー向けの明確な復旧手順も必要です。

長期的な検証

ハッシュベース署名は、長年にわたって検証可能である必要がある記録に役立つ場合があります。

プロトコルのリリース、過去のチェックポイント、ファームウェアイメージ、ジェネシスファイル、ガバナンス上の決定などが例として挙げられます。

長期的な検証には、署名対象のデータ、公開鍵、アルゴリズム識別子、パラメーターセット、必要なハッシュ関数を保持する必要があります。

将来、ハッシュ関数の安全性が低下した場合、タイムスタンプ、再署名、移行手続きが必要になる可能性があります。

耐量子方式だからといって、メンテナンスなしで署名が永久に安全であるという意味ではありません。

ソフトウェアリリース向けのハッシュベース署名

暗号資産ユーザーは、ウォレットアプリケーション、ノードクライアント、バリデーターソフトウェア、ファームウェア、開発者ツールをインストールすることがよくあります。

リリース署名を使うと、ダウンロードしたソフトウェアが正規の開発チームから提供され、署名後に改変されていないことをユーザーが確認できます。

ステートフルなハッシュベース署名は、この用途に適している可能性があります。ソフトウェアのリリースは、ブロックチェーンのトランザクションほど頻繁には行われないためです。

リリースチームは署名デバイスを管理し、署名インデックスを慎重に運用できます。

ポスト量子リリース署名は、将来的に従来の署名アルゴリズムが攻撃されても、長期間利用されるソフトウェアサプライチェーンを保護できる可能性があります。

ただし、ユーザーは信頼できる情報源を通じて公開鍵を検証する必要があります。

ハードウェアウォレットのファームウェアにおけるハッシュベース署名

ハードウェアウォレットには、鍵の生成、トランザクションの表示、署名の動作を制御するファームウェアがインストールされています。

悪意のあるファームウェアアップデートにより、秘密鍵が盗まれたり、誤ったトランザクション情報が表示されたりする可能性があります。

メーカーはファームウェアに署名することで、デバイスが許可されたアップデートのみを受け入れるようにできます。

ハッシュベース署名は、アップデートの頻度が限られており、量子耐性が有益となる可能性があるため、長期利用を前提としたファームウェア認証の選択肢となり得ます。

また、アップデートの仕組みでは、脆弱性のある古いファームウェアへのロールバックを防ぐ必要があります。

セキュアブート、ハードウェアの信頼の起点、バージョンカウンター、保護された公開鍵も引き続き必要です。

ブリッジとオラクルにおけるハッシュベース署名

ブリッジやオラクルは、多くの場合、委員会、運営者、分散ノードによる署名に依存しています。

これらの署名は、資産の移転を承認したり、多額の暗号資産の価値を左右する情報を報告したりする場合があります。

基盤となるアルゴリズムに脆弱性が見つかった場合、長期間使用される公開鍵が量子攻撃の標的となる可能性があります。

ハッシュベース署名は、委員会のメッセージに対して、より強いポスト量子保護を提供できる可能性があります。

ただし、署名サイズの増大や状態管理の要件により、オンチェーン検証のコストが発生する可能性があります。

スマートコントラクト、ガバナンス、経済的前提、バリデーターの閾値の設計が不適切であれば、ブリッジは依然として脆弱です。

署名アルゴリズムを置き換えても、ブリッジやオラクルに関するすべてのリスクが解消されるわけではありません。

Layer 2ネットワークにおけるハッシュベース署名

Layer 2ネットワークは、シーケンサー、証明者、バリデーター、委員会などのシステムを使って、基盤となるブロックチェーンの外部でトランザクションを処理します。

こうした参加者は、バッチ、ステートルート、データ可用性に関する声明、レイヤー間メッセージに署名する場合があります。

ハッシュベース署名は、これらのメッセージを将来の量子攻撃から保護できる可能性があります。

Layer 2では、基盤レイヤーにデータを送信する前に、多数の署名を1つの証明に集約する場合があります。

これにより、オフチェーンでポスト量子署名ポリシーを維持しながら、オンチェーン検証コストを削減できます。

設計全体のセキュリティは、証明システム、データ可用性、アップグレードキー、ブリッジコントラクト、異議申し立てルールに左右されます。

ハッシュベース署名とゼロ知識証明

ゼロ知識証明システムは、多数のハッシュベース署名の検証を圧縮するのに役立つ可能性があります。

証明者は回路内で多数の署名を検証し、検証が正しく行われたことを示す、より小さな証明を生成できます。

ブロックチェーンは、すべての署名を個別に処理する代わりに、その証明を検証します。

この方法により、ブロックスペースと検証コストを削減できます。

一方、選択した証明システムに伴う前提や実装上のリスクが加わります。

また、証明の生成速度がネットワークのタイミング要件を満たす必要があります。

Ethereumの現在のポスト量子研究では、大規模なバリデーター署名の集約にこの方法を利用することが検討されています。

暗号技術のアジリティ

暗号技術のアジリティとは、システム全体を再設計せずに、暗号アルゴリズムを置き換えたり追加したりできる能力です。

どの署名アルゴリズムも永遠に安全であるとは限らないため、ブロックチェーンでは重要です。

暗号技術に柔軟なウォレットは、複数の署名方式に対応し、認証されたアップグレードプロセスを通じて資産を移行できる可能性があります。

暗号技術に柔軟なプロトコルは、バージョン管理された公開鍵、プログラム可能なアカウント検証、アップグレード可能なコンセンサス検証を利用できます。

柔軟性によって、脆弱なアルゴリズムへ簡単にダウングレードできる経路が生まれてはなりません。

サポートするすべてのアルゴリズム、フォールバックルール、移行キーが攻撃対象領域の一部となります。

既存の暗号署名からの移行

ブロックチェーンを従来の署名からハッシュベース署名へ移行するには、新しいウォレットソフトウェアを公開するだけでは不十分です。

ネットワークは、新しい公開鍵と署名の形式を識別する方法を備える必要があります。

ノードには、更新された検証ルールが必要です。

ウォレットには、新しい鍵を生成、保管、バックアップ、ローテーションする機能が必要です。

ユーザーは、古いアカウントから保護されたアカウントへ資産を移す必要があります。

バリデーター、ブリッジ、スマートコントラクト、ガバナンスシステム、カストディポリシーのアップグレードも必要です。

休眠資産は、量子脅威が差し迫る前に所有者が移行できない可能性があるため、対応が難しい問題となります。

プロトコル設計者は、公開鍵が露出した場合、古いアカウント形式、長期間放置された資産について、緊急ルールを設ける必要があるかもしれません。

今保存し、後で攻撃する

「今保存し、後で攻撃する」という表現は通常、将来、量子コンピューターの性能が向上したときに復号するため、現在のうちに暗号化データを収集することを指します。

暗号資産の署名には、これと関連しつつも異なる懸念があります。

ブロックチェーンのデータは恒久的に公開されるため、露出した公開鍵や過去の署名が将来解析される可能性があります。

攻撃者が後から秘密鍵を発見しただけで、通常、すでに確定したトランザクションを変更することはできません。

ただし、脆弱な同じ鍵で引き続き管理されている資金を盗んだり、その鍵を信頼し続けるシステムを攻撃したりできる可能性はあります。

そのため、長期利用のトレジャリーアカウント、アドレスの再利用、バリデーターのID、ブリッジキーについては、早期の移行計画が必要です。

ハッシュベース署名のメリット

ハッシュベース署名の主なメリットは、ポスト量子署名の有力候補として強固な基盤を持つことです。

その構成は、主に広く研究されてきた暗号学的ハッシュ関数に依存しています。

Shorのアルゴリズムが脅威とする離散対数問題には依存しません。

複数の方式がNISTやIETFの正式な標準となっています。

ハッシュ演算は広く実装されており、ハードウェアでもソフトウェアでも高い性能を発揮できます。

Merkleツリーを使えば、多数のワンタイム公開鍵を1つのルートで表現できます。

ステートレス設計では、署名インデックスの再利用に伴う運用上の危険が軽減されます。

ステートフル設計は、管理された低頻度の署名環境で役立つ可能性があります。

ハッシュベース署名のデメリット

最大のデメリットは署名サイズです。

署名サイズが大きいと、暗号資産の取引手数料、ブロック伝播時間、ストレージ要件、検証に必要な帯域幅が増える可能性があります。

ステートフル方式では厳格なインデックス管理が必要で、バックアップや並列署名者が状態を再利用すると深刻な問題が生じる可能性があります。

ステートレス方式では永続的な状態管理を回避できますが、一般に必要なデータ量と計算量は増加します。

現在、既存のウォレットチップ、スマートコントラクト、ノードクライアント、ブロックチェーンプロトコルの多くは、これらのアルゴリズムに対応していません。

また、ハッシュベース署名には、現在の一部の署名システムが備えるコンパクトなネイティブ集約機能がありません。

証明を用いた集約によってこの問題の一部を解決できる可能性がありますが、別の複雑な暗号レイヤーが加わります。

ハッシュベース署名は破られないのか？

ハッシュベース署名も破られないわけではありません。

その安全性は、基盤となるハッシュ関数の強度と、構成全体が正しく実装されているかどうかに左右されます。

弱い乱数生成器を使うと、秘密の署名情報が漏えいする可能性があります。

ソフトウェアのバグにより、誤った認証パスが計算されることがあります。

状態の再利用は、ステートフル方式の安全性を損なう可能性があります。

サイドチャネル攻撃によって秘密データが漏えいする場合があります。

悪意のあるアップデートにより、検証に使われる公開鍵が置き換えられる可能性があります。

将来の暗号解読研究によって、選択したハッシュ関数やパラメーターセットの強度が低下する可能性もあります。

ポスト量子耐性が対処するのは特定の種類の攻撃であり、あらゆるセキュリティ上の不具合ではありません。

ハッシュベース署名に関するよくある誤解

よくある誤解の1つは、ブロックチェーンのハッシュがあれば、すべてのトランザクション認証にすでに量子耐性があるというものです。

トランザクションハッシュはデータを識別するものであり、支出を承認するためのデジタル署名の代わりにはなりません。

もう1つの誤解は、ハッシュ出力が小さいため、ハッシュベース署名も自動的に小さいというものです。

完全な署名には、ワンタイム署名データ、認証パス、その他の構造情報が含まれます。

3つ目の誤解は、秘密シードさえ保護すれば、ステートフル署名は安全だというものです。

現在の署名状態も完全に保護する必要があります。

4つ目の誤解は、量子耐性があればすべての攻撃を受けないというものです。

実装バグ、フィッシング、マルウェア、ガバナンスの不備、スマートコントラクトの悪用は依然として発生する可能性があります。

5つ目の誤解は、ブロックチェーンが新しい署名形式をすぐに導入できるというものです。

移行には、プロトコル、ウォレット、ハードウェア、カストディ、アプリケーション、ユーザー間の連携が必要です。

ハッシュベース署名システムのセキュリティチェックリスト

レビュー済みのアルゴリズムと、パラメーターセットが明確に特定されたものだけを使用してください。

暗号学的に安全な乱数生成器を使って秘密シードを生成してください。

安全なハードウェアや、慎重に設計された鍵管理システムでマスターシードを保護してください。

安全な状態同期設計がない限り、ステートフルな秘密鍵を2つの独立した署名者にコピーしないでください。

状態の更新をアトミックにし、停電やロールバックに耐えられるようにしてください。

XMSS、LMS、XMSSMT、HSSキーの残り署名可能数を監視してください。

攻撃者が置き換え用の公開鍵を差し替えられないよう、鍵のローテーションを認証してください。

標準で求められるとおりに、ドメイン分離を適用してください。

公式のテストベクトルと独立した実装を使って、相互運用性をテストしてください。

既存方式が安全でなくなる前に、アルゴリズム移行を計画してください。

FAQ

ハッシュベース署名とは何ですか？

ハッシュベース署名とは、主に暗号学的ハッシュ関数とハッシュツリー構成の安全性に依拠するデジタル署名です。

暗号資産にとってハッシュベース署名が重要なのはなぜですか？

ウォレット、バリデーター、ブリッジ、ガバナンスシステム、ソフトウェアリリースなどのブロックチェーンインフラに、ポスト量子認証を提供できる可能性があるためです。

ハッシュベース署名には量子耐性がありますか？

安全なハッシュ関数と十分に強いパラメーターを使用すれば、量子耐性があると考えられています。ただし、量子アルゴリズムによってブルートフォース攻撃に対する安全性の余裕が一部低下します。

SLH-DSAとは何ですか？

SLH-DSAは、NISTがFIPS 205で標準化したステートレスのハッシュベースデジタル署名アルゴリズムです。

SLH-DSAはSPHINCS+と同じですか？

SLH-DSAはSPHINCS+を基にNISTが標準化したアルゴリズムですが、以前のすべてのSPHINCS+バージョンが同一だと想定せず、実装ではFIPS 205に従う必要があります。

XMSSとは何ですか？

XMSSは、WOTS+ワンタイム署名を使用するステートフルなMerkleツリー署名システムで、使用済み署名インデックスを慎重に追跡する必要があります。

LMSとは何ですか？

LMSは、LM-OTSワンタイム署名とMerkleツリー認証を組み合わせたステートフルなハッシュベース署名方式です。

HSSとは何ですか？

HSSは、複数のLMSツリーを連結する階層型システムで、より多くの署名に対応できる鍵構造を実現します。

ステートフル署名とステートレス署名の違いは何ですか？

ステートフル署名では署名者が使用済みのワンタイム鍵を追跡する必要がありますが、ステートレス署名では永続的な署名カウンターを維持する必要がありません。

状態の再利用が危険なのはなぜですか？

ワンタイム署名鍵を再利用すると、ステートフルなハッシュベース署名方式の安全性を弱めたり、破壊したりするのに十分な秘密情報が漏えいする可能性があります。

Merkleツリー署名とは何ですか？

Merkleツリー署名は、Merkleルートを使って多数のワンタイム公開鍵をコンパクトなハッシュベース認証パスで認証します。

WOTS+とは何ですか？

WOTS+は、XMSSとSLH-DSAの構成要素として使用されるWinternitzワンタイム署名方式です。

FORSとは何ですか？

FORSはSLH-DSA内部で使用される数回利用可能な署名方式で、結果がハイパーツリーを通じて認証される前に、メッセージダイジェストへ署名します。

ハッシュベース署名は主要なブロックチェーンですでに使われていますか？

大半の主要なブロックチェーンネットワークでは、まだ一般的なトランザクション署名として使われていません。ただし、研究が活発に進められ、特定用途での導入も広がっています。

Ethereumは現在ハッシュベース署名を使っていますか？

Ethereumでは現在、標準的なバリデーター署名やユーザー署名としては使われていませんが、ポスト量子研究ロードマップでleanXMSSと証明ベースの集約が検討されています。

スマートコントラクトでハッシュベース署名を検証できますか？

スマートコントラクトに互換性のある検証ロジックを実装できますが、計算量やトランザクションデータのコストが大きくなる可能性があります。

ハッシュベース署名のサイズが大きいのはなぜですか？

メッセージの署名を公開ルートに結び付けるために、ワンタイム署名値、Merkle認証パス、その他の情報を含める必要があるためです。

ハッシュベース署名は集約できますか？

現在の一部方式のようなコンパクトなネイティブ集約機能は一般にありませんが、証明システムを使えば検証結果を集約できる可能性があります。

ハードウェアウォレットでハッシュベース署名を利用できますか？

互換性のあるファームウェア、安全な鍵保管、十分な処理能力があり、必要に応じた安全な状態管理に対応していれば、ハードウェアウォレットで利用できます。

ハッシュベース署名は暗号化に取って代わりますか？

いいえ。署名は認証と完全性を提供し、暗号化は情報の機密性を保つために設計されています。

既存の暗号資産の秘密鍵をハッシュベース鍵に変換できますか？

安全に移行するには通常、新しいハッシュベース鍵ペアを生成し、既存のアカウントまたはプロトコルのルールに従って新しい公開鍵を承認する必要があります。

ハッシュベース署名は、ほかのすべてのポスト量子方式より安全ですか？

保守的な安全性の基盤を持っていますが、安全性は性能要件、実装品質、鍵管理、パラメーター、周辺プロトコルにも左右されます。

XMSSとLMSの主なリスクは何ですか？

主な運用上のリスクは、バックアップのロールバック、並列署名、状態更新の失敗により、ワンタイム署名インデックスを誤って再利用することです。

SLH-DSAの主なリスクは何ですか？

実用上の主な制約は署名サイズの大きさと計算量ですが、実装や乱数生成の失敗もセキュリティ上の懸念となります。

量子コンピューターは暗号資産をすぐに破るのでしょうか？

現在、主要なブロックチェーンの鍵に対して必要な攻撃を実行できることが実証された量子コンピューターはありません。しかし、世界規模でのプロトコル変更には広範な準備が必要なため、移行は早期に始める必要があります。

まとめ

ハッシュベース署名は、主に暗号学的ハッシュ関数、ワンタイム署名、Merkleツリー認証を使って構築されたデジタル署名システムです。

既知の量子コンピューティング攻撃に耐えられるトランザクション認証やバリデーター認証への有力な道筋を提供するため、暗号資産分野で大きな意義があります。

XMSS、XMSSMT、LMS、HSSなどのステートフル方式は強固なセキュリティを提供できますが、消費した署名インデックスをすべて正確に追跡する必要があります。

古いバックアップを復元したり、2台のデバイスで同じステートフル鍵を使ったりすると、署名情報を誤って再利用し、鍵の安全性を大きく損なう可能性があります。

ステートレスのSLH-DSAは永続的な状態管理を不要とし、2024年8月にFIPS 205としてNISTの最終標準となりました。

一方、SLH-DSAの署名は、現在の暗号資産アカウントやバリデーターで一般的に使われる署名より大幅に大きくなります。

署名サイズが大きいと、取引手数料、ブロックスペース、帯域幅、ストレージ、同期、検証コストに影響します。

そのため、ブロックチェーン研究者はアカウント抽象化、ハイブリッド署名、ゼロ知識証明による集約、プログラム可能な検証、暗号技術のアジリティを研究しています。

Ethereumの現在のポスト量子研究には、ハッシュベースのバリデーター署名と、その検証を圧縮するための証明システムが含まれます。

ハッシュベース署名ですべての暗号資産のセキュリティ問題を解決できるわけではありません。

ウォレットのマルウェア、シードの盗難、フィッシング、スマートコントラクトのバグ、脆弱なガバナンス、安全でないブリッジ、不適切な乱数生成、実装エラーは、依然として損失につながる可能性があります。

ハッシュベース署名は完全なセキュリティソリューションではなく、強力な認証技術として理解する必要があります。

暗号資産ネットワークにとって、長期的な課題は量子耐性のある署名アルゴリズムを選ぶことだけではありません。

より大きな課題は、ネットワークのセキュリティを損なったり、利用していないユーザーを取り残したりすることなく、数十億ドル相当のアカウント、アプリケーション、バリデーターシステム、インフラを移行することです。

ハッシュベース署名は、その移行に向けた、成熟度が高く保守的に設計された基盤の1つです。