トランザクション展性

署名後のトランザクションを、署名に使用されたキーを使用せずに変更できる場合、そのトランザクションには「展性がある」ことになります。XRP Ledgerでは、署名付きトランザクションの機能性は変更できませんが、場合によっては第三者がトランザクションの署名と識別用ハッシュを変更できる 可能性があります 。

展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。

XRP Ledgerのメインネット上では、マルチ署名トランザクションのみが、必要以上の署名がある場合、または承認された署名者が必要以上の追加署名を提供する場合に、変更可能です。優れた運用セキュリティはこれらの問題から保護することができます。ガイドラインについてはマルチシグの展性の緩和対策をご覧ください。

2014年以前は、デフォルトの署名アルゴリズムであるsecp256k1曲線を使用したECDSAの特性により、単一署名トランザクションを不正に変更することができました。レガシー署名ツールとの互換性のため、2020-07-03にRequireFullyCanonicalSig Amendmentが有効になるまでは、変更可能な単一署名トランザクションを作成して提出することが可能でした。(Ed25519鍵で署名されたトランザクション(cryptographic-keys.html#署名アルゴリズム)は、この問題に対して脆弱ではありませんでした)。

背景

XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。

署名自体を除くトランザクションのすべてのフィールドに署名がなされている。
トランザクションの署名に使用されるキーペアが、そのアカウントの代理としてトランザクションを送信することが承認されている。
署名は正規であり、トランザクションの指示に一致している。

署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。

署名はトランザクションの識別用ハッシュの計算に使用されるデータの1つであるため、展性のあるトランザクションを変更すると、ハッシュ値が変わります。

代替secp256k1署名

「正規」であるためには、ECDSAアルゴリズムとsecp256k1曲線（デフォルト）を使用して作成された署名が以下の要件を満たしている必要があります。

署名が適切なDERエンコードデータである必要があります。
署名ではDERエンコードデータ外部に埋め込みバイトがあってはなりません。
署名を構成する整数はマイナスであってはならず、またsecp256k1係数以下でなければなりません。

一般に、あらゆる標準ECDSA実装ではこれらの要件が自動的に処理されます。ただしsecp256k1では、展性を防ぐにはこれらの要件では不十分です。したがってXRP Ledgerでは、同様の問題がない「完全に正規である」署名という概念を採用しています。

ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています。secp256k1係数はNと呼ばれ、すべてのsecp256k1署名の定数です。具体的にはNは値0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141です。署名(R,S)では、署名(R, N-S)（Sの位置にN-Sを使用）も有効です。

このように、 完全に 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（SとN-S）のいずれか 小さい方 を任意に選択すると決めました。トランザクションが選択された（小さな）値Sを使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは 完全に正規 であるとみなされます。

RequireFullyCanonicalSig Amendment（2020年に有効）では、すべてのトランザクションは 完全正規(fully canonical)な 署名のみを使用しなければなりません。

2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションにtfullyCanonicalSig`と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクションが有効であるために 完全正規な 署名を使用することを要求していました。RequireFullyCanonicalSig Amendmentが有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。

マルチシグの展性

マルチシグの明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。

以下のケースはすべて、トランザクション展性の問題につながる可能性があります。

トランザクションへの署名を1つ以上を削除しても、まだその定数を満たすのに十分な数の署名がある場合。第三者が署名を削除し、署名なしでトランザクションを再送信できる可能性があります。
すでに定数に達しているトランザクションに有効な署名を追加できる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
定数を維持しながら、あるトランザクションの署名を、別の有効な署名に置き換えることができる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。

権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。

マルチシグの展性の緩和対策

適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチシグでのトランザクション展性の問題を防ぐことができます。

必要な数以上の署名を収集しない。
必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
マルチシグリストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられているweightの値が、トランザクションの承認には不十分である場合にも該当する。
トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（account_txメソッドなどを使用）。
アカウントのSequence番号を監視する（account_infoメソッドなどを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
トランザクションを再度作成してマルチシグにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、Sequence番号を変更 しないでください 。
署名前にtfFullyCanonicalSigフラグが有効であることを確認する。

セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。

展性のあるトランザクションを使用した悪用

XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。

シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチシグを使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。

悪用シナリオの流れ

脆弱なシステムを悪用するプロセスは、以下のような順で進みます。

脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
承認された署名者が悪意のある、あるいは無責任な場合、その署名者の署名が含まれていないにもかかわらず追加される可能性がある場合、そのトランザクションも脆弱になる可能性があります。
システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
不正使用者は、トランザクションが確定する前にそのトランザクションがネットワークを通じて伝搬することを確認します。
不正使用者が脆弱なトランザクションの代替署名を計算します。
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
あるいは、その署名がまだトランザクションの一部でない承認された署名者は、脆弱なトランザクションの署名リストに自分の署名を追加することができます。送信者のマルチシグの設定によっては、これはトランザクションから他の署名を削除する代わりに、あるいはそれに加えて行われるかもしれません。
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
これにより、当初送信されたトランザクションと、不正使用者によって送信された改ざんバージョンが「競争」します。この2つのトランザクションが同時に記録されることはありません。いずれのトランザクションも有効ですが、Sequence番号をはじめ厳密に同一のトランザクションデータを含んでいるので、検証済みレジャーに記録できるのは常にいずれか1つになります。
ピアツーピアネットワークのサーバは、どちらが「最初に到着した」トランザクションであるか、またはどちらが元の送信者が意図したトランザクションであるかを認識できません。ネットワーク接続での遅延やその他の偶発的な事象により、バリデータはコンセンサス提案をファイナライズする時点で、いずれかのトランザクションだけを認識する結果になる可能性があります。この場合、いずれかのトランザクションが「競争に勝った」ことになります。
もし不正使用者がピアツーピアネットワークで適切に接続しているいくつかのサーバを乗っ取れば、これらのサーバがバリデータとして信頼されていなくても、非正規トランザクションを確定できる確率を高めることができます。
脆弱なシステムからのトランザクションを唯一受信したサーバを不正使用者が乗っ取った場合、不正使用者はネットワークの他の部分に配信されるバージョンを容易に制御できるようになります。
不正ユーザのトランザクションがコンセンサスに達し、検証済みレジャーに記録されます。
この時点でトランザクションは実行されており、このトランザクションを無効にすることはできません。その影響（XRPの送金など）は最終的です。本来のトランザクションは、そのSequence番号がすでに使用されているために有効ではなくなります。
XRP Ledgerでのトランザクションの影響は、本来のバージョンが実行された場合とまったく同じです。
脆弱なシステムは、予期しているトランザクションハッシュを認識せず、トランザクションが実行されなかったという誤った結論に達します。
トランザクションにLastLedgerSequenceフィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
トランザクションでLastLedgerSequenceフィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じSequence番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、確実なトランザクションの送信をご覧ください。）
脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
たとえば、XRP Ledgerで送金されていないと判断した資金についての責任を果たすため、システムで顧客の残高に返金します（または単に引き落としを行いません）。
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しいSequence、LastLedgerSequence、およびFeeパラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。