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.

Goals

1. Be a source of secure binding for user identifiers on their phone.
2. Specifically allow the user to register with a web site supplying on the minimal level of user contact information consistent with California laws in the US or GDPR elsewhere.
3. Meet the needs of the US Healthcare community for identity proofing with dual factor authentication (IAL2) and user credential protection (AAL2).

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 meeting NIST SP 800-63-3B specifications. (See the references below.)
• This is a companion use case to the User Agent in the Cloud Use Case. In this case the user puts the agent on the smart phone, in that case the user lets a cloud service be their agent.

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 of the user and the site.
• The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.

1. on the user's smart phone where the user's consents (grants) are maintained, or
2. in the cloud, possibly as a component of an Identity Provider in the manner described in OpenID Connect 1.0.

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. Essentially all smart phones shipped since 2017 can do this.
   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. A healthcare specific trust registry exists to attest to providers of Electronic Health Record (EHR) and smart phone apps, all of which agree to support the security, privacy, interop and UX of the Health Care Profile.
2. The patient can create one or more trusted identifiers in cyberspace that can be used to access their health records at any of their care providers.
3. The patient has access to Health IT Record Location Service (Data Aggregation) and brought a locator ID or authorization code available on paper or existing PCP web site.
4. The patient has a smart phone and 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.
   2. The smart phone app may be selected by the user, or by the PCP, but must be registered by the trust registry in condition #1.

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 includes 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 Credential Service Provider 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 likely 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.

Alternate Scenario:

1. User controls access to Protected Health Information (PHI) through a Qualified Health Network (QHIN) which may be one of the providers or a trusted third party.
2. The QHIN is required (TEFCA 6.2.4iii) to perform identity proofing, unless it is also directly connected to the user's PCP it needs some other identity proofing, such as that provided by a phone credential.
3. The QHIN is required (TEFCA 6.2.5) to authenticate the user to AAL2 specs which is part of the phone credential.
4. Since the QHIN is a covered HIPAA entity it will have an entry in the trust registry and so known to the app as trustworthy.
5. The user can create an account to the QHIN using their smart phone as both the source of identity proofing and strong key protection.
6. The application will then be able to track the QHIN as it would any other medical provider and sign seamlessly via their phone.
7. In this case the application will need access to the consents that the user has created that allow access from one provider to another.
8. The phone provides cryptographically secure user consent to one party (typically the receiver of the PHI) that can be passed to another party (the sender).
9. The user can revoke a consent at any time stopping any further transfer from one site to another.

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 value add for the patient includes:
   1. The ability to authenticate to a level 2 of assurance using their smart phone with no separate IDP required.
   2. The ability to interact (upload and download) with medical records based on the credentials in their smart phone.
   3. The ability to seamlessly register with any other participating entity (covered entity or QHIN.)

• Covered entities are medical care providers, EHR, pharmacies, payers, laboratories, third party IT providers etc. that are subject to HIPAA rules.
• QHIN is a qualified Health Information Network, which may also be a covered entity with registered individual users.

Examples:

1. tbd

Dependencies:

1. Web Sites must be trusted before any user information is released to them.
2. Trust federations are effective in helping users make informed decisions.
3. User consent and trust must begin with no user information transferred other than some method to notify the user of any problems.
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 its 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 (testator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.

• The base page for NIST Special Publication 800-63 version 3. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.

  Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

• TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.

  page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health Information, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules.

  page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared.

• Complying with the FTC’s Health Breach Notification Rule includes the HIPAA covered entities as well as third parties that hold medical data.
• ONC Model Privacy Notice is voluntary, but provides good guidance.