DIDの鍵が盗まれた・なくしたら｜鍵の更新とアカウント復旧に備える3つの権限

目次（タップで折りたたみ）

ある会社が、取引先に出す証明書の発行者としてDIDを使っています。ある日、DIDを管理している担当者のノートPCが盗まれました。

そのPCに入っていたのが、毎日の署名に使う鍵だけなら、被害はその用途に限られます。鍵を差し替えれば済みます。しかし、DIDの中身を書き換える鍵まで同じPCに入っていたらどうでしょう。攻撃者は鍵を自分のものに差し替え、DIDごと乗っ取れます。会社の側からは、もう取り戻せないかもしれません。

DIDを長く安全に使うには、次の3つを別々に保管します。

毎日使う鍵（利用鍵）
DIDを書き換える権限（更新権限）
乗っ取られたときに取り戻す権限（復旧権限）

そして、全部なくしたときにどうするかも、先に決めておきます。

もう一つ知っておきたいのは、DIDの取り戻し方は方式ごとに違うことです。DID（分散型識別子）の共通仕様は、すべてのDID方式（DID method）に同じ復旧の方法を用意していません。ですから、方式を選ぶときは「DIDを作れるか」では足りません。更新の鍵を失ったとき、誰が何を根拠に取り戻せるか。同時に来た操作のどちらを正とするか。ここまで確かめて選びます。

この記事で使う言葉

DID：ネット上の身分証番号のような識別子
DID Document：その番号に結び付いた公開鍵などの一覧表
リゾルバー：番号から一覧表を引く窓口
DID方式：DIDの作り方・更新のしかたを決めた個別の仕様（did:webなど）

DIDと自己主権型アイデンティティの基礎は「自己主権型アイデンティティ（SSI）とは」で解説しています。

最初に、3種類の権限を分ける

毎日のログインや署名に使う鍵で、DIDの書き換えや取り戻しまでできるようにしていると、冒頭の例のように、PCが1台盗まれただけでDIDそのものを乗っ取られます。

暗号の方式を選ぶより先に、3つの権限ごとに、誰が承認し、鍵をどこにしまうかを決めます。家にたとえるなら、毎日使う合鍵、家の造りを変える大家の権限、そして鍵を全部なくしたときの再発行の手続き、という違いです。

権限	推奨する保管・承認	侵害時の影響
利用鍵（毎日の署名・ログイン）	端末、HSM、ウォレット。用途別・短い有効期間	対象用途のなりすまし。更新権限が分離されていれば交換可能
更新権限（DIDの中身の書き換え）	管理基盤、複数者承認、次の鍵の事前準備	DID Documentの改ざん。復旧権限で上書きできる方式もある
復旧権限（取り戻し）	日常系から隔離したHSM、複数主体の閾値、時間遅延	DIDの恒久的な乗っ取りまたは喪失につながり得る

それぞれで行う操作の仕様上の名前は、後半の「実装する人向けの詳細」にまとめています。

W3C DID 1.1 Candidate Recommendationも、取り戻し専用の鍵をほかの用途に使い回さないよう勧めています。そのうえで、取り戻しと、鍵の定期的な交換（ローテーション）・失効を組み合わせることを推奨しています。

注意したいのは、どの鍵でDIDを書き換えられるかが、DID方式ごとに違うことです。DID Documentに「認証用」として載っている鍵が、書き換え用の鍵でもあるとは限りません。

定期の交換・盗まれた疑い・全部なくした、で手順を変える

鍵の変更には、性質の違う2つがあります。古い鍵を信頼できる定期の交換と、古い鍵を攻撃者が使っているかもしれない緊急の取り戻しです。1つの「鍵更新」の手順にまとめると、この2つを区別できなくなります。そこで、場面ごとに手順を分けます。

