REGLA 177 PROCEDIMIENTO DE LANZAMIENTO DE PENALTI / LANZAMIENTO

In this section, we evaluate how CA-TMS reduces the attack surface of the Web PKI. When E1 uses CA-TMS, trust validation must succeed for a presented certification

path. Otherwise, validation services are queried and a potential attack is detected. Recall that A might block the access to validation services to prevent a definite detection. However, in such cases the connection is temporarily blocked and E1 is

informed about the suspicious certificate.

Trust validation can only succeed if the certificate is already a trusted certificate in E1’ trust view View or if the involved issuers are contained in View. Furthermore,

those CAs must be considered sufficiently trustworthy for the required security level of the application. Thus, A must compromise a CA with sufficiently high issuer trust in order to be successful.

Attacking a specific group of entities requires the compromise of a CA with a sufficiently high issuer trust in each of the group member’s trust views. The same holds when attacking a specific service. In this case, the relevant set of trust views are those of the group of service users. Otherwise, A risks an immediate detec- tion of the compromise when the validation services are triggered. As shown in Section 3.2, several past CA compromises have been detected in exactly that way where the compromised CA was not trusted by the Chrome browser. As trust views are specific to individual entities and not publicly visible, it is hard to identify such a sufficiently trusted CA. Even if the identification is possible, it is questionable if A can purposefully compromise that CA. In Chapter 5, a push service for CA warn- ings is presented to also protect entities whose trust view already contains the CA controlled by A as a trusted CA. The detection mechanisms is shown to be effective even if only a small fraction of the targeted entities does not trust the compromised CA.

Generally speaking, by the use of CA-TMS, A can hardly exploit accidental CA failures. The possible damage is reduced due to the limitation of the number of attackable entities accompanied by the increased compromise detection probability. Furthermore, with CA-TMS, the damage a compromised CA may cause highly de- pends on the CAs visibility in the certification business. The result of using CA-TMS is a much more natural setting than each existing CA being equally critical.

Measurement of the attack surface

The attack surface is individually reduced by CA-TMS by limiting the number of trusted CAs. The attack surface is a measure for the individual risk to rely on a fraudulent certificate. We measure the effectiveness of CA-TMS by adapt- ing the metric of Kasten et al. [41], which measures the attack surface as AS = P

CA∈PKIdom [CA], where dom [CA] is the number of domains which CA is allowed to

sign. PKI describes the set of all CAs which are part of the Web PKI. We adapt the metric to:

AS(View) = X

CA∈View

(bCA

1 · dommax+ bCA2 · dommed+ bCA3 · dommin)

with bCA

1 =

