Wiki » History » Revision 2
« Previous |
Revision 2/13
(diff)
| Next »
Suravi Regmi, 11/20/2025 06:44 PM
MGuard: A Secure mHealth Infrastructure for Real-Time Data transfer with Fine-grained Access Control over NDN¶
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.
Purpose¶
MGuard addresses two core challenges in mHealth data sharing:
Access to privacy-sensitive data is limited to authorized users based on well defined polcies
Supporting real-time sharing of high-frequency sensor data
System Goals¶
- Provide secure sharing of heterogeneous, high-frequency sensor data.
- Enable real-time access to newly published mHealth data.
- Support fine-grained access control.
Core Components¶
Producer¶
Receives data from the MD2K ecosystem or directly from device sensors.
The producer:
- converts raw or derived data streams into NDN-named data objects,
- associates each object with appropriate attributes, and
- stores encrypted data into the NDN repository.
It is also responsible for notifying subscribers when new data is available (via published manifest names).
Based on the “Data Adapter” and “Publisher” modules described in the system design.
Controller¶
Represents the policy and access management logic.
The controller:
- defines who can access which data streams,
- parses and manages access control policies, and
- collaborates with the Attribute Authority to issue decryption keys (DKEYs) to validated data requesters.
It enforces the name-based access control structure.
Attribute Authority (AA)¶
Part of the controller-side security infrastructure.
The AA:
- validates requester identities (using the system’s trust anchor),
- issues policy-compliant decryption keys based on KP-ABE, and
- publishes public parameters required for encryption.
Consumer¶
Subscribes to mHealth data streams according to the access rights defined for the requester.
The consumer:
- receives notifications for new manifests,
- fetches the corresponding encrypted data objects from the repository, and
- decrypts data based on issued keys and permitted attributes.
Repository¶
Persistent storage for all published mHealth data objects, content keys, and manifests.
The repository allows consumers to:
- retrieve data independently of the producer,
- fetch CKs needed for decryption, and
- access previously published (historical) data.
Navigation¶
- Architecture
- Design Elements
- Developer Guide
- API Reference
Updated by Suravi Regmi 1 day ago · 13 revisions