定期の交換（担当交代、署名方式の移行など）：新しい鍵を公開し、リゾルバーやキャッシュに行き渡ったのを確かめてから、古い鍵を外す。2段階で進める。
盗まれた疑い：リスクの高い用途を止め、証拠を保全する。緊急の承認で、被害の有無と影響期間を確かめる。
盗まれた：古い鍵による承認は信用しない。独立した復旧権限を使い、関連する鍵をすべて置き換える。
全部なくした：方式が許す取り戻しを行う。できなければ新しいDIDへ移り、古いDIDを信頼し続けない。
廃止：取り戻せない、組織がなくなった、などの場合。原則として元に戻さない。

もう一つ、鍵の差し替えが途中で止まったように見えるときの注意です。ここですぐに別の差し替えを送ると、差し替えが二重になり、どちらの鍵が有効か分からなくなります。そこで、同じ操作の番号で状態を問い合わせ、反映されていないと確かめてから次へ進みます。

状態ごとの細かい条件は、後半の表にまとめています。

DID方式は、取り戻し方と履歴の残り方で比べる

DIDの共通仕様（DID Core）は、作る・引く・更新する・無効にする、という操作の考え方を示しています。実際に誰が更新を許すか、順番をどう決めるか、履歴をどう残すかは、方式ごとの仕様が決めます。候補の方式は、4つの条件で比べます。更新の認可、復旧経路、履歴・順序、採用時の注意です。前半の表では、復旧経路と採用時の注意を並べます。

方式例	復旧経路	採用時の注意
`did:web`	DNS、ドメイン、ホスティング、CI/CDの復旧手順に依存	ドメイン奪取、サーバー証明書、配信キャッシュ、変更承認を自社で統制
Sidetree系	分離した復旧鍵で更新鍵とDIDの状態を置換	次の鍵の紛失、未確定の操作、復旧鍵の隔離を管理
台帳・コントラクト系	方式またはコントラクトに実装した閾値・時間遅延	手数料、チェーン再編成（reorg）、チェーン停止、アップグレード権限、プライバシーを評価
更新不能型	原則として新しいDIDを作成	長く存続する主体、鍵交換、サービス変更が必要な用途には不向き

did:web Method Specificationでは、更新はWebサーバー上のファイル（did.json）の置き換えです。ただし、書き込むときの認証・認可の仕組みは定めていません。GitやCI/CDで変更の履歴を持てても、実際に取り戻せるのは、ドメインの登録業者やホスティングの管理者です。

対してDIF Sidetree v1.0.1は、更新鍵（update key）と復旧鍵（recovery key）を分けています。次に使う鍵を、操作のたびに先に約束（コミットメント）として登録し直す仕組みです。

どちらが常に優れているわけではありません。自社が確実に守れるものを土台に選びます。

ブロックチェーンに何を載せ、何を載せないか

ブロックチェーンを使う価値があるのは、複数の主体が、特定の管理者を信頼せずに、操作の順番や改ざんの有無を確かめる必要がある場合に限られます。秘密鍵や個人情報は載せません。

チェーン上：確かめる側が共有すべき最小の状態、順番、次の鍵の約束（コミットメント）。操作内容のハッシュ、管理者変更の記録、無効化の状態も候補。
公開するがチェーンの外：DID Document、サービスの接続先、署名済みの操作内容。内容のハッシュで整合性を確かめる。
非公開で管理：秘密鍵、取り戻し用のシードや分割鍵、本人確認の資料と原本、メールアドレス、端末情報、承認記録、連絡先、事故の証拠。

1社が発行・更新・検証をすべて管理し、ドメインと監査ログを十分に守れるなら、ブロックチェーンは必須ではありません。逆に、複数の組織が共同で管理者の変更を確かめる場合でも、個人情報を公開の台帳に載せる理由にはなりません。

取り戻すとき、本人確認と鍵の操作をどう分けるか

DIDを暗号の上で取り戻す権限と、「申請者を本人と認める」という業務上の判断は別のものです。個人のDID、法人のDID、機器のDIDで、確認の方法も責任を持つ人も違います。取り戻しは、次の6つの手順で進めます。

