mGuard

# 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

![](high_lvl.png)

![](system_design.png)

---

## 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”

[[Architecture Details]]