認証とデバイスセキュリティ

このドキュメントは、Chronolith の macOS アプリ と バックエンドサービス で使用される認証アーキテクチャの セキュリティ重視 の概要を提供します。システムを狙うために悪用され得る実装詳細は公開せずに、技術的な流れと防御的制御を説明することを目的としています。

対象範囲:

認証方式（パスワード、パスキー、TOTP）
デバイスバインディングとデバイス許可リスト
リクエストおよび機微操作に対する PoP（Proof-of-Possession）保護
ローカルの安全な保存とリカバリ登録の概念
検証、レート制限、リプレイ対策、運用上のガードレール

設計目標

強固なアカウント保護をデフォルトに（多要素への備え、デバイス制御）。
デバイスバインディングとリクエスト PoP により トークン盗難の影響を最小化。
登録を明示的かつ監査可能に（新規デバイス登録には追加の証明が必要）。
機微情報の露出を低減（端末での安全な保管、サーバーは可能な限りハッシュ／派生表現のみを保持）。
層状の防御：レート制限、ステップアップ要件、リプレイ防止、用途限定のワンタイム証明。

コアとなるセキュリティ構成要素

サーバー側の暗号処理（高レベル）

パスワードハッシュ は、実績のあるライブラリを用いたモダンなメモリハード KDF（Argon2 系）で実施。パラメータは最新のガイダンスに合わせて選定し、必要に応じて調整。
TOTP は標準規格（RFC 6238）に準拠し、時計のずれに対応する小さな許容ウィンドウを持つ。
公開鍵署名（Ed25519）を、ID／デバイス証明やリクエスト PoP 検証に使用。
チャレンジや「証明」ステップで用いる 用途限定のワンタイムトークン は、認証済みのサーバー側メカニズム（例：正規化したペイロードへの HMAC）で生成・検証し、厳格な用途拘束と有効期限を持つ。

公開メモ：正確なパラメータ値、正規化文字列の形式、内部の検証閾値は意図的に省略しています。

トークンモデルとセッション管理

短命の アクセストークン と、より長命の リフレッシュトークン を使用。
トークンは 不透明なランダム値 とし、サーバーには ハッシュ／派生表現のみ を保存して、データベース流出時のリスクを低減。
リフレッシュトークンのローテーションを有効化可能。ローテーション時はリプレイを検知して保護措置（例：セッションの無効化、ポリシーに応じた関連セッションの無効化）を実施。

デバイスバインディングとデバイス許可リスト

Chronolith はデバイスをセキュリティ上の第一級オブジェクトとして扱います。

デバイスは次を紐づける デバイス証明書／クレデンシャル で表現:
- アカウントの ID 鍵（公開鍵）
- デバイス鍵（公開鍵）
- 発行メタデータ
- 関係性を証明する署名
検証後、サーバーはアカウントに対する デバイス許可リスト を維持。
デバイスに紐づいたセッション は許可済みデバイスにリンクされ、高信頼エンドポイントはデバイスバインディングを要求。

これにより:

未知のデバイスからのサイレントなログインを防止
未認識デバイスでのトークン使用を検知・遮断
デバイス失効でデバイス紐づきセッションを無効化

リクエストの PoP（Proof-of-Possession）

盗まれたベアラートークンの価値を下げるため、Chronolith は リクエスト単位の PoP を要求できます。

クライアントは署名済みの証明をリクエストに付与。
証明は以下にバインド:
- HTTP メソッドとパス
- リクエストボディのハッシュ
- タイムスタンプとノンス（鮮度とリプレイ防止）
- トークンバインディング要素（トークン間で再利用不可）

サーバー側の強制内容:

タイムスタンプの許容範囲
ノンスの形式／エントロピー検査
署名検証
リプレイ防止（ノンスの一定期間追跡）

公開メモ：ヘッダー名、正規化の詳細、ノンスの保持戦略、正確なスキュー／TTL 値は公開していません。

macOS アプリのセキュリティアーキテクチャ

ローカル鍵素材

macOS アプリは OS 提供の暗号プリミティブと安全なストレージを使用します。

ID／デバイス鍵はモダンな公開鍵暗号を使用。
コンテンツ暗号化はローカルオブジェクト暗号に適した AEAD 構成を使用。
リカバリデータは強力な KDF と認証付き暗号を適用するパスフレーズベース方式で暗号化。

アプリは暗号操作に必要な範囲を超えて鍵素材の生データを露出させません。

安全な保管（Keychain）

機微情報は、強固な認証情報に適した制限的なアクセス設定で macOS Keychain に保存されます。

保存される可能性のある項目:

ID／デバイス鍵素材（またはその派生用シード）
コンテンツ暗号化素材
セッショントークン（アクセス／リフレッシュ）
サーバー検証に必要なデバイス証明アーティファクト

