PP pki type

何かに署名するプロトコルはすべてアルゴリズムを名指しする必要があり、送信者が管理するフィールドでそれを名指しすることがダウングレード攻撃の始まりとなります。BIP70は3つの値を用意していましたが、そのうち1つは仕様が書かれる何年も前から弱いと見なされていました。ブラウザは2017年1月にSHA-1証明書の排除を完了し、この支払いプロトコルは一度も更新を出しませんでした。

仕組み

状態: 歴史的。PP pki typeはPaymentRequestのフィールド2で、既定値は文字列"none"でした。2020年6月3日のバージョン0.20.0以降、Bitcoin Coreには存在しません。

3つの値が定義され、4つ目は仕様に余地が残されていたものの一度も登録されませんでした。

"none"は署名のないリクエストを意味しました。証明書フィールドは空のまま、署名フィールドも空のままで、ウォレットは金額と送金先を表示できましたが、身元は一切表示できませんでした。実際に出回ったリクエストのほとんどはまさにこれでした。

"x509+sha256"は、加盟店が署名フィールドを空白にしたメッセージ全体をシリアライズし、その結果をSHA-256でハッシュ化し、添付した証明書チェーンの最初の証明書に対応する秘密鍵でそのハッシュに署名することを意味しました。

"x509+sha1"は、SHA-256の代わりにSHA-1を使う同じ手順を意味しました。

弱い選択肢を用意していたことが興味深い点です。送信者が名指ししたアルゴリズムをそのまま受け入れる検証者は、なお受け入れる最悪のアルゴリズムと同じ強度しかありません。そのため後の設計では、メッセージから読み取るのではなく、受け入れ可能な集合を検証者側で固定します。SHA-1は2013年の時点でも弱い候補でした。総当たりより速い衝突攻撃が2005年に発表され、NISTは2013年以降、新しいデジタル署名の生成にSHA-1を認めなくなりました。認証局は2015年の終わりにSHA-1証明書の発行をやめ、Chrome 56は2017年1月にそれらを信頼しなくなり、その1か月後に完全な公開衝突が起こりました。

どこで見るか

ビットコイン自体が、送信者が名指しする署名アルゴリズムへの反例を示しており、これは覚えておく価値があります。

ビットコインのトランザクションは、検証する相手と署名アルゴリズムを交渉しません。使用されるアウトプットが問題を決着させます。Taproot以前のアウトプットはsecp256k1上のECDSAで検証され、Taprootの鍵に支払うアウトプットはBIP340に基づくSchnorrで検証されます。このルールは2021年11月のブロック709,632で有効になりました。支払う側は、破るのがより安上がりな何かを提案できません。コインを受け取った時点で選択が固定されていたからです。

この違いは、証明書ベースのレイヤーがビットコインの上にあまりにうまく乗らなかった理由を説明します。コンセンサスルールは全員に同一に適用され、協調的なアップグレードによってのみ変わりますが、アルゴリズムを名指しするフィールドは交渉であり、交渉はダウングレードされます。

ソフトウェアを書くのではなく購入先を選んでいる方にとって、役に立つ教訓は限定的ですが確かなものです。時代遅れの暗号オプションを"互換性のため"に生かし続けるプラットフォームは、利便性と安全性をどう天秤にかけるかを教えており、その判断は点検できないシステムの部分にも当てはまります。

PP pki type vs SSL署名

PP pki typeは方式を名指しし、SSL署名はそれを実行した出力でした。両者を1つとして扱うと、古いBIP70のドキュメントが紛らわしくなります。リクエストは種類を名指ししながら署名をまったく伴わないことがあり、それはまさに"none"が意味していたことだからです。現代のTLSは同じ対を保ち、署名バイトと並べてアルゴリズム識別子を記録しますが、クライアントはかつて合法だったすべての識別子をもはや受け入れません。