事故の番号を発行し、対象のDID、疑いのある鍵、最後に正常だった版を記録する。
既存の鍵以外の手段で、申請者と承認者を確かめる。いつもの担当者だけでは承認できないようにする。
リスクの高い用途を一時停止し、リゾルバー、検証者（Verifier）、発行者（Issuer）など依存先へ知らせる。
新しい利用鍵・更新鍵・次の復旧鍵を作り、取り戻しの操作を一度だけ送る。
複数のリゾルバーで確定した版を突き合わせ、古い鍵による新しい署名を拒否する。
証明書（credential）、信頼レジストリ、許可リスト、サービス側のキャッシュを更新し、影響期間を監査記録に残す。

先に見たW3Cの推奨のとおり、取り戻し用の鍵はほかの用途に使い回しません。取り戻し用の鍵は、新しい鍵一式に切り替えるためだけに使います。取り戻した後に、それを毎日の鍵として使い回してはいけません。

NISTのSP 800-57 Part 1 Rev. 5も、鍵のライフサイクル管理を求めています。鍵の種類、使える期間（cryptoperiod）、盗まれたときの対応を含むものです。

過去の署名を後から確かめるには

今のDID Documentだけを見て過去の署名を確かめると、困ることがあります。削除された鍵が、署名した時点では有効だったのか。それとも盗まれた後に、日付をさかのぼって偽装されたのか。この区別がつきません。

過去の署名を後から確かめたいなら、署名した時点の「DIDの版」と「時刻の証明」を、署名と一緒に保存しておきます。

選んだ方式やリゾルバーが過去の版を引けない場合は、DIDだけで長期の検証を成り立たせようとしません。署名時刻のサービス、監査用の保管庫、有効期間の短い証明書など、別の仕組みを組み合わせます。保存する項目の名前は後半にまとめています。

本番の前に、何を見張り、何を練習するか

見張りと取り戻しの練習を、本番に出す条件にします。

DID Documentの版、鍵ID、管理者、サービスの変化を見張り、予定外の変更を知らせる。
リゾルバーごとの版の食い違い、更新が確定するまでの時間、キャッシュの最大経過時間、操作の失敗率を測る。
復旧鍵は、あるかどうかだけでなく、隔離した環境で実際に署名できるかを定期的に練習する。
更新操作のタイムアウト、順番の逆転、二重送信、古い更新鍵での競合を試す。
全部の鍵の喪失、取り戻し担当者の不在、ドメイン登録業者の侵害、台帳の停止を机上で練習する。

合格の条件は「APIが200を返した」ではありません。次のことまで確かめます。

新しい版が決めた時間内に、複数のリゾルバーへ行き渡る
古い鍵が拒否され、依存するシステムが同じ版にそろう
監査記録から、誰が何を承認したかを追える

同じDIDを使い続けられるかを、どう判断するか

同じDIDを長く使い続けられるのは、次の条件がそろう場合です。

更新の鍵と取り戻しの権限を分けられる
それぞれの秘密を、別々の障害が及ばない場所で守れる
方式の競合のルールと過去の版の引き方を、要件に合わせて確かめられる

取り戻しの権限を守れない。方式が更新できない。過去の版を必要な期間だけ確かめられない。こうした場合は、新しいDIDへ移ることと、業務上の結び付け直しを最初から設計に入れておきます。

DID/VC全体の信頼モデル、個人データの置き場所、証明書の失効・再発行は「DID・VCの導入設計」で整理しています。従業員の端末紛失や退職に伴うウォレット側の運用は「企業向け証明書ウォレットの運用設計」、証明書の失効を検証者へ届ける仕組みは「VCの失効設計」を参照してください。

実装する人向けの詳細

ここからは、DIDの更新と取り戻しの仕組みを作る担当者向けに、仕様上の名前と状態の条件をまとめます。

3種類の権限と、仕様上の主な操作

利用鍵：authentication（認証）、assertion（主張への署名）、key agreement（鍵共有）
更新権限：検証用の鍵（verification method）やサービスの追加・削除
復旧権限：更新権限の再設定、侵害鍵の一括置換、DIDの無効化（deactivate）

