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 APIs associated with patient trust of the providers and patient consent granting and recording.

Primary Scenario:

1. Patient schedules an appointment with primary care physician and is authenticated at the front desk. (This will typically include a request to grant access held in the EHR at the practice to others - aka a consent form.)
2. As the receptionist collects patient data, an EHR is built up. Before the patient is permitted to see the provider the patient identifiers and attributes are built up into an Attribute Vector, which is combined with a risk profile of the PCP to create a trust vector which is scored by the computer. If the patient does not have sufficient trust score, the computer will direct the receptionist to continue to collect data until the following conditions (inter alia) are met:
   1. The real-world individual is identified,
   2. The real-world health history is sufficient,
   3. Payment has been adequately arranged.
3. Patient sees the provider(s), is re-authenticated (this reauth will be less onerous than that at the front desk) and explains symptoms.
4. The provider and others at the practice continue to collect patient health information and add it the the PCP EHR.
5. The provider may create diagnoses, health care plans, prescriptions or refer the patient to other providers during the visit.
6. At check-out additional actions, like payments or paperwork is provided. Re-authentication would apply at this step as needed by privacy concerns.
7. For new patients, the patient is given, or is mailed, a form the the following pieces of information that can be used to establish an online presence.
   1. A URL to the patient chart on the web. This is the site of the EHR, which may, or may not, be the same as the provider, such as would be the case for a conglomerate of several providers.
   2. An access code that allows them to create an identity proofed sign-in capability at the provider.

Alternate Scenario:

1. Before accessing the EHR the patient will need to follow the instructions on the form provided above.
2. The patient can sign onto the various practices' web sites and perform the actions from the comfort of her living room.
   1. Electronic consents are appropriate whenever additional consent is granted by the patient. Any consent receipts will be renderable to the user in plain language that they can understand.
   2. All sites that display patient data requires strong authentication of the patient and compliant protections of user information.

Following is one example of an online registration ceremony that has worked in the past to provide identity proofing of a patient at a web site.

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. A registration consent receipt for access that they have granted to others (e.g. data processors or providers who have EHRs of their own)
   2. Care plan including POLST and similar declarations that the patient has made to the practice.
   3. Access to their EHR (with sufficiently strong authentication.)
2. The EHR includes followup contact (phone, email, etc) information to inform the patient of care plan milestones that the patient has agreed to accomplish.
   1. This notification capability can be used for other information that needs to be communicated to the patient after the visit and registration.
3. Any referrals to other practitioners might be part of the this PCP, in which case it is covered by these consents and other terms, but referrals to other practitioners possibly need their own EHR.

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.