Remote Attestation Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 86: Line 86:
* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>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.</blockquote>
* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>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.</blockquote>
* [https://pages.nist.gov/800-63-3/sp800-63-3.html 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.<blockquote>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.</blockquote>
* [https://pages.nist.gov/800-63-3/sp800-63-3.html 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.<blockquote>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.</blockquote>
* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf 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.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI. 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. </blockquote>
* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf 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.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI. 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. </blockquote><blockquote>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. </blockquote>


[[Category:Use Cases]]
[[Category:Use Cases]]
[[Category:Profile]]
[[Category:Profile]]

Revision as of 16:24, 30 September 2019

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 (See the references below.)

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 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 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, 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 upload and download 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 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. 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.