Architecture » History » Revision 19
Revision 18 (Suravi Regmi, 11/21/2025 06:16 PM) → Revision 19/23 (Suravi Regmi, 11/21/2025 06:33 PM)
# Architecture This page provides a **high-level architectural view** of MGuard. It summarizes how the main modules interact, how data flows through the system, and how security and access control are enforced at a system level. Detailed module-level behavior, policy processing, manifest handling, and sequence diagrams are provided in the linked **Architecture Details** page. --- ## System Architecture Overview MGuard follows the design described in the paper’s **Design Overview** (§3.1). :contentReference[oaicite:0]{index=0} A service instance consists of: - a data source (MD2K repository or sensor-generated streams), - a **Producer** that adapts and publishes mHealth data into NDN, - a **Controller** responsible for access policies and requester validation, also contains **Attribute Authority (AA)** issuing decryption keys, - an **NDN Repository** storing encrypted data, content keys, and manifests, - one or more **Consumers** subscribing to data streams they are authorized to access. Data requesters obtain trust anchors and certificates, subscribe to data streams, receive manifest notifications, and fetch/decrypt data objects. --- ## High-Level Architecture Diagram  --- ## TODO (Architecture Details) End-to-end workflows (overview) Publication workflow (Adaptor → Publisher → NAC-ABE encryption → Repo → PSync announcement) Authorization workflow (Consumer → Controller → DKEY issuance) Retrieval workflow (PSync update → manifest fetch → data/CK fetch → decrypt → callback) Black box components NAC-ABE → “encrypt(data, attributes) → encrypted data + CK” PSync → “publish(manifestName) → notify subscribers”