リカバリバンドルの概念（公開可能な説明）

Chronolith は、制御されたデバイス登録やアカウント回復を可能にする リカバリバンドル 概念を備えています。

主な性質:

リカバリバンドルは 暗号化と認証 を施し、将来互換のためのバージョン付きメタデータを含む。
復号にはユーザーが保持する秘密（例：パスフレーズ）が必要。
リカバリデータの導入でアイデンティティの連続性を確保しつつ、サーバー側での明示的なデバイス登録が必要になるよう設計。

認証方式と技術フロー

以下のセクションでは、主要なフローごとの 操作順序とセキュリティ制御 を説明します。エンドポイント名やフィールド詳細は一般化しています。

1) メール認証（サインアップ手順）

クライアント

ユーザーがメールアドレスを送信。
クライアントがメール認証コードを要求。

サーバー

IP／識別子単位でのレート制限と悪用対策を適用。
短い認証コードを生成し、保護された表現のみを保存。
再送クールダウンと試行回数制限を実施。
構成済みのメールプロバイダでコードを送信。

クライアント

ユーザーがコードを送信。
サインアップ完了にのみ使える短命・用途限定の検証アーティファクトを受け取る。

セキュリティ特性:

メールアドレスの列挙対策は設定可能。
検証アーティファクトは短命かつ用途限定。

2) サインアップ（初回デバイス）— メール + パスワード + デバイス／ID 証明

クライアント

ローカルに ID／デバイス資格情報が存在することを確認。
アカウント ID 鍵との関連を証明するデバイスクレデンシャルを生成。
サインアップ情報（メール、パスワード、検証アーティファクト）と ID／デバイス証明を送信。

サーバー

検証アーティファクトを検証（ワンタイム、用途限定、有効期限内）。
パスワードをメモリハード方式でハッシュ化。
ID／デバイス証明を検証し、発行の鮮度ルールを確認。
ユーザー作成と初回デバイスの許可リスト登録。
デバイスに紐づくセッションを発行。MFA が必須／想定の場合、セッションは制限付きの「セットアップ」状態で開始。

セキュリティ特性:

メールとデバイス資格情報の双方を証明せずにサインアップできない。
初回デバイスを許可リストの基点として確立。

3) TOTP セットアップ／有効化／無効化

セットアップ

クライアントは、認証済みかつデバイス紐づきのチャネルで TOTP 登録素材（例：シークレットと URI）を取得。

有効化

クライアントが現在の TOTP コードを送信して設定を確認。
サーバーは検証し、セッションの信頼レベルを引き上げる。

無効化

アカウント乗っ取りによる MFA 無効化を防ぐため、ステップアップ検証（例：パスワード + TOTP）が必要。

セキュリティ特性:

MFA 変更は追加の証明が必要で監査可能。
有効化／無効化は高信頼のチェックで保護。

4) パスワードログイン（デバイス認識）

クライアント

メールとパスワードを送信。
許可リスト適用のためのデバイス識別情報を付与。
MFA が有効なら第二要素を提出。

サーバー

ログイン試行にレート制限と悪用対策を適用。
パスワードハッシュを検証。
MFA が有効なら検証。
デバイス許可リストを適用:
- 既知の有効デバイス：続行。
- 未知のデバイス：アカウントポリシーに基づく制御されたブートストラップ経路がない限りブロック。
デバイス紐づきのセッショントークンを発行。

セキュリティ特性:

レート制限など多層防御でクレデンシャルスタッフィング／総当たりに強い。
デバイス許可リストで未知端末からの無言アクセスを防止。

5) パスキーログイン（WebAuthn）

クライアント

パスキーログインを開始しチャレンジを取得。
プラットフォームのパスキー API でアサーションを生成。
アサーションと必要なデバイス識別情報を送信。

サーバー

WebAuthn アサーションの特性（RP／origin、フラグ、署名）を検証。
WebAuthn に適したリプレイ／整合性チェックを適用。
デバイス許可リストを適用（またはアカウント状態／ポリシーに応じた制御付きブートストラップ）。
セッショントークンを発行。

セキュリティ特性:

WebAuthn によるフィッシング耐性。
ポリシーで明示的に許可されない限り、未信頼デバイスからのパスキー単独アクセスを防止。

6) リフレッシュトークンフロー（PoP 付き）

クライアント

リフレッシュトークンで更新を実行。
更新操作に紐づく PoP データを添付。

サーバー

レート制限と異常検知。
保護表現を用いてリフレッシュトークンを検証。
デバイスバインディングと許可リストを強制。
PoP 証明とリプレイ対策を検証。
リフレッシュトークンをローテーションし、リプレイを検知する場合がある。

