A previous blog in this series, “From Verification to Trust,” discussed the role that digital signatures and other evidence can play in enabling trust decisions. The accompanying technical report “Origin Verification is Not Enough” further elaborated on the foundational difference between origin authentication and long-lived protections such as those provided by object security protocols.

Those discussions illustrated the importance of measurable trust and highly available, current security status information.

This blog and the new Verisign Labs Technical Report “Security is Priceless, but Exposure Costs Must be Quantified,” by Verisign Distinguished Scientist Eric Osterweil, explore a critical aspect of deriving trust from security status: time.

The technical report provides a formal mathematical foundation for the time dimension of security status called vulnerability windows. It also proposes calculations of the impact of these windows, called exposure cost. Organizations can use these concepts to quantify the risk levels in their deployments of certificate-based security, and how different status mechanisms can reduce those risks.

As an example of identifying vulnerability windows and exposure cost, consider that many secure email applications today follow the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol, which is based on the Cryptographic Message Syntax (CMS). Following the framework discussed in the blog “From Verification to Trust,” an S/MIME recipient considers at least three types of evidence when validating a secure email:

• the sender’s digital signature on the email;
• the sender’s certificate (and any other certificate in its trust chain); and
• status information about the sender’s and other certificates

All three types of evidence have been included in the CMS SignedData syntax since it was first published as RFC 2630. They also appeared in CMS’s precursor, PKCS #7 v1.5.

The SignedData syntax originally supported one type of status information, Certificate Revocation Lists (CRLs). RFC 3852 made the status information types extensible and RFC 5940 formally added Online Certificate Status Protocol (OCSP) responses.

A benefit of “stapling” the status information in a SignedData syntax is that the email recipient doesn’t need to look up the certificate status itself; the SignedData object provides it directly.

In addition to stapling, applications can take other architectural approaches for obtaining status. For example, an application could look up status information based on the AuthorityInformationAccess extension in the certificate. Or, an application could obtain status information in the background, as web browsers now typically do, as discussed in the previous blog post.

Regardless of whether status information is stapled in, looked up, or pushed out in the background, an important question remains: how does the freshness (or staleness) of the status information affect the risks of an application’s security decisions?

As noted earlier, Verisign’s new technical report introduces a formal evaluation framework for answering the question. The framework is based on two key concepts:

• The vulnerability window for a certificate, which is the period of time during which the certificate has been compromised yet potentially remains “trusted” by a verifier due to the verifier’s lack of awareness that the certificate’s status has changed; and
• The exposure cost, which is measured to assess both the risk and impact of a compromise. The more times the certificate is relied on during this window, the greater the exposure.

The secure email use case, one of several considered in the technical report, provides a good illustration of the framework.

Consider a scenario where a sender is issued a certificate at time t₀ that expires at time t_e, signs S/MIME secure emails with the corresponding private key, and where the certificate is compromised before it expires.

The evaluation framework models the compromise with a vulnerability window defined by four values:

• t_c, the time when the certificate has been compromised;
• t_d, the time at which the compromise of the certificate has been detected;
• t_r, the time at which the revocation of that certificate is initiated; and
• t_R, the time at which the relying party becomes aware of the compromise and the revocation becomes effectuated (“Remediated”) by the relying party software.

The framework is illustrated for the secure email use case in the figure above, taken from the technical report. In the graph, a vulnerability window, shaded in red, is overlaid upon a series of signed emails or “protections” dated at different times, shown in green. (The technical report “Origin Verification is Not Enough” discussed the difference between protections and origin authentication in more detail.) The exposure cost is the area of the intersection between the vulnerability window and the protections.

A few points may be helpful in understanding the model:

• Between time t₀ and t_c — before the compromise occurs — a recipient of an email claiming to have the sender’s signature makes either a “true positive” or a “true negative” decision about the email, i.e., a correct one, depending on whether or not the signature evidence passes cryptographic verification. These emails stay green.
• Between time t_c and t_R — after the compromise occurs but before a recipient of a given email becomes aware of the compromise — the recipient potentially makes a “false positive” decision, i.e., an incorrect one, when the signature evidence passes cryptographic verification.
  
  For decisions based on emails dated between t_c and t_R, the reason is obvious: an adversary may have had access to the sender’s signing capability during that time and may have forged the signature. But messages dated between t₀ and t_c are at risk too. The reason is that S/MIME does not directly provide evidence that the signing date is correct; it too may have been forged. These emails are shaded in red.
• Between t_R and t_e — after a recipient becomes aware of the compromise and until the certificate expires — the recipient makes a “true negative” decision about the email. Even if the rest of the signature evidence passes verification, the status information indicates that the certificate has been compromised and the recipient, correctly, doesn’t accept it. These emails stay green again because the decision is correct (not because the emails are valid).

The technical report proposes that the exposure cost, as a measure of area, can be expressed in a composite unit such as protection-days (pdays), where protections refers to the number of objects (e.g., emails) affected and days to the amount of time. If r is the number of emails sent per day, then the exposure cost can be calculated as follows, assuming for simplicity a constant rate of emails sent:

The technical report gives these examples for illustration:

• Certificate issued at t₀ = 0 days, expires at t_e = 365 days.
• Compromised at t_c = 182 days, detected 10 days later at t_d = 192 days, revocation initiated two hours later at t_r = 192.083 days.
• Emails rate limited to r = 70 per day.
• Scenario 1: Relying party becomes aware of compromise within one hour, so revocation effectuated at t_R = 192.125 days. Exposure cost = 132,581 pdays.
• Scenario 2: Relying party becomes aware of compromise within 12 hours, so t_R = 192.583 days. Exposure cost = 138,747 pdays.
• Scenario 3: Relying party doesn’t become aware of compromise, so t_R = t_e = 365 days. Exposure cost = 3,503,535 pdays.

Updating certificate status information for effectuation by the relying party software within one hour thus provides more than a 26-fold reduction in the exposure cost compared to not providing status information at all. The details will vary based on all the parameters.

The importance of this calculation is not so much the specific numbers but the fact that there are numbers to compare at all — that the risk is being quantified.

Once the vulnerability window and exposure cost are quantified in a particular deployment, the next step is to reduce the risk. The reduction may involve improvements in all three “gaps” within the vulnerability window: how long it takes for the compromise to be detected (t_c to t_d); how long it the takes for the revocation of the certificate to be initiated (t_d to t_r); and how long it takes for a relying party to become aware of the compromise and the revocation to be effectuated (t_r to t_R).

By delivering high-availability, at-time-of-use status information, Verisign Informed^TM can be part of the solution for the third gap, complementing organizations’ efforts to reduce the other two gaps to help close vulnerability windows, lower exposure costs, and enhance trust.