5.3 Push service for behavioral changes of CAs
5.4.4 Push service evaluation
In this section the proposed push service is evaluated in terms of success probabilities of an attacker. We compare the system-centric setting with the user-centric setting without and with the push service and show the security gain by such a service. First, the detection capability for behavioral changes of our system depending on the class of the compromised CA is evaluated. Based on these findings, the success probabilities of an attacker are presented.
Detection of behavioral changes
The performance of the detection mechanism is evaluated in terms of successfully attacked entities until the service provider SP detects the maliciously issued certifi- cate due to reports send by its clients. For the analysis we consider an attacker A according to the attacker model given in Section 3.1.2. A possesses a fraudulent certificate C for the web service S issued by CA. A uses C to attack relying entities when connecting to S. Thus, we consider the users of S as the target group G of attacked relying entities. A could also attack several web services in parallel, yet this would only increase the size of the target group. Thus, for the analysis we assume, that A only attacks one web service at a time.
Let q be the percentage of entities G that consider CA as trustworthy to issue certificates for S in the user-centric setting. Trusting CA to issue certificates for S means that CA reaches a sufficiently high issuer trust for end entity certificates in the respective trust views. We call q the trust rate. Then, the probability that for entity E∗, randomly chosen from G, trust validation outputs trusted for C is q and the probability that it outputs untrusted and E∗ subsequently reports the attack to SP is (1 − q). Thus, the probability that the n-th entity detects the fraudulent certificate when connecting to S is prdet(n) = qn−1· (1 − q). The expectation value
for the number of successfully attacked connections to S until a detection occurs, can be computed as:
Expcon = ∞ X n=1 prdet(n) · n = ∞ X n=1 qn−1· (1 − q) · n = 1 1 − q 2
From this follows, that given q per cent of the entities trust CA, A on average can successfully attack Expcon − 1 = 1−q1 − 1 entities until the attack is detected and
reported to SP. Table 5.2 shows the average number of successfully attacked entities for different values of q. The numbers show that an attacker must compromise a CA that achieves a trust rate approaching one within the target group in order not to be rapidly detected. Even for q = 0.99 an attack is on average detected after 99 successfully attacked entities.
q 0.1 0.3 0.5 0.7 0.9 0.95 0.99
Expcon− 1 0.111 0.429 1 2.333 9 19 99
Table 5.2: Number of on average successfully attacked connections depending on q
2P∞ n=1q n−1· (1 − q) · n = P∞ n=1q n−1· n −P∞ n=1q n· n = P∞ n=0q n· (n + 1) −P∞ n=1q n· n = P∞ n=0q n·n+P∞ n=0q n−P∞ n=1q n·n = q0·0+P∞ n=1q n·n+P∞ n=0q n−P∞ n=1q n·n =P∞ n=0q n= 1 1−q
p lmin lmed lmax ≥ 0.1 82 (26.8%) 63 (20.6%) 30 (9.8%) ≥ 0.2 57 (18.6%) 42 (13.7%) 24 (7.8%) ≥ 0.3 40 (13.1%) 29 (9.5%) 15 (4.9%) ≥ 0.4 30 (9.8%) 16 (5.2%) 9 (2.9%) ≥ 0.5 19 (6.2%) 13 (4.2%) 8 (2.6%) ≥ 0.6 16 (5.2%) 11 (3.6%) 5 (1.6%) ≥ 0.7 12 (3.9%) 7 (2.3%) 2 (0.7%) ≥ 0.8 7 (2.3%) 4 (1.3%) 0 (0.0%) ≥ 0.9 0 (0.0%) 0 (0.0%) 0 (0.0%)
Table 5.3: Number of CAs (per cent of total) for which at least the trust rate q is reached for different required security levels for the attacked web service. The percentage refers to the CA super set of 306 CAs found together in the analyzed 64 trust views.
Table 5.3 shows how many CAs achieve a certain trust rate q in our data set of 64 trust views. The super set of CAs found together in the 64 trust views contains 306 different CAs. For example, it can be observed that if entities require a security level lmin for S, then only 26.8% of the CAs in the super set reach a trust rate of
q ≥ 0.1. For lmax this even shrinks to 9.8%. None of the CAs reaches a trust rate
of q = 0.9. Additionally, all CAs not contained in the super set are not trusted by any entity in the target group. Thus, a fraudulent certificate issued by one of those CAs would be immediately detected. In summary this shows, that in practice, it is very improbable that A can identify and compromise a CA that achieves a high trust rate in the target group, which would prevent an immediate detection of the attack. Even compromising the CA which issued the legitimate certificates for the S is no guarantee for a high trust rate, because the trust views of the attacked entities might lack additional positive experiences for this CA for other web services.
Attacker success probabilities
The success probability of A is evaluated based on the trust rate q of the CA from which A obtained the fraudulent certificate. In the previous section it was shown, after how many attacked connections the attack is detected on average. With the use of the push service, A’s success probability depends on the number of attacked connections and drops to zero once the attack is detected. Most important, this bounds the absolute number of entities that can be successfully attacked independent from the size of the target group.
depends on q, while the success probability in the system-centric setting is 100%. This is depicted in Table 5.4. The evaluation concerns the time period between the issuance of the fraudulent certificate and its revocation, from which on the certificate cannot be used for an attack in any setting. However, while a revocation of the fraudulent certificate protects from the misuse of this single certificate, a warning by the push service leads to suspending the CA, which means further fraudulent certificates issued by the same CA will also be detected.
Setting: system-centric user-centric user-centric with push
service
Success probab. 100% q qn
Table 5.4: Success probability for an attack depending on q reached by the CA that issued the fraudulent certificate. n denotes the number of entities A has attacked prior to this attack.
5.5 Conclusion
To conclude this chapter we summarize the results. Service providers for CA-TMS realizing a reputation system and a push service for CA warnings were presented. The services have been evaluated in terms of security and performance. It was shown that the reputation system speeds up the information collection and thus the bootstrapping by more than 50% while only minimally increasing the attack surface by less than 1% compared to the strictly local information collection. Differences in trust views resulting from the use of the reputation system fade out, the more evolved a trust view becomes. This shows, that the reputation system fastens the evolution of trust views while not changing their individual character. Traffic overheads are kept at a low rate of approximately seven requests per month on average per user of the reputation system. These requests are non-blocking and thus do not lead to any delays during browsing.
The presented push service solves the problem of relying entities making decisions based on outdated information in case a CA changes its behavior from trustworthy to untrustworthy. It was shown that the presented detection mechanism is capable to detect maliciously behaving CAs, even if a majority of relying entities already trusts the CA in question. Moreover, the push service puts an absolute bound on the number of entities that can be attacked until the attack is detected. A detection
leads to an immediate warning of the relying entities and the elimination of the threat. For our test group of Internet users, the analysis showed that there does not exist a single CA which is trusted by at least 90% of the group members. This illustrates the detection and attack prevention capability in practice. Even a trust rate of 90% in the target group of the attack on average leads to a detection after 9 attacked entities.
In summary, the proposed service providers highly improve the user experience of CA-TMS because of the speed-up of information collection and thus the prevention of delays and the reduction of the dependence on external validation services. At the same time, service providers impose strong security benefits by adding highly effi- cient detection mechanisms for fraudulent certificates and the subsequent prevention of attacks.
In this chapter, we present a solution for the too-big-to-fail problem of CAs. This problem refers to the impossibility to revoke the key (and the according certificate) of a large CA, even if actually required from a security perspective. In public key infrastructures, revocation of a certificate is required whenever a key needs to be invalidated before the end of its validity period. For example, in order to prevent misuse when a key was compromised. However, the revocation of a CA’s key subse- quently invalidates all certificates that contain the revoked key in their certification path. This in turn means, that all services using such an invalidated certificate for authentication become unavailable until their certificates are exchanged by new ones. In many scenarios, such a temporal unavailability of services is not acceptable and thus, either requires that the revocation of a CA key is considerably delayed or even completely avoided. In Chapter 3, it was shown that this behavior is a huge problem in practice and leads to security flaws.
In Section 6.1, we present a solution to the too-big-to-fail problem of CAs. The problem is solved with forward secure signature schemes (FSS). FSS provide a (par- tial) chronological ordering of the signatures generated with one key. It is guar- anteed, that even an adversary that compromises the key cannot manipulate the ordering of previously generated signatures. This property allows to revoke a key without invalidating former signatures, thus the unavailability of dependent ser- vices is prevented. We provide the concepts and implementation details concerning changes in the standard path validation and revocation mechanisms and protocols. We show how to implement the solution in the Web PKI in Section 6.2.
In Section 6.3, the solution is evaluated in regard to practicality. For the evalua- tion we use a reference implementation of XMSS [12], a hash-based FSS. It is shown that our solution provides good performance and practical data loads by present- ing runtimes as well as certificate and signature sizes. These are compared to the standard setup where common signature schemes like RSA or (EC) DSA are used. Furthermore, we compare our solution to an alternate approach based on time- stamps and show that time-stamps are not a viable solution to the too-big-to-fail
problem. Section 6.4 concludes this chapter.
The contributions of this chapter were published as parts of [B10]. The publication covers the theoretical results presented in Section 6.1. This chapter extends these results with implementation details and an evaluation regarding the practicality of the solution.
6.1 Realizing CA revocation tolerance with forward
secure signatures
In Chapter 3 it was shown that the too-big-to-fail problem results from the implicit revocation of all certificates that rely on a revoked CA certificate, i.e. that have the revoked CA certificate in their certification path. To resolve this problem, revocation of CA certificates and the according revocation checking must be realized such that legitimately issued certificates stay valid despite a revocation of superordinate CA certificates. This requires the possibility to securely distinguish between legitimate signatures and such generated by an attacker who compromised a CA’s private signing key. We call a PKI that realizes the property of preserving the validity of legitimately issued certificates in the face of CA certificate revocations a CA revocation tolerant PKI.
In the following, a CA revocation tolerant PKI is achieved by replacing the con- ventional signature schemes used for certificate signing by forward secure signature schemes (cf. Section 2.1.2) in combination with an adapted version of the chain model for path validation. End entities further use conventional signature schemes, such as RSA and (EC) DSA, to minimize the deployment efforts. For authentica- tion purposes, one does not gain a benefit from using FSS because signatures are in general verified in close temporal proximity to signature creation. An extension of the CA revocation tolerant PKI to FSS also being used by end entities in scenarios where non-repudiation is required is presented in Chapter 7.
An exemplary certification path given a CA revocation tolerant PKI realized with an FSS is shown in Figure 6.1. In each certificate an FSS public key is certified except for the end entity certificate. The signatures on all certificates are generated using the FSS.
In the following, we present the solution in detail. First, it is explained how FSS enable to securely distinguish between legitimate signatures and such generated by an attacker. Then, fine grained revocation is presented, which makes use of the FSS’ special properties during the revocation of a certificate. Finally, we present the adapted version of the chain model for path validation.