Remote Attestation Use Case

Full Title of Use Case

A user with a Smart Phone goes though a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.

Context

• The test use case will be a patient that desires to download or upload medical records, including records with a high level of privacy sensitivity.
• To provide Level 2 or Level 3 assurance of a user NIST SP 800-63-3B

Goal

• The primary goal is to enable patient choice in the selection of the types of attestation that they can seek commensurate with the requirements of relying parties with which they desire to establish an enduring, secure channel of communications for the mutual benefit.

Actors

1. A new user of a relying party who is told that they must acquire the means to establish higher levels of assurance to download or upload data on that relying party.
2. A relying party that has high value data that a user want to see or modify, for example a patient wants to download or upload medical records for a Electronic Health Repository.
3. The auditor that verifies the functionality of the Remote Attestation Service.
4. A Remote Attestation Service (aka Credential Service Provider) that can handle the following functions:
   1. Have a known level of trust in the community of interest, for example, with the regulators of the healthcare community.
   2. Industry requirements for participants in the attestation function, for example the proofing of the identity of the user.
   3. Have a verified policy statement that explains to all what procedures they follow in producing their attestations.
   4. Identification of the hardware supplier, the operating system supplier and the user application.

Distributed Attributes

• This use case assumes that it will not be possible to have a single aggregation of all of a patient's digital records in a single provider. While such aggregation may be possible in smaller countries, it will never be possible in any federal system where the individual states have responsibility for the health of their residents, like the US or the EU. So the use cases is based on a fragmented source of patient data.
• As a general rule, a single unified source of data is also a single point of failure that is not responsive to patient concerns. It is considered to be both more resilient and more responsive to provide an ecosystem where patient attributes are distributed among parties that are responsible for the validity and integrity of the attributes.
• In this context patient attributes are considered to include personal and financial attributes as well as user sensitive (e.g. medical) records.

Preconditions

1. The user has self-selected to establish a high level of assurance on the phone (or other device) in order to access highly sensitive, or costly, data on the relying party.
2. The user has possession of a device and its software that can meet the following criteria (in this case possession means that the user has effective control of the functioning of the device):
   1. The device's manufacturer is known and has control of the software that is initially delivered with the device to the user.
   2. The device include hardware protection for authentication credentials (e.g. a private key) and the use of that credential.
   3. The operating system of the device has control of the application software that is loaded onto the device and prevents the installation of applications that can impact the user security and privacy.
   4. The application software is provided that meets the security, privacy, interoperability and user experience as specified by the community of interest.

Healthcare Specific Conditions

1. The patient has one or more trusted identifiers in cyberspace that can be used to access their health records at any of their care providers.
2. The patient has access to Health IT Record Location Service (Data Aggregation) and brought a locator ID or authorization code with them.
3. The patient has a smart phone with a health maintenance app that allows them to bring their health records to, or to take their health records away from, the PCP at registration.
   1. The smart phone app may have the data stored locally, or in a web site that supplied the app. In all cases the data is covered by HIPAA regulations.

Scenarios

The goal of this scenario is to test the functionality of the process of patient acquisition of level 2 assurance for access to patient health records of the PCP and other healthcare providers.

Primary Scenario which include identity proofing by the PCP:

1. User (a Patient or Guardian) leaves their Primary Healthcare provider with an authorization code.
2. User downloads one of the applications that is identified as acceptable on a list provided by the PCP. (Note that it is permissible for the list to include only the one app provided by the PCP.)
3. The user is guided through a process of initializing the application on the phone.
4. The user selects an identifier that will be used for any level 2 assurance.
5. The user is asked for some means to contact them for recovery or redress, typically an email address or phone number.
6. The user enters their authorization code.
7. The app contacts the Remote Authorization Service (aka CSP) and gets back a packet of information that attests to the validity of level 2 assurance.
   1. Note that there could be some back and forth at this point to guide the user to make the correct choices or provide the appropriate data.
8. The user can now sign in to the PCP with their level 2 resources (at this point the only advantage over existing PCP web site access the the ability to download data in bulk.)
9. The user downloads data from the PCP.
10. The user visits (in person on online) to another covered medical provider where their level 2 sign in credentials are accepted.
    1. There most like will be other information required by the other provider, usually associated with getting payment authorization.
11. The user can transfer the medical information directly from the phone, or create an authorization to transfer data via an HIE based on the level 2 authentication of the user.

Alternate Scenario:

1. TK

Results

Accepted Risks:

1. Data transfers involved work within a framework of trust and mutual understand as to the patient's wishes with respect to care and privacy.

Post Condition:

1. The patient is given:
   1. The ability to access medical records based on the credentials in their smart phone.

Examples:

1. tbd

Dependencies:

1. Web Sites must be trusted before any user information is released to them.
2. Trust federations can be used to help users make informed decisions.
3. User consent and trust must begin with no user information transferred.
4. Standards (like TEFCA) exist to collect needed attributes where-ever they may be.
5. Connections to related providers for financial settlements will need to be enabled. In many cases these will have patient private information that needs protection.
6. Most PCPs will depend on IT support from third party providers. It must be clear to the patient in all cases who holds their data (a data processor) and who controls their data (a PCP or data controller) and where the patient goes for redress. This is not generally true as of (2019-04-29).

Workflow Diagram

TK

References

• Stanford University CS259 Project Report - Security Analysis of Remote Attestation by Lavina Jain and Jayesh Vyas

  Remote attestation is a method by which a host (client) authenticates it’s hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (attestator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.