# A Blockchain based PKI Validation System based on Rare Events Management
## 2 Attacks to PKI  
PKI is exposed to risks due to potential failures of certificate authorities (CAs) that may be used to issue unauthorized certificates for end-users. Many recent breaches show that if a CA is compromised, the security of the corresponding end-users will be in risk. There are many cases where a CA's errors or breaches have resulted in unauthorized certificates being issued. One of the most famous events is the security breach of Dutch CA operated by DigiNotar, which resulted in the company's infrastructure being used to issue hundreds of fake digital certificates for high-profile domains, including a certificate for \"google.com.\" After more than 500 fake certificates were discovered [6], web browser vendors were forced to blacklist all the certificates issued by the DigiNotar.  
Some other security incidents have shown that CAs do not need to be breached at all. For example, in early 2012, TrustWave admitted to issuing a CA signing certificate to one of its corporate customers, allowing the customer to eavesdrop on all communications (even HTTPS) from its internal network [7]. Although TrustWave has revoked the certificate and stated that it will no longer issue subordinate root certificates to customers, it illustrates just how easy it is for CAs to make mistakes and how severe the consequences of those mistakes might be.  
In 2012, TurkTrust mistakenly issued two CA signing certificates instead of end-entity certificates (which cannot issue further certificates), allowing the holders to issue rogue certificates for Google [8].  
Another important weakness of PKIs concerns the reliability and security of certificate revocation lists (CRLs or associated OCSP servers), which are used to ensure proper lifecycle management of certificates, particularly the revocation, and should be queried any time a certificate is used. Classically, the CRL for a set of certificates is maintained by the same (and sole) certification authority (CA) that issued the certificates, and this introduces a single point of failure into the system. On the Internet, a client browser reads the CRL address in the server certificate that it must verify; a fake certificate will contain a coherent fake CRL address. The second critical point about CRLs is the speed of CRL updates. In fact, CRLs do not operate in real time; they are commonly updated periodically by the issuing CA, and there may be a delay between a security breach and the subsequent CRL update, resulting in the temporary use of compromised certificates. The theft of a certificate (with its associated private key) could be unknown to the CA, and the certificate is not revoked in this case. We will show that this situation can be managed and solved using our approach.  
The discussed weaknesses have also been exploited in \"man in the middle\" (MITM) attacks. Usually, web servers offer their services using a Transport Layer Security (TLS) secure channel without mutual authentication. There are two ways to carry out MITM attacks: to obtain access to a fake web server certificate (containing the same domain name as the original web server), issued by a trusted CA, or to directly create a fake CA certificate and put it in the list of trusted CA certificates stored on the computer of the user under attack. Most browsers allow users/programs to do this. There are two troubling aspects linked to these attacks: Client credentials can be read and memorized, and re-used later on by the attacker.  
Finally, when detecting an anomaly in a server certificate, the browser warns users that the website's digital certificate is not valid and recommends not visiting the website itself. However, the user can ignore the warning, rendering this anomaly handling system weak.  
Table 1 contains a summary of attacks grouped into classes, where the class represents the attacked entity.