ドキュメント鍵生成式典

鍵生成式典

すべてを支える鍵を、私たちがどう保持するか。

M-of-N の担当者式典を、エアギャップされた部屋で、立会いと記録のもとに。意図的に退屈です。

01

そもそもなぜ式典なのか

3つの更新署名鍵 — release、security、operations — は、プロジェクトが所有する最も重大なシークレットです。そのいずれか1つが攻撃者に回復されても、他の2つが共同署名を拒むため、3署名の更新プロトコルは依然として成立します。しかし、もし3つが一度に同じ場所に揃ったことがあれば、プロトコルは崩壊します。

式典は、いかなる単一の人間、システム、施設も、3つのうち2つ以上に触れることが決してないようにするために存在します。

02

クォーラムのサイズ

  • ロール鍵の生成またはローテーション: 担当者5名中3名
  • リリースマニフェストへの署名: 各ロール鍵が各自の M-of-N のもとに個別に署名
  • 担当者交代後の再構成: 担当者5名中4名 + 立会人
  • 緊急失効(任意のロール): 上級担当者3名中2名 + 記録された正当化理由
なぜ M-of-2N ではなく M-of-N か
大きなプールに対する小さなクォーラムは紙の上ではレジリエントに見えますが、より多くの式典を誘発し — そして式典こそミスが起きる場所です。私たちは、より少なく、より慎重なイベントを最適化します。
03

出席ロール

  • 担当者(ロールごとに5名指名)。 スマートカードを保持。別々に移動。式典のためだけに集まる。
  • 立会人(1名)。 台本を読み上げる。鍵素材は持たない。担当者と並んで立会人ログに署名する。
  • オペレーター(1名)。 HSM を操作する。スマートカードは持たない。部屋の内外で監査される。
04

エアギャップ手順

式典マシンは、一度もネットワークに接続されたことのないハードウェアアテステーション済みワークステーションで、イベント間は改ざん検知バッグに封印され、カメラの前でのみ開封されます。

checklist☐ Room sweep for radios (Bluetooth, Wi-Fi, cellular, NFC)
☐ Faraday bag enclosure verified
☐ Camera rolling, room recording
☐ Officers identified — photo, smart card present, NDA signed
☐ Operator verified separately
☐ Tamper-evident bag opened on camera
☐ HSM checksum read aloud and matched against the witness log
☐ Script read aloud at each step
☐ Final hash printed and signed by all attendees
☐ Sealed tamper-evident bag, re-secured
05

立会人ログ

A4 1枚の紙に、全出席者が署名します。HSM チェックサムを収めた封印済み封筒とともに会社の金庫に保管。写真撮影し、物理的に離れた2か所へクロス公開します。

なぜ紙か
紙は電話を掛けません。紙には OTA がありません。立会人ログは、その部屋で何が起きたかについての唯一のグラウンドトゥルースであり — デジタルアーティファクトはそこから導出されます。その逆ではありません。
06

ローテーションの周期

  • Release 鍵: 12か月ごと、加えて担当者の離任時
  • Security 鍵: 12か月ごと
  • Operations 鍵: 18か月ごと
  • 中間署名鍵: 6か月ごと(完全な式典は不要 — オペレーターのみ)

前世代の鍵は、段階的なロールオーバーのため14日間有効なままです。14日後、公開レジストリで失効し、それを依然信頼するデバイスは縮退モードに入ります。

07

回復シナリオ

プロジェクトは4つの喪失パターンに備えます:

  • 担当者に連絡が取れない。 5名中3名で十分です。続行します。
  • 担当者の侵害が疑われる。 即時の緊急失効。30日以内に新担当者を採用します。
  • 施設の喪失。 地理的に離れたバックアップサイトで、同じ担当者により同じ式典を実行できます。
  • 複数の担当者の喪失。 5名中4名の再構成式典に立会人を加えます。これが失敗すれば、ロールそのものを公開アテステーションから再構築します。
実際の侵害が疑われる場合
ただちに security@lydos.ailydian.com へメールしてください。バグトラッカーのイシューは立てないでください。72時間以内に追跡識別子と、必要なら緊急失効のタイムラインを添えて応答します。