Digital+Signature+Threat+Analysis

Threats generally fall into one of 4 categories: confidentiality, integrity, authenticity, and availability.
 * NHIN Digital Signature Threat Analysis **

There are literally thousands of threats, exploits, and known vulnerabilities (over 43,000 vulnerabilities alone are tracked by the Common Vulnerabilities and Exposures List []). Many are essentially theoretical attacks, and many of the remaining practical threats don’t apply for NHIN-like architectures. An example is that web browser based vulnerabilities generally don’t apply to the NHIN since the gateways are largely automated.

See the references section, and the 2008/2009 section of this document for more threat models. As documented by the NIST, correct 2-way-SSL type deployments mitigate the vast majority of risks as a virtue of its design. Only two classes of attacks remain: Message Replay and Denial of Service (DoS). In addition, one specific TLS vulnerability has also been brought to the attention of the NHIN Security and Privacy Team, and is covered below. //Replay Attacks// ** //Definitions:// 1) An attacker, which must be a Man in the Middle (MITM), has the ability to intercept, store, and resend IP packets sent from one NHIN Gateway to another NHIN Gateway. The attacker does not need to ability to decrypt or understand the packets in order to successfully resend them. 2) A MITM attacker has the ability to intercept and resend complete SOAP messages appearing to come from a legitimate NHIN Gateway, or the NHIN Gateway itself has been compromised by malware or a defect resulting in it resending a stream of one or more recorded (old) SOAP messages. //Risks:// 1) Resending data will result in incorrect (old) information being transmitted across the NHIN Gateways. This is a very low impact risk since there are no identified cases where it will harm the integrity of the NHIN data sets at either node, other than one NHIN Gateway having a discrepancy in the ATNA log compared to the corresponding gateway. 2) Resending data could result in a Denial of Service (DoS) attack. This is a moderate risk, but one that is mitigated via IT perimeter systems, not by the use of XML-DSig. //Recommendation/Mitigation:// In both cases, no steps need to be taken within the context of signing the Timestamp (or the SAML Assertion) element using XML-DSig. For case #1 (IP packet replay) attacks can be filtered by perimeter systems or the TLS stack since the TLS 64-bit serial number is being resent. For case #2 (SOAP message replay) the XML-DSig requirement of can be removed since the 2-way-SSL channel provides a high degree of assurance that the message has been sent from a legitimate sender. //Rationale:// A replay can generally occur either by 1) a Man in the Middle (MITM) attack, or 2) if the corresponding NHIN Gateway itself is compromised, or 3) SSL is compromised. For #1, the replay can be detected and discarded before the message reaches the SOAP stack. For #2, that implies that the sender itself can probably just as easily generate a complete XML-Digitally Signed (authentic appearing) SOAP message, in which case we also have bigger issues of concern. For #3, if SSL is compromised, then again, we also have bigger issues of concern than replay attacks. This is not a practical concern with respect to the use of XML-DSig of the Timestamp. //Denial of Services Attacks// ** //Definition:// A Denial of Services (DoS) attack is one in which the attacker’s goal is to prevent or limit access to the NHIN’s legitimate users or systems. The most prevalent DoS attacks simply attempt to overwhelm a service endpoint with a large number of requests. An example would be to have a 10,000 computer “zombie bot node network” to all simultaneously attempt open a connection to a NHIN gateway XCPD responding service. The attempt to access the service will fail due to lack of proper 2-way-SSL credentials, but the very act of attempting to open a connection itself causes system resources to be consumed, resulting in the XCPD service being slow, or unavailable. //Risks:// 1) Delayed response times, or 2) unavailability of NHIN Gateway services. //Recommendation/Mitigation:// No steps needed within the domain of XML-DSig of the SAML Assertion or Timestamp elements. The XML-DSig elements should not be employed. We offer a strong recommendation that the ONC consider adding policy to require implementation and auditing of NHIN Gateway nodes to ensure proper IT-level security best practices are being employed. //Rationale:// DoS attack response must be generally handled by perimeter systems such as hardware firewalls. If the DoS attack passes through perimeter systems, it is generally too late to defend against the attack at the SOAP stack layer. //TLS Man in the Middle (MITM) Vulnerability (CVE-2009-3555)// ** //Definition:// Vulnerability has been found in most contemporary TLS implementations allowing a MITM attacker to inject limited plain text into an otherwise secure stream. //Risk:// Limited. The attacker is not able to read plain text dialog between the two TLS end points. The attacker is able to inject arbitrary plain text. //Recommendation/Mitigation:// No steps needed within the domain of XML-DSig of the SAML Assertion or Timestamp elements. The NHIN Security and Privacy Team recommends that the ONC consider issuing policy requiring all NHIN end points to be configured as per well-documented best practices to prevent this attack. //Rationale:// This attack leverages specific configurable aspects of the end point TLS implementations related to renegotiation and binding of cryptographic methods to channels and thus it is appropriate to resolve this threat through proper TLS configuration not through application of XML-DSig of the SOAP message. In addition, a number of risks exist if one uses partial XML-DSig as the NHIN is doing today. See the IBM paper in the references section for more information, including some countermeasures.
 * 
 * 
 * 

