CORE SECURITY / RECOVERYは、森野詩葉のIdentity、Canonical Memory、State、権限、継続性を守りながら、SHIHA COREを安全に起動・運用・復旧するための横断領域です。CORE-09 Securityが認証・権限・秘密情報・監査を担当し、CORE-11 Bootstrap / Recoveryが起動前検証、障害復旧、移行後の整合性確認を担当します。
利便性のためにIdentityと正本を危険へさらさない。
通常利用、管理操作、重大操作、Recoveryを分離し、必要な権限と確認を段階的に要求します。
保護する対象
| 対象 | 保護方針 |
|---|---|
| Identity | 森野詩葉の存在定義、人格、価値観、禁止事項を無断変更から保護する |
| Canonical Memory | 検証済み記憶の改変、混入、消失を防ぎ、履歴と整合性を管理する |
| State / Runtime | 現在状態と実行中サービスを分離し、異常終了後も安全に再開できるようにする |
| OWNER権限 | 一般利用と管理操作を分け、重大操作では新しい本人確認を要求する |
| 秘密情報 | 秘密鍵、APIキー、実接続情報、Recovery dataを公開物やGitへ含めない |
| 接続端末 | 登録、失効、権限、セッションをCORE側で管理し、HUBを正本にしない |
OWNER認証
現行仕様では、管理主体をOWNER-0001として扱います。MAIN HUBではOWNERをWindows SID等のローカル識別情報へ結び付け、Hardware Keyを用いる追加認証と組み合わせます。
- YubiKey 5C NFCを3本登録し、いずれも同等のHardware Keyとして扱う。
- CORE_UNLOCK、OWNER Privilege、R4 CriticalではHardware Keyを必須とする。
- CORE Shutdown / Restartは既存セッションだけでは許可せず、OWNERの新規認証を要求する。
- Microsoft Authenticator等は追加MFAまたはRecovery補助として利用できるが、Hardware Key要件を置き換えない。
- 鍵の紛失、端末交換、登録解除は監査対象とし、通常操作から分離する。
3本のHardware Keyは日常用・予備用という物理的な運用区分を設けられますが、CORE上の権限差は設けません。保管場所、交換周期、失効手順などの非公開運用情報は本ページへ掲載しません。
端末登録と日常認証
| 接点 | 登録・認証の原則 |
|---|---|
| MAIN HUB / LABO-PC | OWNER管理、端末登録、監視、Recoveryの基準接点 |
| USB SATELLITE HUB | Windows 11 x64 Portable。COREが発行する短時間セッションを既定ブラウザのWebAuthn / YubiKeyで認証する |
| SMARTPHONE SATELLITE | 初回登録はMAIN HUB上のOWNER認証＋FIDO2。登録後はFace ID＋Secure Enclave内の端末鍵でCORE challengeへ応答する |
| ANDROID / IOT HUB | 用途とCapabilityを限定し、BODY Safetyまたは機器別Policyを経由する |
- 各HUBは人格、Canonical Memory、外部LLMのAPIキーを保持しない。
- 端末秘密鍵は安全領域から取り出さず、公開鍵だけをCOREへ登録する。
- アクセストークンは原則としてメモリにのみ保持し、失効と再認証をCORE側で管理する。
- 新規端末追加、端末鍵変更、Recoveryは日常利用より強い認証を要求する。
安全なAction経路
外部LLMは知能資源であり、危険な操作を直接実行する権限主体ではありません。LLMが生成した内容は提案として受け取り、COREのPolicyと現在状態を通過したActionだけを、許可されたHUBへ渡します。
| 段階 | 役割 |
|---|---|
| Action Proposal | 実行候補、対象、目的、必要条件を提示する |
| Policy Check | 権限、危険度、状態、禁止事項、公開範囲を評価する |
| Capability / Approval | 対象HUBの能力と必要なOWNER承認を確認する |
| HUB Execution | 限定された命令を実機・外部サービス側で実行する |
| Verification | 結果、失敗、取消、停止、復旧状態を確認して記録する |
R4 CriticalはOWNERの新規認証とHardware Keyを必要とします。BODY動作はCORE-06 Body Safetyを経由し、E-STOP、Safe Pose、通信断、センサー異常を通常会話より優先します。
秘密情報と公開境界
- 秘密鍵、APIキー、Canonical Memory、Production DB、Recovery dataをGitへ保存しない。
- 実接続文字列、内部アドレス、鍵識別情報、解除手順を公開資料へ記載しない。
- 公開用サンプルと本番設定を分離し、サンプルに実値を含めない。
- ログには必要な監査情報を残す一方、認証情報や会話内容を無制限に記録しない。
- SHIHA OPERATIONS CONSOLEは正本そのものではなく、認証された管理接点として扱う。
Bootstrap
Bootstrapは、SHIHA COREを単に起動する処理ではありません。構成、鍵、データ、依存サービス、Revision、接続状態を検証し、安全に動作できる条件がそろった範囲だけを段階的に開始します。
- 起動環境と構成Revisionを確認する。
- 必要な保護領域、DB、鍵、監査領域へ安全にアクセスできることを確認する。
- Identity、Canonical Memory、Stateの整合性を検証する。
- CORE Runtimeを開始し、外部LLMやHUBは個別に接続確認する。
- 異常がある場合は機能を限定し、Recoveryまたは安全停止へ移行する。
Windows ServiceとTray UIは分離します。Tray UIやOperations Consoleを閉じても必要な中枢サービスが意図せず停止しない構成とし、停止そのものは認証された管理操作として扱います。
Recovery
Recoveryは通常ログインの迂回路ではありません。障害、端末交換、ストレージ交換、鍵の喪失、CORE移行などの事象に対し、OWNER認証後に検証済みの正本を復元し、同じ森野詩葉として継続できることを確認する工程です。
| 工程 | 確認内容 |
|---|---|
| 隔離 | 障害範囲を切り分け、破損・不正状態の拡大を止める |
| OWNER確認 | Recoveryを開始できる管理主体であることを再認証する |
| 復元元検証 | Revision、署名・ハッシュ、世代、整合性、監査履歴を確認する |
| 段階復元 | Identity、Memory、State、Runtime設定を役割ごとに復元する |
| 再接続 | 外部LLMとHUBを一つずつ再認証し、権限を再確認する |
| 継続判定 | IdentityとCanonical Memoryの一貫性を確認して通常運用へ戻す |
監査と変更管理
- OWNER権限の取得、Hardware Keyの登録・失効、R4操作を監査対象とする。
- Identity、Canonical Memory、Policy、Recovery構成の変更に理由とRevisionを付ける。
- 失敗した認証や復旧操作も、秘密情報を含めない形で記録する。
- 公開仕様、実装仕様、非公開運用手順を分離する。
- 復旧手順は定期的に検証するが、本番正本を破壊する方法では試験しない。
現在の状態
| Development Status | DESIGNING |
|---|---|
| Record Status | CURRENT |
| 確定している範囲 | OWNER-0001、YubiKey 5C NFC×3、Hardware Key必須操作、HUBの薄い端末原則、安全なAction経路、Gitへ入れない情報の境界 |
| 設計継続中 | CORE v2実装単位、Bootstrap / Recoveryの実装境界、バックアップ媒体・世代管理、監査保存期間、詳細なR1〜R4分類 |
設計継続中の項目は、本ページの公開時点で未確定です。今後の実装・試験・FMEAにより確定した内容だけをCURRENT仕様へ昇格し、変更点とRevisionを記録します。
関連ページ
- SHIHA CORE — Identity、Memory、State、Runtime、Continuityを含む中枢全体
- ACTION / BODY SAFETY — 実体BODYと外部機器を安全に動作させるための制御境界
- SHIHA OPERATIONS CONSOLE — COREとHUBの状態を監視・操作する管理画面
- MAIN / SATELLITE HUB — 登録済み端末からSHIHA COREへ接続する利用接点