The use of codes and ciphers to protect secrets is probably as old as the human desire to communicate with each other and do so secretively and/or selectively when desired.
A Little History
The earliest known use of cryptography is found in non-standard hieroglyphs carved into the wall of a tomb from the Old Kingdom of Egypt circa 1900 BC. In India, encryption finds mentions in KatapayadiShankya or Mlechittavikalp. Ancient Greeks were no strangers to ciphers either, and the Caesar cipher, one of the simplest encryption techniques to credited to the Romans. Arabs are known as the first people to systematically document cryptanalytic methods.
Fast forward to the 20th century, it was the decryption of Germany’s Zimmermann Telegram that resulted directly in the USA jumping into World War I. More notably, it was the breaking of the Enigma code during WW II that shortened the war by 2 – 4 years and saved around 14 million lives.
Cryptography and Telephony
Till the 1990s, the use of cryptography was confined to its usage by men in power or by armies during wartime. With the Internet taking off, a common person could send/receive messages and conduct commercial and financial transactions over the network.
To add to this, the late 90s and early 2000s saw a rapid adaption of Voice over IP systems (VoIP) that used Session initiation protocol (SIP) instead of the Plain Old Telephone System (POTS)
With this, the need to encrypt text and voice traveling over the net became critical.
A brief history of SSL and TLS
Netscape formally introduced the SSL (Secure Sockets Layer) protocol in 1995, making it the first widely used protocol for securing online transactions between consumers and businesses.
Transport Layer Security (TLS) came later in 1999 when the Internet Engineering Task Force (IETF), an international standards organization, published its first version of the protocol.
SSL and TLS were essentially designed to ensure security and privacy for communication over the Internet. In the voice world, TLS is used with another protocol, SRTP (Secure Real-time Transport Protocol). TLS is used to encrypt the signaling of the calls, and SRTP secures the actual media or data packets.
Before we explore SSL/TLS certificates in depth through this series, let’s start with the basics.
The Basics of Encryption
Let us take a minute to quickly understand the basics of encryption. There are two types of encryption: symmetric and asymmetric.
- Symmetric encryption uses a single key for both encryption and decryption. Since the keys now have to be shared, there is a chance that they might fall into the wrong hands.
- Asymmetric encryption uses a combination of 2 keys:
- a public key to encrypt a message, and
- a private key to decrypt the message.
Both the keys are mathematically related. A public key is freely shared while a private key is used only by its owner.
Let’s take an example to understand how this works. There are two people, let’s call them A and B. A has his public and private keys. B too has his own public and private key. They know each other’s public keys.
Now A wants to send an encrypted message to B. So, the steps he would perform are as under
- A encrypts the plain text message using B’s public key.
- When the encrypted message reaches B, B uses his private key to decrypt the message and read it.
- Consider another person C, who got hold of the encrypted message sent by A to B. C cannot do anything with it unless he has B’s private key. If C has B’s public key (which is no big deal because anyway it is public), can he somehow derive B’s private key using his public key?
The answer is NO because the algorithms are designed such that it is almost impossible to computationally derive a private key from an existing public key.
As a software developer, it appears safe to always use asymmetric encryption and not bother about symmetric encryption. So, when a browser talks to a web server on HTTPS, this is what you would expect.
But the reality is that browsers use both asymmetric and symmetric encryption. Let’s break it down
- When you go to https://www.webserver.com, the webserver sends back its asymmetric public key.
- Your browser creates a new symmetric session key and encrypts it using the server’s public key shared in the earlier step.
- The server decrypts the encrypted session key sent by the browser using its private key.
- For the rest of the session, the browser, and server encrypt/decrypt data using the symmetric key generated in Step 2.
It is important to note these session keys are valid only for one session.
Asymmetric encryption is used at the start and for the rest of the session, a symmetric session is used.
Why? This is done mainly because the symmetric keys are short and encryption/decryption with these keys is faster and computationally cheaper.
Now that we know the basics of encryption and how SSL/TLS works in the browser, in the later articles of this series, we will discuss many more technical breakthroughs, policies, standards, and aspects of securing communication on the Internet.
About Assertion
At Assertion, we’re committed to helping companies see a direct impact on call answer rates, experience better integration of their voice channel data, and secure their customers and themselves from voice scams.
Assertion® SecureVoice™ gives you complete control and visibility into each incoming call and every outgoing call from your company. This means that you now can
- Increase outbound call answer rates by verifying your calls
without using third-party apps - Prevent vishing and impersonation calls on your customers
with live identity assurance capabilities integrated into your website or app - Secure your business, employees, and data from voice scams and attacks
by screening every incoming and outgoing call in real time
You can see all this in action – in your setup.
Sign up for a 30-day no-obligation trial of Assertion® SecureVoice™