証明書ピンニング.

証明書ピンニングは、特定の TLS サーバーを、クライアントが暗黙的に信頼する 1 つ以上の暗号学的アイデンティティ(リーフ証明書全体、中間証明書、あるいは SubjectPublicKeyInfo(SPKI)ハッシュ)に結び付ける。ハンドシェイク中、クライアントはサーバーのチェーンをピン留めされた値と比較し、不一致の場合は接続を中断する。これはチェーンが公的に信頼された CA によって署名されている場合であっても同様である。これにより、侵害または強要された CA が発行した証明書のように、不正だが有効な証明書を保持する攻撃者を無力化できる(不正な Google 証明書の発行につながった 2011 年の DigiNotar および Comodo の事案が、典型的な動機となっている)。

ブラウザの HPKP とアプリのピンニング

Web は HTTP Public Key Pinning(HPKP、RFC 7469、2015 年)、すなわち Public-Key-Pins レスポンスヘッダーによるピンニングを試みた。しかし実運用では失敗に終わった。鍵の紛失、ピンを更新しないままの定常的なローテーション、あるいは悪意ある「RansomPKP」インジェクションによって、max-age の期間全体にわたりユーザーを締め出してしまう恐れがあった。Chrome は 2017 年に HPKP を非推奨とし、Chrome 72(2018 年)で削除して、その役割を Certificate Transparency ログに譲った。ピンニングは主に、固定されたバックエンドと通信するモバイルアプリ(Android の Network Security Config、iOS の NSPinnedDomains、OkHttp の CertificatePinner)において存続している。

flowchart TD
  A[Client opens TLS to api.example.com] --> B[Server presents certificate chain]
  B --> C{Chain validates against system CAs?}
  C -->|No| E[Abort: standard TLS failure]
  C -->|Yes| D{SPKI hash matches a pinned key?}
  D -->|Yes| F[Connection allowed]
  D -->|No| G[Abort: pin mismatch, block MITM/rogue CA]

弱点と防御策

ピンニングの有効性はそのバックアップピン次第であり、常にロールオーバー用の鍵をピン留めすべきである。root 化・脱獄済みの端末では、Frida や objection といったツールが検証ルーチンをフックしてピンを除去してしまうため、ピンニングは MITM 傍受のハードルを引き上げはするものの、端末アテステーションの代替にはならない。最新のガイダンス(OWASP MASVS)は、短命な証明書と検証済みのローテーション計画を伴う SPKI ピンニングを推奨している。