Project

General

Profile

Wiki » History » Version 14

Lan Wang, 11/23/2025 11:46 PM

1 1 Suravi Regmi
# MGuard: A Secure mHealth Infrastructure for Real-Time Data transfer with Fine-grained Access Control over NDN
2
3
4 14 Lan Wang
**MGuard** is an NDN-based system designed to support high-frequency mHealth data sharing with **fine-grained contextual access control** and **real-time data distribution**.  It builds on name-based access control (NAC/NAC-ABE) and PSync to enable timely access to sensitive mobile health data.
5 1 Suravi Regmi
6
---
7
8
## Purpose
9
MGuard addresses two core challenges in mHealth data sharing:
10
11
1. **Access to privacy-sensitive data is limited to authorized users based on well defined polcies**  
12
13
2. **Supporting real-time sharing of high-frequency sensor data**  
14
15
---
16
17
## System Goals
18
- Provide secure sharing of heterogeneous, high-frequency sensor data.
19
- Enable real-time access to newly published mHealth data.
20
- Support fine-grained access control.
21
22
---
23
24
## Core Components
25
26
### **Producer**
27
Receives data from the MD2K ecosystem or directly from device sensors.  
28
The producer:
29
- converts raw or derived data streams into NDN-named data objects,
30
- associates each object with appropriate attributes, and  
31
- stores encrypted data into the NDN repository.
32
33
It is also responsible for notifying subscribers when new data is available (via published manifest names).  
34
Based on the “Data Adapter” and “Publisher” modules described in the system design.
35 2 Suravi Regmi
36 1 Suravi Regmi
---
37
38
### **Controller**
39
Represents the policy and access management logic.  
40
The controller:
41
- defines **who** can access **which** data streams,  
42
- parses and manages access control policies, and  
43
- collaborates with the Attribute Authority to issue decryption keys (DKEYs) to validated data requesters.
44
45
It enforces the name-based access control structure.
46
47
---
48
49
### **Attribute Authority (AA)**
50
Part of the controller-side security infrastructure.  
51
The AA:
52
- validates requester identities (using the system’s trust anchor),
53
- issues policy-compliant decryption keys based on KP-ABE, and  
54
- publishes public parameters required for encryption.  
55
56
---
57
58
### **Consumer**
59
Subscribes to mHealth data streams according to the access rights defined for the requester.  
60
The consumer:
61
- receives notifications for new manifests,  
62
- fetches the corresponding encrypted data objects from the repository, and  
63
- decrypts data based on issued keys and permitted attributes.  
64
65
---
66
67
### **Repository**
68
Persistent storage for all published mHealth data objects, content keys, and manifests.  
69
The repository allows consumers to:
70
- retrieve data independently of the producer,  
71
- fetch CKs needed for decryption, and  
72
- access previously published (historical) data.  
73
74
---
75
76
## Navigation
77 8 Suravi Regmi
78 1 Suravi Regmi
- **[[Architecture]]**
79 8 Suravi Regmi
  - **[[Architecture_Details|Architecture Details]]**
80
- **[[Design_Elements|Design Elements]]**
81
  - **[[Naming_Scheme|Naming Scheme]]**
82
  - **[[Trust_Model|Trust Model]]**
83
  - **[[Access_Control|Access Control]]**
84
  - **[[NAC-ABE_Design|NAC-ABE Design]]**
85
  - **[[Manifest_Design|Manifest Design]]**
86
  - **[[PSync_Design|PSync Design]]**
87 12 Suravi Regmi
  - **[[Pub-Sub API|Pub-Sub API Design]]**
88 13 Suravi Regmi
  - **[[Repo|Repo Design]]**
89 8 Suravi Regmi
- **[[Developer_Guide|Developer Guide]]**
90 11 Suravi Regmi
- [Open editable Figma diagram](https://www.figma.com/design/I2SLqGN17XJHh8KsyAJ88l/Untitled?node-id=0-1&t=xWqhvwrDlUOlkeVU-1)