What is the ONC policy with respect to change management (new services, new hashing, etc.)? We need a version management strategy (sun setting old services after a time, etc.) What is the intent for non-repudiation? We cannot assure non-repudiation of the entire message without signing the body, and non-repudiation is a stated NHIN goal and HHS / Federal policy (see the references section). However, the precise definition of non-repudiation for the NHIN has not been specified. It is to ensure that the clinical document payload of the SOAP message has been viewed by a physician, and that the physician has digitally signed this clinical document payload? Or is the intended purpose to allow NHIN gateways to have the ability to prove that a given SOAP message was sent from another specific NHIN gateway? Or is this an obsolete requirement given the NHIN’s use of 2-way-SSL and ATNA logging? Is the ONC seeking end-to-end SOAP message security or just gateway-to-gateway? Is it ONC policy that NHIN gateways are only allowed to interoperate with other NHIN gateways? Is it ONC policy to require implementation and periodic auditing of NHIN Gateway nodes to ensure proper IT-level security best practices are being employed? Is SOAP message integrity and tamper detection an objective? If it is, then the current approach XML-DSig approach, taken out of context, is insufficient as only the two signed elements are protected. However, taken in context, we should either rely on 2-way-SSL, policy, and logging, or we should digitally sign the entire SOAP message. Other ONC Issues (Forward Looking) //** Will intermediaries be allowed and if so, will they be allowed to (or required to) add or replace XML-DSigs? Is the intermediary trusted? What are the boundaries of message level security? Some intermediaries are expected to change the message for example. If NHIN SOAP messages are subject to XML-DSig, which elements should be signed? What are the implications of a cloud model (some type of hosted intermediaries)? What are the implications of Edge systems (such as a push to a local practice EMR)? Is .NET stack support an objective, then the current approach is flawed and virtually unimplementable since the default .NET stack methods don’t support partial XML document signatures with different enveloping/reference mechanisms. If we don’t require XML-DSig now, will it be difficult to force support for it in the future? Federal cryptographic requirements may be higher than non-federal partners. Federal partners must use a higher level, potentially, that other entities. We must allow for the fact that policy, and technology, will change. This should be forward-looking enough to support the future, to the degree it can be anticipated such as new hashing and encryption algorithms. We should also allow for a transition period to accommodate this. In the future, will the NHIN allow plain text over an open channel? If so, then we will need to consider XML-DSig and XML-Encryption of the SOAP message (header and body). Prior Work //** From the 2008 / 2009 NHIN Security and Privacy Workgroup Key: Black=(X) HITSP Counterpart Orange= Partial (P) HITSP Counterpart Red = No (N) HITSP Counterpart · Message alteration. An attacker inserts, removes or modifies information within a message to deceive the receiver, · Loss of confidentiality. Information within a message is disclosed to an unauthorized individual, · <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Falsified messages. Fictitious messages that an attacker intends the receiver to believeare sent from a valid sender, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Man in the middle. A third party sits between the sender and provider and forwards messages such that the two participants are unaware, allowing the attacker to view and modify all messages, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Principal spoofing. An attacker constructs and sends a message with credentials such that it appears to be from a different, authorized principal, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Forged claims. An attacker constructs a message with false credentials that appear valid to the receiver, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Replay of message. An attacker resends a previously sent message, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Replay of message parts. An attacker includes portions of one or more previously sent messages in a new message, <span style="font-family: Symbol; font-size: 10pt; line-height: 115%; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol; msobidifontfamily: Symbol; msofareastfontfamily: Symbol; msolist: Ignore;">· <span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Denial of service. An attacker causes the system to expend resources disproportionately such that valid requests cannot be met. From the NIST publication cited below:
 * //<span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">Open Questions Related to Digital Signatures //**
 * //<span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">
 * //<span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">

<span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">The HHS already has a department-wide non-repudiation stance. Origin: (Defined in FIPS 200, Minimum Security Requirements for Federal Information and Information Systems) []__.html HHS esig notice of proposed rule making: [] ARRA-related standards [] W3C message level threats (see section 3.6.2): [] NIST publication for web services security: [] Proper usage of XML-DSig: [] Relevant NHIN Spec subject to revision: [] Non-repudiation mandate (section 5.3.8): [] External requirements audit: [] NIST web site devoted to security vulnerabilities, with a link to the TLS issue mentioned above: []
 * //<span style="font-family: 'Arial','sans-serif'; font-size: 10pt; line-height: 115%;">References: //**