Back-doors, A New PKI Infrastructure and A New “Trust” Infrastructure for the Internet?

Back-doors, A New PKI Infrastructure and A New “Trust” Infrastructure for the Internet?

So what’s the core of trust on the Internet? Well, like it or not, it’s the PKI (Public Key Infrastructure). This involves the setup of trusted places to find Alice’s public key. So, could a nation-state decide to diverge from the global PKI infrastructure, and set up its own one? The implementation of sanctions against Russia at the current time may force Russia to diverge from the global trust infrastructure and setup its own one.

So what is PKI?

Within digital signing, Bob has a key pair: a public key (pk) and a private key (sk). When Bob wants to prove his identity to Alice, he takes a hash of a message and then signs this with his private key. He passes this and the message to Alice, and who then checks the signature and message against his public key (Figure 1).

But, how does Bob get his public key to Alice in a trusted way? Well, this is where PKI comes in, and where Trent takes Bob’s public key and produces an X.509 digital certificate that contains Bob’s public key. Trent then digitally signs this certificate with his private key. When the certificate is received by Alice, she will check the validity of the certificate by checking it against Trent’s public key. Trent’s public key is stored on her system in a trustworthy way (such as being installed by default). Once she has the certificate signed by Trent, she can use Bob’s public key to check his identity.

Within PKI, Trent can be the root CA (Certificate Authority) and is trusted to issue certificates with Bob’s public key. Trent thus has a high level of trust, and if Alice does not trust Trent, she won’t be able to validate Bob’s public key. Once we have the root CA, we can then create intermediary CAs, and which are trusted to create certificates for various applications, such as for TLS, email and hardware validation. These intermediary CAs thus need the root CA to approve them. Without their approval, their certificates will not be validated. This creates a chain-of-trust, with the root CA, trusting the intermediary CA to issue certificates. At any time the root CA can decide not to trust on of the certificates issued by an intermediary CA (such as where there has been a breach of their private key).

Can a country create their own root CA?

With increasing sanctions, Russian sites could be increasingly blocked from generating TLS certificates, and thus connections to their Web sites could fail. To overcome this, Russia is setting up their own CA infrastructure. But, as Let’s Encrypt has found, it can take a while to be trusted as a root CA, as the new CA will have to be vetted by a range of companies.

Currently there is currently little chance of the major browsers, such as Chrome, Firefox and Safari, actually trusting the new Russian CA, and so users may have to turn to the Yandex browser — as this browser currently accepts the Russian CA for the issue of digital certificates.

At present, the Russian Central Bank has a certificate signed by GlobalSign up to 2029:

Let’s Encrypt is also a popular signer of certificates in the Russian domain:

These certificates use a root CA of ISRG Root X1, and issue R3 certificates:

While many certificates of Russian sites are still valid, the risk is when these certificates run out, and where root CAs would not reissue a new certificate.

Will Chrome and Firefox accept?

It is possible for Chrome to add a certificate from an untrusted source, but this could lead to problems in the trustworthiness of the network connections, and leaves the opportunity of an Eve-in-the-middle for secure traffic. If this is detected, the browser could add the root certificate to a CRL (certificate revocation list), and which would mark the public key of the CA as being blocked. All of this points to a software infrastructure could be constructed from applications which run within their own trust infrastructure and create an alternative Internet.

A back door?

In order to create a secure TLS connection, Bob can use Alice’s public key to send back the key to be used for the secure tunnel between Bob and Alice. As we can see in Figure 2, Alie passes her public key to Bob, and who passes the secret key back to Alice, and who decrypts with her private key. This type of approach can lead to a back door in the communications between Bob and Alice, as someone holding Alice’s private key can discover the used for the encryption tunnel. This could risk all of the communications which use a compromised key pair to be listen in on the communications.

Conclusions

As many know, the TLS infrastructure allows for a back-door on network communications, and where the key exchange uses a private key which allows for the key used for the communications to be listened to. It will be interesting to see how this all pans out. One thing to note is that TLS 1.3 has stopped the usage of the key exchange with the key pair, and thus any implementation here for a back-door would possibly ban the usage of TLS 1.2. This would fossilisation all the software used.

Nothing can be proven at this stage for the intentions, and it could be that Russia just aims to minimise the damage on its Internet, but the opportunity to create a new PKI is there, but it would require a whole new setup. This, again, would diverge away from our existing protocol standards, and create a new Internet. It would be costly to implement, and possibly mean that the two could not work together, and in the way that the Tor network nees a Tor browser to properly integrate.