W3C DID 1.1は、復旧専用の暗号素材を他用途に再利用しないことを推奨しています。一方、どの鍵がDIDの操作を認可するかはDID方式ごとに異なり、DID Documentのauthenticationにある鍵が当然に更新鍵であるとは限りません。

鍵管理の状態と遷移

開始状態	事象	許可する操作	検証者の扱い	完了条件
通常（`ACTIVE`）	定期更新、担当交代、署名アルゴリズムの移行	新鍵追加→伝播確認→旧鍵削除	重複期間は鍵IDと用途で判定	複数のリゾルバーで新しい版を観測
侵害の疑い（`SUSPECTED`）	侵害の疑い	高リスク用途の停止、証跡保全、緊急承認	対象用途を停止するか追加審査に回す	侵害の有無と影響期間を確定
侵害（`COMPROMISED`）	利用鍵・更新鍵の侵害	復旧権限で関連する鍵をすべて置換し、旧鍵を削除	更新時点以後の旧鍵による署名を拒否	新しい版の反映、通知、依存システムの更新
管理不能（`CONTROL_LOST`）	端末・更新鍵をすべて喪失	方式が許す復旧、または新しいDIDへ移行	復旧できないなら旧DIDを信頼し続けない	新しい管理者（controller）との結び付きを検証
無効化（`DEACTIVATED`）	廃止、復旧不能、組織の終了	原則として再有効化しない	新しい署名を拒否	後継の識別子と業務記録を更新

操作がタイムアウトした場合は、同じ操作ID・同じ内容で状態を照会し、未反映と確認できるまで別の鍵変更を送らないようにします。

方式ごとの更新の認可と履歴

DID Coreはcreate、resolve、update、deactivateの考え方を示しますが、実際の認可・順序・履歴は方式ごとの仕様が決めます。

方式例	更新の認可	履歴・順序
`did:web`	Web公開基盤の権限で`did.json`を更新	仕様は版の履歴を保証しない
Sidetree系	次の更新鍵へのコミットメント	アンカー（台帳への記録）の論理順と操作の系譜
台帳・コントラクト系	トランザクション署名、管理用コントラクト、ガバナンス	台帳上の順序とファイナリティ（取引が覆らなくなる確定）
更新不能型	更新操作なし	識別子自体は固定

過去の署名の検証に保存する項目

長期の検証が必要なら、署名とともにDID DocumentのversionIdまたはversionTime、信頼できる署名時刻、当時のDID Documentまたは再解決できる履歴を保存します。

W3C DID 1.1は、失効済みの鍵による過去の署名を第三者を信頼せずに検証する条件として、版の情報、署名時点を確定する根拠、updatedとnextUpdateを挙げています。

XTELAができること

私たちは、DID方式の比較、利用鍵・更新権限・復旧権限の分け方と保管方式の設計、鍵更新と復旧のPoC、タイムアウトや二重送信を注入する障害試験、復旧演習の手順づくりまでを行っています。貴社が守れる信頼の起点に合わせて、同じDIDを使い続けるか、新しいDIDへの移行を前提にするかを一緒に決めます。本人確認の法的要件に関わる判断は、弁護士と連携して進めます。技術構成の検討はお問い合わせください。

参考資料

資料の確認日

仕様・資料の最終確認日は2026年9月24日です。W3C DID 1.1は、2026年9月24日時点でも2026年3月5日付の勧告候補のままです。NIST SP 800-57 Part 1の後継のRev. 6は、2026年9月24日時点で初期公開ドラフトの段階です。

記事一覧

DIDを管理するPCが盗まれ、書き換えの鍵まで入っていたらDIDごと乗っ取られる。DIDで証明書を発行する企業の担当者へ。毎日使う鍵・書き換える権限・取り戻す権限の分け方、盗難や全紛失の手順、DID方式ごとの復旧の違い、過去の署名の確かめ方を解説します。