Skip to main page content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

Https

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Access keys NCBI Homepage MyNCBI Homepage Main Content Main Navigation
. 2019 Apr:12:49-65.
doi: 10.1016/j.smhl.2018.01.003. Epub 2018 Apr 17.

Secure Sharing of mHealth Data Streams through Cryptographically-Enforced Access Control

Emily Greene  1 , Patrick Proctor  1 , David Kotz  1
Affiliations

Secure Sharing of mHealth Data Streams through Cryptographically-Enforced Access Control

Emily Greene et al. Smart Health (Amst). 2019 Apr.

Abstract

Owners of mobile-health apps and devices often want to share their mHealth data with others, such as physicians, therapists, coaches, and caregivers. For privacy reasons, however, they typically want to share a limited subset of their information with each recipient according to their preferences. In this paper, we introduce ShareHealth, a scalable, usable, and practical system that allows mHealth-data owners to specify access-control policies and to cryptographically enforce those policies so that only parties with the proper corresponding permissions are able to decrypt data. The design and prototype implementation of this system make three contributions: (1) they apply cryptographically-enforced access-control measures to stream-based (specifically mHealth) data, (2) they recognize the temporal nature of mHealth data streams and support revocation of access to part or all of a data stream, and (3) they depart from the vendor- and device-specific silos of mHealth data by implementing a secure end-to-end system that can be applied to data collected from a variety of mHealth apps and devices.

Keywords: electronic health records; encryption; mHealth; mobile health; privacy; security.

PubMed Disclaimer

Conflict of interest statement

Conflicts of interest: none

Figures

Figure 1
Figure 1
Example of temporal granularity supported by ShareHealth. S0 represents the first random seed generated for this data stream. Each black tick represents the beginning of a new SRI, with Sx being the random seed generated for the xth SRI. Data currently generated by Alice, the data owner, is hashed using the 7th hash chain. Bob (top thick dark gray) and Charlie (bottom thin light gray) are two data consumers with whom Alice would like to share different temporal subsets of this data stream. To grant Bob access, Alice shares the hash within the 4th hash chain (seeded by S4) that corresponds to the first record she would like Bob to access in addition to the hash key for that chain. Bob will continue to receive the new hash chain seeds until Alice terminates his access in the future by generating seed S10A in the middle of the 10th SRI and sharing the new seed with all data consumers except Bob. Alice desires to grant Charlie access to two different subsets of temporal data. She retroactively shares seeds S2 through S5 with Charlie in addition to the hash key for the hash chain, but does not share seed S6 (thereby restricting his access to only the time period contained by SRI 2–5). She will also share seeds S8 through S11 (including S10A) as they are generated to share future stream data with him.
Figure 2
Figure 2
An overview of the protocol between ShareHealth components. Seed and key sharing between ShareApp and ShareView occurs periodically after the initial key exchange. ShareView uses seeds to generate hashes (where the xth value in a hash chain is denoted hx) and requests the corresponding data for that hash (denoted dx) from ShareBase. ShareBase returns the encrypted data (denoted E(dx)) for ShareView to decrypt (D(E(dx))). All communications between ShareApp, ShareBase, and ShareView are encrypted using standard protocols, such as TLS.
Figure 3
Figure 3
The components of ShareHealth
Figure 4
Figure 4
Defining the attribute universe and attribute-tagging scheme (left) and the temporal range of access for each consumer (right).
Figure 5
Figure 5
Execution time of encryption and upload
See this image and copyright information in PMC

References

    1. Akinyele JA, Lehmann CU, Green MD, Pagano MW, Peterson ZNJ, Rubin AD. Tech Rep 2010/565. Cryptology ePrint Archive; 2010. Self-protecting electronic medical records using attribute-based encryption. URL http://eprint.iacr.org/2010/565.
    1. Ambrosin M, Conti M, Dargahi T. Proceedings of the Workshop on IoT Challenges in Mobile and Industrial Systems (IoT-Sys) ACM; 2015. On the feasibility of attribute-based encryption on smart-phone devices; pp. 49–54. URL . - DOI
    1. Benaloh J, Chase M, Horvitz E, Lauter K. Proceedings of the ACM Workshop on Cloud Computing Security (CCSW) ACM; 2009. Patient controlled encryption: ensuring privacy of electronic medical records; pp. 103–114. URL . - DOI
    1. Caine K, Hanania R. Patients want granular privacy control over health information in electronic medical records. Journal of the American Medical Informatics Association. 2013;20(1):7–15. doi: 10.1136/amiajnl-2012-001023. URL . - DOI - PMC - PubMed
    1. Caine K, Kohn S, Lawrence C, Hanania R, Meslin E, Tierney W. Designing a patient-centered user interface for access decisions about ehr data: Implications from patient interviews. 2015;30(1):7–16. doi: 10.1007/s11606-014-3049-9. URL . - DOI - PMC - PubMed

LinkOut - more resources