A game changer technology - Quantum Security Series - Part 1
Reading time: 14 minutesIt's 3 a.m. and there's an odd latency increase that lags all your web services. Your cloud provider says "it's all good", your Internet Service Provider has no obvious issues, but something is wrong with the path… then after 15 minutes your entire traffic suddenly and magically returns to normal, latency dropped and somehow there wasn't any service disruption.
Everybody scratches their heads, wondering what just happened.
Your entire IP space was re-routed without notice—luckily your SOC team was monitoring the whole event. You were the victim of a BGP hijacking maneuver, but why? How? For what purpose? And then you remember the important set of classified data that was going to be transmitted exactly at that time.
'This doesn't seem like an effective attack!'... you think. All communications are encrypted, eavesdropping would be nonsense… or would it ?
What if the attacker had enough computing power to break your encryption, decipher all communications and extract your precious data set? Such an attack would look like this:
The attacker-group (while this attack could be easily crafted by one individual, the possibility of achieving quantum power isn't very likely) could inject new routes to some ISP router along the path. Once the injection is made, the victim's IP range traffic is subtracted from its legitimate route and re-routed to the attacker premises. That's where they sniff it and forward it to the correct endpoint to be as stealthy as possible.
While this could sound far from realistic, there are claims that this has been happening for quite some time. For the benefit of the doubt, let's provide some information regarding this type of attack to give you added insight:
- BGP hijacks happen all the time, especially to rather small and really big ISP's, where routes are not filtered properly. Despite efforts like RPKI BGP route validation, they still occur.
- Quantum-powered cryptanalysis of bypassed internet traffic has been reported several times in different situations and media, alongside with various techniques like packet injection.
- Governments are publicly racing against each other for the quantum computation advantage, so we can just imagine what is and has been done behind the scenes.
So what is "quantum computing", and what changes will be needed in the (possibly) near future regarding traditional IT security? That's what we intend to address in our Quantum Security Series. Let's dive in!
- What is quantum computing?
- How does this affect your system's security?
- Post-quantum protected SSH
- Summary
What is quantum computing?
Quantum computing is the next big thing. This brand new technology comes with a lot of promise and while some say it's still in its infancy, breakthrough progress has arrived on the scene.
Basically, it's a new computation model that replaces the traditional use of transistors for atomic particles in order to allocate information states. Quantum mechanics properties such as "superposition" and "entanglement" are used to augment the way we compute.
Multiple implementations of quantum computers take advantage of subatomic particle's properties, such as the "spin" of an electron-proton-nucleus, or characteristics like "photonic polarization" where a determined state can be measured after a desired process.
Some general implementations of quantum processor units (QPU) are:
Transistors let us store information by using a binary approach (states can be 0 or 1), while quantum objects can allocate a superposition of those two states for every register until measured. When measured, the state must escape superposition state and become a unitary option—let's say spin up or down, polarization vertical or horizontal, etc.
Those states are equiparated to a binary notation, for example a spin up (↑) to 0 and a spin down (↓) becomes 1, which completely change the way we look at computation are the superposition (⇅) and entanglement between particles. This allows you to have the orchestration of multiple states at the same time which gives the ability to compute more information exponentially faster.
To differentiate these new units of information that can be in different states from the classical "bit", the term "quantum bits", or "qubits" for short was invented.
Why is it needed ?
One of the most frequently mentioned reasons for pursuing quantum computer power is the fact that Moore's law prediction is reaching an end. This law implies that approximately every 18-24 months the amount of transistors within a computer chip is doubled, and therefore the computational power of a central processor unit (CPU) is doubled.
While scientist have been working on solutions, quantum tunneling (as mentioned in the above video link) is the phenomenon that probabilistically allows particles to travel through barriers, which would create a major limitation in the current classical model because it's not possible to increase computing power by shrinking transistors size and placing more of them inside a CPU chip.
Another approach is that to simulate quantum particles behaviour and objects such as molecules, atoms, etc, the amount of computing power needed super-exceeds the ones that could be created with traditional transistor-made processors.
How does this affect your system's security?
Cryptography relies on difficult-to-solve problems to secure the assets it intends to protect. If at any time those problems become easy to solve, secrets are no longer safe and the encryption algorithm is useless. This concept is not alien to the cryptography community, as it is a phenomenon seen several times in the past. It's all "part of the game" for the community to stay ahead and develop new and more resistant algorithms.
Despite this fact, it's paramount for systems administrators to properly maintain their services and remove old and weak ciphers from production environments. This not only affects hard disks or database encryption but also disturbs:
- Secure communications (chats, VoIP calls, video calls)
- Secure emailing (pop3, imap, smtp, webmail)
- Secure web browsing, e-Banking, almost anything using HTTPs
- IoT, cloud services, etc.
- VPN, SSH, remote desktop apps and more
You name it, all currently secure data exchange could be compromised if captured in the future.
Post-quantum cryptography
The goal of post-quantum cryptography is to develop cryptographic systems that are secure against both quantum and classical computers and can interoperate with existing protocols and networks.
Where lies the real risk?
It's not our intention to scare you as a reader, but there have been several reports over the years about the multicudinary techniques utilized by multiple actors to illegitimately read information. BGP hijacking, as mentioned earlier, is one of them—but there are plenty, and with no lack of creativity.
Examples include:
- Optic fiber tampering at submarine cable infrastructure
- Countrywide BGP IP range hijacking
- Tor network endpoint takeovers
- Stealth chips along networking and server hardware
- Stealth software within a device's firmware
- Encrypted communication channels analysis and exploitation
- The quantum computing power race, which could soon break current cryptography
After reading this, one can solidly picture that our information could be captured at some point with or without our provider's involvement. Information has been captured and stored for ages, just waiting to be decrypted. As an example, let's take a look at the first event listed: submarine cable tampering.
Currently, the submarine cabling allowing communication to countries and continents across the globe looks like the picture below. And reportedly, different governments and agencies have created teams to stealthily connect and store traffic information.
Source: http://submarinecablemap.com
Some companies have taken the next step and developed special technology to meet this market's demands. This kind of equipment subtracts signals from terrestrial or submarine optic fiber cables, without disturbing normal operations, and repeats signals to a rogue monitoring hardware:
Source: Wikileaks.org
To summarize, information can be captured and then archived, but how are your actual encrypted communications going to be broken by quantum computing? Say hello to Shor's algorithm.
Quantum-efficient encryptions key-breaker algorithm
Shor's algorithm was invented in 1994 by American mathematician Peter Shor. It's a clever way to factorize integers exponentially faster using a quantum computer.
With attackers using this algorithm, weak prime-number-based encryption is compromised easily once enough computing power has been reached, especially regarding asymmetric cryptography algorithms, such as RSA.
Additionally, some of these algorithms are currently vulnerable to successful cryptanalysis attacks due to weak key lengths. A more in-depth explanation of the mathematics behind how Shor's algorithm works can be found in this link.
But how far are we from working with it? You can see in the image below a picture taken from a Microsoft Research team video, showcasing a quantum computing quest. There you can clearly see on the first line of code the test of a function designated __Shor() which attempts to find the factors of the number 15 using a quantum computer simulator. As this exists, there are several implementations from different vendors and developers using quantum computing languages such as IBM's Qiskit and QASM, among others.
Source: The Race For Quantum Supremacy
How can we protect ourselves from these crypto-attacks?
To efficiently protect your systems from this risk today, we must look upon stronger traditional encryption algorithms suited to solving a very difficult problem.
We may rely on a different solution in the near future, when quantum cryptography becomes publicly available. Until then, let's showcase the use of a quantum-safe SSH tunnel as an experimental secure communications channel.
Post-quantum protected SSH
Secure Shell (SSH for short) is a protocol used for the remote login and control of devices. OpenSSH is its most popular implementation, the most commonly used open source software in the world.
Having said that, you can imagine that securing SSH connections is extremely important. Let's dive into the handshake process to make it easier to understand this crypto-ecosystem:
Client and server exchange different keys and algorithms to establish a proper connection. Here are protocol details:
-
TCP protocol 3-way handshake - Using the familiar SYN > SYN-ACK > ACK sequence; data will flow between devices after this initial handshake.
-
SSH protocol handshake - Both client and server will tell each other which version of the SSH protocol they are using; in our case the protocol version is SSH2.
-
Key exchange handshake - We'll manipulate KEX algorithms in this example; they generate per-connection keys to securely communicate secrets.
-
Host key authentication - This allows client-server authentication using a private key for the client to sign and a public key on the server to verify it.
-
Stream ciphers - These are the allowed symmetric encryption algorithms used to secure communications during the entire session until disconnection occurs or rekeying is in place due to key expiration.
-
MAC codes - These are the message integrity check methods used to prevent stream modifications from going undetected.
-
Compression algorithm - While this is not listed, the next step is to exchange compression protocols to shrink the size of the packets sent.
A network capture of this stream of events should look like this:
Focusing on OpenSSH software, it's important to note that since version 6.9 it includes chacha20-poly1305 as the default stream cipher, which possesses a 256 bit key and, according to the crypto-community, offers stronger security and better efficiency than AES-256. That said, both algorithms are considered quantum-safe.
OpenSSH, since version 8.0, includes an experimental new algorithm to exchange keys between hosts and allows quantum protection of key exchange.
So to further emphasize the importance of this introduction, we should clarify that:
-
Asymmetric encryption algorithms are the most affected by quantum attacks, and as post-quantum ciphers are still under review by the cryptography community, they're used in combination with another protocol (and quoting OpenSSH release changelog "..experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519").
-
Symmetric encryption algorithms are less vulnerable to attacks but as secret key exchange must be highly protected, the use of asymmetric encryption to exchange keys must be reviewed and improved. Algorithms such as AES-256 or chacha20-poly1305 produce sufficient difficulty to be quantum-safe at the time of this writing.
Great, so we now have a quantum-safe asymmetric algorithm to exchange keys and a symmetric quantum-safe algorithm to secure communications. Let's configure OpenSSH so we can use them.
First we verify the presence of the KEX quantum-resistant algorithm in our system by querying SSH:
~ # ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curv[email protected]
[email protected]
We should note the "[email protected]" algorithm on the last line, and then we can test communication with the server using the following command:
~ # ssh -v -o 'KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org' user-name@server-name
Note that if you get the following message, it's because this KEX algorithm is not enabled on the server side. We need to configure our sshd_config file to use it:
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: (no match)
Unable to negotiate with server-name port 22: no matching key exchange method found.
Their offer:
curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
To make this work, we'll need to add the following line within /etc/ssh/sshd_config:
KexAlgorithms +sntrup4591761x25519-sha512@tinyssh.org
Once this is done, we must reload our SSHD daemon and it should be ready to work. Let's try again and verify what the debug log shows us:
~ # ssh -v -o 'KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org' user-name@server-name
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to server-name [127.1.2.3] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.1
debug1: match: OpenSSH_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 127.1.2.3:22 as 'user-name'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20[email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20[email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
[...]
debug1: rekey in after 134217728 blocks
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp52
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).
[...]
And that's it! Now your SSH connection should be a bit more secure than it was a few moments ago (if you want to browse additional SSH hardening tips, check out our article about Securing SSH). In case you want your SSH client to use this experimental quantum-safe KEX algorithm as the default, simply modify your /etc/ssh/ssh_config or ~/.ssh/config file with the following contents:
Host *
KexAlgorithms ^sntrup4591761x25519-sha512@tinyssh.org
This will allow your client to try this algorithm first. If it's not available on the server, it falls back to available algorithms, such as curve25519-sha256.
Summary
Quantum computing is an amazing discipline that is now beginning to show how much we can change the way we do things in this world. It changes the way we can simulate the interaction of health and wellness drugs in patients, how we can design more resistant materials, how we can create new devices to improve the way we live.
While this is all very promising, we aren't yet sufficiently informed about how to interact with this technology. Companies developing devices in this area are seeking new problems that could be solved with quantum computing, as well as algorithms that could take full advantage of its potential processing power.
Secure communications, application methods, data protection and threat intelligence strategies are just a few of the areas that stand to evolve significantly.
We merely need to be patient, to witness and even become part of the "quantum computing revolution"!
In the meantime, feel free to continue reading the next chapter of this fascinating quantum computing security series: Random and Mysterious - Quantum Security Series - Part 2.
Are you worried about how much of your company's data is exposed to the Internet? SurfaceBrowser™ is the ultimate surface analyzer, that lets you detect and inspect your entire online infrastructure from a single interface. To learn what else we can do for you and your company's security, contact our sales team and schedule a call today!
