edgesentry-rs のコンセプト
このドキュメントは、このリポジトリで使用されているコアコンセプトをまとめたものです。
1. 改ざん検知可能な設計
主な目的は「完全な改ざん防止」ではなく、「確実な改ざん検知」です。
- 元のペイロードからハッシュを計算する
- デバイスの秘密鍵でハッシュに署名する
- ハッシュチェーンでレコードを連結する
これらのメカニズムを組み合わせることで、改ざん・なりすまし・レコードの並べ替えを検知します。
2. AuditRecord
エビデンスの基本単位はAuditRecordです。主なフィールド：
device_id：送信元デバイスの同一性sequence：単調増加するシーケンス番号timestamp_ms：イベントのタイムスタンプpayload_hash：生ペイロードデータのハッシュsignature：payload_hashに対する署名prev_record_hash：前の監査レコードのハッシュobject_ref：生ペイロードストレージへの参照（例：s3://...）
3. ハッシュと署名
3.1 ハッシュ（完全性）
- 目的：ペイロードコンテンツのフィンガープリント
- 特性：ペイロードが 1 バイトでも変わると異なるハッシュが生成される
3.2 署名（真正性）
- 目的：ペイロードハッシュが信頼済みデバイス鍵によって生成されたことを証明する
- 検証：登録されたデバイス公開鍵で検証する
4. ハッシュチェーンの連続性
レコードはprev_record_hashによって連結されます。
- 最初のレコード：
prev_record_hash = zero_hash - 後続のレコード：前のレコードの
hash()と一致しなければならない
これにより、チェーン内への挿入・削除・置換を検知します。
5. シーケンスポリシー
sequenceはデバイスごとに 1, 2, 3, …と増加しなければなりません。
- シーケンス値の重複は拒否される
- ギャップや順序違いのシーケンスは拒否される
6. ソフトウェアアップデートの完全性
デバイスがファームウェアまたはソフトウェアのアップデートを適用する前に、edgesentry_rs::update::UpdateVerifierを通じて 2 つのチェックをパスしなければなりません。
- ペイロードハッシュ —
BLAKE3(raw_payload)がSoftwareUpdateマニフェストに埋め込まれたハッシュと一致しなければならない - パブリッシャー署名 — そのハッシュに対する Ed25519 署名が、登録済みの信頼するパブリッシャー鍵で検証できなければならない
試行結果（承認・拒否を問わず）はすべて監査のためにUpdateVerificationLogに追記されます。これは CLS-03 / ETSI EN 303 645 §5.3 / JC-STAR STAR-2 R2.2 を満たします。
7. ネットワークポリシー（デフォルト拒否）
edgesentry_rs::ingest::NetworkPolicyは、受信接続に対してデフォルト拒否の IP/CIDR アローリストを強制します。呼び出し元はレコードをIngestServiceに渡す 前にNetworkPolicy::check(source_ip)を呼び出します。リストにないアドレスからの接続は、暗号チェックに達することなく拒否されます。
ルールは追加的です：allow_ip(addr)で完全一致、allow_cidr("10.0.0.0/8")で CIDR ブロック（ IPv4 ・ IPv6 両対応）を許可します。空のポリシーはすべてを拒否します。
8. データ取り込み時の検証
edgesentry_rs::ingestは永続化前のトラストチェックを完了させる責任を持ちます。
レコードをデータ取り込みする際の完全なチェック順序は次のとおりです。
- ネットワークゲート —
NetworkPolicy::check(source_ip)が暗号処理の前にリストにない送信元を拒否する - ペイロードハッシュ —
IngestServiceが生ペイロードとrecord.payload_hashの一致を検証する - ルート同一性 —
cert_identityが存在する場合、record.device_idと一致しなければならない - 署名 — ペイロードハッシュが登録済みデバイス鍵で署名されていなければならない
- シーケンス — デバイスごとに厳密に単調増加かつ重複なし
- 前レコードのハッシュ — 最後に承認されたレコードのハッシュからチェーンが続いていなければならない
ステップ 3 〜 6 はIntegrityPolicyGateが強制し、ステップ 2 はゲートを呼び出す前にIngestServiceが強制します。
9. ストレージモデル
データ取り込みが承認されると、システムは次のものを保存します。
- 生データ（ペイロード本体）
- 監査台帳（監査レコードのストリーム）
- 操作ログ（承認/拒否の決定）
この分離により、エビデンスのメタデータとペイロードストレージを独立して管理できます。
10. デモモード
10.1 ライブラリサンプル（ DB/MinIO 不要）
- 実行：
cargo run -p edgesentry-rs --example lift_inspection_flow - インメモリストアを使用
- 署名・データ取り込み検証・改ざん拒否を素早く確認できる
10.2 インタラクティブローカルデモ（ DB/MinIO 必要）
- 実行：
bash scripts/local_demo.sh - PostgreSQL + MinIO + CLI を使ったエンドツーエンドのフロー
- 永続化された監査レコードと操作ログを確認できる
11. トラスト境界
- デバイス側：ファクトに署名してコンパクトな監査メタデータを送出する
- クラウド側：データを受け入れる前に厳格な検証ルールを強制する
この分割により、エッジとクラウドの責任を明確かつ監査可能に保ちます。
12. 品質とリリースのコンセプト
- 静的解析：
clippy - OSS ライセンスポリシー検証：
cargo-deny - アドバイザリスキャン：
cargo-audit（ RustSec アドバイザリ DB に対する CVE チェック） - リリース準備： CI + リリースワークフロー
- タグ駆動リリース：
vX.Y.Z
実行手順についてはコントリビューションとビルドとリリースを参照してください。
13. STRIDE の脅威モデル
SS 711:2025 と IMDA IoT サイバーセキュリティガイドは、 CLS レベル 3 評価のために記録された STRIDE ベースの脅威モデルアーティファクトを必要とします。 6 つの脅威カテゴリは、 EdgeSentry-RS の攻撃面に次のようにマッピングされます。
| 脅威 | 攻撃面 | 緩和策 |
|---|---|---|
| S poofing （なりすまし） | デバイス同一性 | Ed25519 署名 — 登録された公開鍵だけがレコードを検証できる |
| T ampering （改ざん） | 監査レコード・ペイロードストレージ | BLAKE3 ハッシュチェーン — いかなる変更もチェーンの連続性を破壊する |
| R epudiation （否認） | データ取り込み決定 | OperationLogがすべての承認/拒否決定を理由とともに記録する |
| I nformation Disclosure （情報漏洩） | 生ペイロードストレージ | object_refの分離により、ペイロード本体が監査メタデータストリームに含まれないよう保つ |
| D enial of Service （サービス拒否） | データ取り込みエンドポイント | NetworkPolicyのデフォルト拒否が、暗号処理の前にリストにない送信元を拒否する |
| E levation of Privilege （特権昇格） | データ取り込みゲート | IntegrityPolicyGateがデータを受け入れる前にデバイス登録と署名を検証する |
CLS レベル 3 評価向けの正式な設計アーティファクトの作成は#93で追跡されています。
14. SBOM （ソフトウェア部品表）
ソフトウェア部品表（ SBOM ）は、製品で使用されているすべてのソフトウェアコンポーネントとそのバージョンを一覧にしたものです。 IMDA IoT サイバーセキュリティガイドは、ベンダー開示チェックリストのライフサイクルサポートカテゴリの一部として、 SBOM の提供を必須 CLS レベル 3 エビデンスアーティファクトとして要求しています。
Rust プロジェクトでは、cargo-sbomやcargo-cyclonedxなどのツールを使ってCargo.lockから SBOM を生成し、すべてのクレートとその推移的な依存関係の機械可読なインベントリを作成します。
SBOM の生成・公開とベンダー開示チェックリストの整備は#92で追跡されています。