Enterprise Best Practices
Principal Architect
September 4, 2019
Hello, and welcome to the second installment of the Enterprise Best Practices Blog. My name is Neil Danilowicz, Principal Architect for Versa Networks. This week I would like to focus on Keys – their importance to SD-Wan and why an Enterprise should be concerned about the keys.
As we all know, every Enterprise has both public and private information. And it is the duty of the Enterprise to protect private information, be it intellectual property (IP), financial information, customer subscription information, payment history, or other information that must be protected due to regulations (both industry standard and governmental).
Protecting information is not a new concept, we have been protecting secret and confidential information for centuries. In fact, Julius Caesar was so worried that the communications between himself and his generals would be intercepted by the enemy, that he created a method of encrypting his messages. This became to be known as the Caesar Cipher. The cipher worked by utilizing a letter offset in the Roman alphabet. By knowing the cipher key (offset), one could encrypt and decrypt a message, like “I will arrive tomorrow.” But the encrypted message would look like the example below.
The problem with the Caesar Cipher is that it was very simplistic in its design. Both sides needed to know the key (the cipher offset) and there were only 23 unique values for this key. It would take a human between 15 minutes to an hour to work through all the possible combinations to decipher the message. Today, using a personal computer (PC), it would take less than a second.
So if cipher keys are so important to encrypt messages, what attributes should be utilized to make them secure and complex enough such that any compromised endpoint cannot reveal the key, and the hackers (threat actors) would be unable to guess or use modern compute techniques to derive the key?
First, obviously making a longer key (at least 128 bits and preferably 256 bits in length) would help solve the probability of a hacker (threat actor) from being able to guess the password. But length is not the only solution. Brute force attacks can run through millions of combinations in a second. So clearly, something more than key length is needed.
Second, storage of the key in an unencrypted form would allow a hacker (threat actor) to gain access to the keys if a device were compromised. So, network equipment utilizes hash algorithms to morph the key into a value that can be later be un-hashed and utilized. However, if the hacker knows the algorithm for hashing or the algorithm has a vulnerability, then the key can be exposed as well.
Asymmetrical key exchange creates a more secure connection as a Public Key is created and then shared with the other side of the connection. The other side utilizes the public key to encrypt the data, but the public key is insufficient to decrypt it. A private key of the receiver is needed to decrypt the information. However, if a device is compromised and the private key is readable, then the security risk still exists.
Use of a Trusted Platform Module (TPM) can mitigate this risk by making the private key unreadable. Tampering with or attempting to break the TPM would invalidate the private key and render the device unusable. This works very well with hardware based platforms which have integrated a TPM chip into the product. However, in a virtualized world, there is no secure way to protect the private key from discovery on a virtual machine.
A more secure solution would be to only exchange part of the key and have an algorithm that could validate the partial key utilizing negotiated terms and elements that are secret to each device. In this manner, no device would have all pieces to re-assemble the key. Therefore, the capture of keys from one device would not provide any usable means for unauthorized access to the enterprise network. Also, the key would never need to be stored and could be computed with each packet/flow that needed to be encrypted or decrypted.
In fact, this is the exact solution developed and utilized by Versa. Each node creates a key using two negotiated terms, a secret code (known only to that node) and the partial key from the other end of the connection. This then produces a unique secure key value which can be rotated by changing the secret code and the other side advertising their new partial key. This method even allows for asymmetrical encryption where a secure key value is utilized for the transmit traffic and another secure key value is utilized for the receive traffic.
Versa’s solutions utilizes secret codes that are at least 256 bits in length and negotiated values in excess of 1024 bits in length. Even if a hacker were able to capture all the necessary information, it would take a hacker more than the lifetime of the universe to gain access to the key. By that time the keys would have rotated and would no longer be useable.
So a secure key solution should be one of sufficient length to make it impossible to guess, one in which the full key is never exchanged, where the key is never stored and derived from extremely large values (both negotiated and secret), and rotated in a sufficient timeframe to prevent cracking.
Until next week, when we discuss why a secured multi-tiered architecture is needed to safeguard the Enterprise network.