セキュリティ特性:

リフレッシュは長期アクセスの入口であるため強化。
ローテーションとリプレイ検知で盗難トークンの持続性を制限。

7) ログアウト／全セッションログアウト

ログアウト：現在のセッションを失効。
全セッションログアウト：アカウントの全アクティブセッションを失効。デバイス許可リストは（ポリシーにより）維持される場合があり、デバイス信頼状態を維持しつつセッションを失効可能。

セキュリティ特性:

侵害の疑いがある場合の迅速な封じ込め。

8) パスワード変更

クライアント

現在のパスワードと新しいパスワードを送信。必要に応じて他セッションの失効を要求。

サーバー

現在のパスワードを検証し、保存ハッシュを更新、ポリシーに従ってセッションを失効。
可能であればセキュリティ通知メールを送信。

セキュリティ特性:

ステップアップ必須。
セッション失効は攻撃者の滞在時間を短縮。

9) パスキー登録と失効

登録

クライアントが登録チャレンジを要求。
プラットフォーム API でパスキーを作成。
アテステーション／登録結果を送信。
サーバーが検証し、公開鍵と必要メタデータを保存。

失効

特定のパスキー失効を要求し、サーバーが失効状態に更新。

セキュリティ特性:

登録は origin 検証かつ用途限定。
失効は即時反映され、インシデント対応を支援。

制御されたデバイス登録（リカバリ支援）

Chronolith は、特に MFA 有効アカウントに対して、追加の証明による 意図的な 新規デバイス登録をサポートします。

登録の原則

登録は 限定スコープのセッション（権限を絞ったセッション）でブートストラップ。
登録中、アプリはリカバリされた機微データを一時的に メモリ上にのみ 保持し、サーバー承認後にのみ安全なストレージへ保存。
登録には、登録デバイスがアカウント ID の代理として動作していることの証明が必要。

リカバリ支援登録フロー（一般化）

クライアント

強力な手段（例：MFA 付きログイン／パスキーによる限定ログイン）で限定セッションに認証。
リカバリバンドルをローカルで復号・検証（メモリ上で一時保持）。
特定の登録目的に対する ID チャレンジをサーバーへ要求。
復元した ID 材料でチャレンジに署名／応答。
新しいデバイスクレデンシャルを生成し、ID 証明と共に送信。
成功時は Keychain に登録状態を保存、失敗時は一時素材を消去。

サーバー

限定セッションと目的拘束されたチャレンジトークンを発行。
ID 証明の妥当性、鮮度、ワンタイム性を検証。
デバイスクレデンシャルの整合性を検証し、アカウントに紐付け。
新デバイスを許可リスト登録し、限定セッションを失効。
通常のデバイス紐づきセッションを発行。

セキュリティ特性:

新規デバイス登録は「パスワードだけ」では成立しない。
証明トークンは用途限定・短命・再利用不可。
一時的な機微データは、サーバー承認までローカルに永続化されない。

運用上のガードレールと防御制御

Chronolith は多層防御を採用しています。主な例:

メール認証、ログイン試行、リフレッシュ処理、その他の機微エンドポイントに対する レート制限
PoP におけるノンスと時間ウィンドウによる リプレイ耐性
署名対象の厳格な入力検証と正規化
ID 確認と登録アクション向けの 用途限定ワンタイム証明
デバイス許可リスト と デバイス紐づきセッション による高信頼操作の保護
影響の大きい操作（MFA 無効化、認証情報変更、登録）への ステップアップ要件
失効経路:
- セッション失効
- 全セッション失効
- デバイス失効（デバイス紐づきセッションも無効化）
- パスキー失効

本ドキュメントで意図的に非公開としている情報

公開安全性のため、以下の詳細は省略／一般化しています:

正確なエンドポイントパス、内部ヘッダー名、正規化文字列形式
TTL、許容スキュー、試行しきい値、リプレイウィンドウの正確な値
内部ストレージキー、Keychain 識別子、サービス名
列挙を可能にする詳細なエラー挙動
実装依存の癖、パースのエッジケース、正規化の細部

まとめ

Chronolith の認証は次を組み合わせます:

標準準拠の要素（パスワードハッシュ、TOTP、WebAuthn パスキー）
デバイス信頼（許可リスト + デバイス紐づきセッション）
リクエスト整合性（PoP + リプレイ耐性）
制御された登録（限定セッション + 用途限定 ID 証明）
安全なローカル保存（Keychain + 登録時の一時メモリ保持）

このアーキテクチャは、単一レイヤーが低下した場合（例：トークン露出）でも、追加の証明（デバイスバインディング、PoP、ステップアップチェック）を要求することで、重要なアカウント操作の前に防御できるよう設計されています。