(

1 if for CA : E(okl,ee) ≥ lmax

0 else ,

bCA

2 =

(

1 if for CA : E(okl,ee) ≥ lmed

0 else ,

bCA

3 =

(

1 if for CA : E(okl,ee) ≥ lmin

0 else ,

where dommax, dommed, and dommin are the respective numbers of domains for

which the relying entity E1 requires a maximal, medium or minimal security level.

The input View represents the trust view of E1. A CA is contained in View, if

it contains the according trust assessment. Note that CAs not contained in View are not considered, as these are not trusted by E1 to sign any certificate. okl,ee =

okl,CA∧ oeeit,CA is the derived key legitimacy of keys certified by a certificate that was

issued by CA. The key legitimacy okl,CA of the CA’s key depends on the certification

path as described in Section 4.1.5.

Further it holds: dommax + dommed+ dommin = dom. dom describes the total

number of validly signed domains, i.e., for which a valid TLS certificate exists. Note that in our metric dom is not parametrized by the respective CA as the restriction of domains for which a CA is allowed to issue certificates is not considered. This is according to the current deployment of the Web PKI (cf. Section 3.1.3).

Attack surface measurements for real trust views

In the following, the reduction of the attack surface for the 64 trust views simulated based on the data sets collected in the user studies is presented. For all simulations,

the proposed parameter setting: lmax = 0.95, lmed = 0.8, lmin = 0.6, maxF = 0.8,

fix_kl = 3, and n = 10 is used.

The calculation of the attack surface of the Web PKI in the system-centric setting is based on the number of 1,590 CAs observed by Durumeric et al. [17]. With the system-centric trust model for the Web PKI, all CAs are trusted for signing certificates for any domain, thus AS = 1, 590 · dom, which equals the attack surface computed with the original metric from [41].

The adapted metric enables the relative quantification of the reduction of the at- tack surface resulting from the use of CA-TMS with the above specified parameters. The relative attack surface for a trust view View is defined as:

ASrel(View) =

AS(View) AS .

Then, the reduction of the attack surface can be quantified as:

RedAS = 1 − ASrel(View).

The distribution of the domains to dommax, dommed, and dommin depends on the

relying entity’s preferences. Data about the distribution of security levels to domains is not available to us. The analysis is done for the three generalized cases where either lmax, lmedor lmin is assigned to all domains. We denote the respective relative

attack surfaces with ASrel(View, lmax), ASrel(View, lmed) and ASrel(View, lmin). In

these cases, the relative attack surface results as the quotient of CAs in the trust view that can issue certificates for the given security level, divided by the total number of CAs of the Web PKI. Further details about the data sets can be found in Tables 1 and 2 in the appendix.

For the 64 analyzed trust views we found 0 ≤ ASrel(View, lmax) ≤ 0.028, 0 ≤

ASrel(View, lmed) ≤ 0.049 and 0 ≤ ASrel(View, lmin) ≤ 0.057.

The minimum numbers result from the least evolved trust views where nearly no CAs are trusted. In most cases this results from short histories and the related low number of observed hosts. However, considering the 48 trust views resulting from browsing histories with a minimum length of six months only slightly increases the minimal relative attack surfaces to 0, 0.001 and 0.001. The averages for these 48 trust views are AS_relavg(View, lmax) = 0.009, AS_relavg(View, lmed) = 0.019 and AS_relavg(View,

lmin) = 0.026.

This shows a reduction of the attack surface of at least 94.3%, even for the security level lmin. On average, a reduction of 97.4% is achieved in our data sets.

To generalize these results, the relative attack surface is evaluated depending on the number of observed hosts. The attack surfaces for the different security levels

0 0.01 0.02 0.03 0.04 0.05 0.06 0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000 R el ativ e at tack su rf ace

Number of observed hosts lmax lmed lmin

Figure 4.6: ASrel(View) for security levels lmax, lmed and lmin. (Real data.)

0 0.01 0.02 0.03 0.04 0.05 0.06 0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000 R el ati ve at tack su rf ace

Number of observed hosts Attack surface comparison

lmax lmed lmin

Figure 4.7: ASrel(View) for security levels lmax, lmed and lmin. (Extrapolated for host numbers larger than 466.)

are measured during the simulations after each observation of a new host. The resulting attack surfaces are then averaged over all simulated trust views. The results are shown in Figure 4.6. It shows an under proportional growth depending on the number of different hosts that are accessed via TLS secured connections.

The gaps within the graph result from trust views ending with the according number of observed hosts. Thus, the results for the high numbers of observed hosts depend on a low number of trust views. In our data sets, only 7 trust views contained more than 466 different hosts. Furthermore, the results for more than 639 hosts are based on a single trust view with 1013 hosts in total. This trust view also formed an upper bound for the number of observed CAs. Thus, the averaged results for high numbers of observed hosts are biased towards a larger attack surface. To have an estimate for the average relative attack surfaces, the data from the measured values below 466 observed hosts is extrapolated. This is depicted in Figure 4.7.

The extrapolation is done with an exponential estimator. The average rate of change was computed with a sliding window of size 50. The resulting curve was approximated with an exponential approximation function, which was used to ex- trapolate values of the attack surface for more than 466 hosts. Figure 4.7 shows that the relative attack surface on average stays below 0.05 even for the security level lmin.

The reduction of the attack surface comes at the cost of querying validation ser- vices whenever new CAs are observed or not enough trust experiences have previ- ously been collected. In the next section we show, that the rate of reconfirmations is kept in an acceptable range and does not interfere browsing in practice.