Digital+Signature+Threat+Analysis+page.

Threats generally fall into one of 4 categories: confidentiality, integrity, authenticity, and availability. 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.
 * Threats of Concern**

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.

> I. 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.

//II. 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.

//III. 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. > > > > **Prior Work** (add reference/link) > (From the 2008 / 2009 NHIN Security and Privacy Workgroup) > > **References** (add reference/link)