Outline
Introduction to Uses of Cryptography on the Internet
Domain Name Systems Security Extensions (DNSSEC)
Why Care?
Why It's Not Popular
What Cryptosystems Does DNSSEC Use?
GNU Pretty Good Privacy
What Cryptosystems Does GPG Use?
Transport Layer Security
The Discovery of the SSL Stripping Attack
Blockchain Technology (Cryptocurrency)
Introduction to Uses of Cryptography on the Internet
In this blog post we explore famous protocols used to protect the security of Internet users. All of the protocols in the outline are now an industry-standard in the field of Network Security.
Domain Name Systems Security Extensions (DNSSEC)
Without DNSSEC you have no scientific means of disproving that a website is the true owner of a domain. Not even if you type the right domain on your browser.
Contrary to popular belief that padlock icon on your browser does not guarantee immunity against phishing!
DNSSEC is a protocol to help clients test if the server the client is connected to is the true owner of a domain name. It was invented when security developers realized hackers were corrupting DNS records of famous email providers to steer traffic to the attacker's website.
In general, DNSSEC defends against attacks where attackers try to overwrite the IP address DNS Recursive Resolvers or DNS Authoritative Name Server send back to the client.
Attackers can overwrite the IP address mapped to domains in Recursive Resolvers. These are servers that store the IP addresses mapped to domains. Clients request for the IP address for a domain from such servers as this is faster than expecting the client to go through the complicated steps to get the IP address from the website owner first-hand. Attackers can also overwrite the IP address for domains on the DNS servers owned by the website owner, which are called Authoritative Name Servers.
Why Care?
You can't be sure you are on a phishing site unless the server you are connected to passed DNSSEC tests--even if the site has Transport Layer Security enabled.
The latest Requests for Comments admitted less than 10% of the Internet uses it--even though it is still best practice.
Why It's Not Popular
There is no system to automate the complete deployment of DNSSEC as there is for TLS.
The Internet Security Research Group has launched its own program named Let's Encrypt to help automate the deployment of TLS certificates to websites free-of-charge. The Electronic Frontier Foundation has made a program named certbot that allows system administrators--people that manage the deployment of websites--to set up TLS once and forget. No such technology has yet been made for DNSSEC...for some reason.
Both of the above technologies were made free-of-charge to encourage adoption. The closest we have to the above is CloudFlare's Universal DNSSEC solution--but you have to be willing to use CloudFlare's DNS Servers and abide by their rules if you want to do so. If you want your own DNS server be prepared to cash out $200/month.
Of course CloudFlare wants to turn you into a paying customer. If you do not want to go the CloudFlare route like the most of us you still have to find a Domain Registrar that supports DNSSEC and protects its own site under DNSSEC. When I make REST API requests to my Domain Registrar I want to make sure I am talking to the people that own the domain for real. After a lot of searching I have settled with the German Domain Registrar one.com. They have good reviews on TrustPilot. Business walls like this have stopped people from adopting DNSSEC.
And even then all of your DNSSEC problems are not solved--your Domain Registrar has to support it.
What Cryptosystems Does DNSSEC Use?
Just as TLS relies on a chain of digital signatures to allow the client to verify the TLS certificate is authentic--DNSSEC does the same!
Take a look at programcryptography.com's DNSSEC chain-of-trust according to DNSviz.net:
DNSSEC also allows many of the same digital signature algorithms featured in TLS: RSA, ECDSA, ED25519, ED448, etc. Below is a full list by IANA:
Just as for TLS the most common DNSSEC algorithm is RSA-SHA-256 for websites that support it.
How DNSSEC Works
In a DNSSEC Chain-of-Trust, we first pay attention to verifying the DNS Root Server DNSSEC signature. Since the chain-of-trust begins with the DNS Root server, no other DNS server digitally signs the DNS Root Server's DNS Resource Records to bear witness that it is was signed with the authentic key. The DNS Root Server self signs its own DNS Resource Records and expects us the clients to trust that by default. So how do we know if we are speaking to the correct DNS Root Server and not some fake? There was a public DNSSEC Root Signing Ceremony by the IANA for the DNS Root Servers to sign the Key Signing Key. You can watch the latest video recordings on the IANA Youtube Channel here.
How DNSSEC Keys are Managed
It is best practice for a domain owner to have two sets of private-public keypairs: Key Signing Private/Public keypair and Zone Signing Private/Public keypair. The domain owner can sign the Zone Signing Public Key using the Key Signing Private key and store the Key Signing Private Key offline. If an attacker steals the Key Signing Private Key they can get away with forging DNS Resource Records of the domain without the real domain owner's permission!
The Zone Signing Private Key is used to digitally sign all DNS Resource Records. Unlike the Key Signing Private Key the Zone Signing Private Key can be stored on a computer or even online--ideally on a FIPS-140-2 Hardware Security Module. These are devices that are designed to safely store secrets for use by a machine.
You can verify the DNSSEC signatures for a domain's DNS Resource Records are correct by using the delv command line tool. Below is a photo of me fully validating the DNSSEC signatures for the DNS Root Zone:
In the above command line output pay attention to the RRSIG Resource Records. Next pay to the DNS Resource Record Type next to it. For instance for the line for "RRSIG NS" the signature verifies the integrity and authenticity of the NS records of the Authoritative Nameservers DNS Root Server. delv reports all Resource Records are properly signed.
So once the client verifies the DNS Resource Records of the DNS Root server were properly self-signed with the correct DNS Root Key Signing Key and Zone Signing Keys what next? Well, next in the DNSSEC chain-of-trust we must verify the digital signatures of the Domain Registry that owns the DNS Servers for the Top-Level Domain.
If we wish to verify the DNSSEC Signatures for programcryptography.com we should first verify the DNSSEC Resource Record signatures of the Root DNS Server. Next, we must verify the DNSSEC Resource Record signatures of the Top-Level Domain DNS Server. The following photo demonstrates how a client can do this:
And finally we can verify the DNSSEC Resource Record signatures for programcryptography.com--knowing that the DNS parent zones (DNS Root Server and DNS Top-Level Domain DNS Server) have been verified in the DNSSEC chain-of-trust:
Best Practices When Verifying DNSSEC Signature
Make sure you are using a DNS Recursive Resolver whom you trust if its not your own. The DNS Recursive Resolver can, in theory, betray you by giving you false answers. I use ProtonVPN and Private Internet Access's DNS Recursive Resolvers since I use their VPN services.
GNU Pretty Good Privacy
Back in the 1990s the United States required companies to insert trapdoors in the cryptosystems featured in their commercial products. This would allow the US federal government to see what you were hiding using a cryptosystem, citing it to be weapons of mass destruction--because math kills people.
Phil Zimmermann, the creator of Pretty Good Privacy, didn't think so. As he points out governments are managed by people--and people sometimes abuse their power. In the case of Pretty Good Privacy the law that required the trapdoor would allow the government to invade the privacy of others when it is wrong to do so. So he wrote a program that offered a suite of cryptosystems that would allow people to encrypt documents they send online to others. Recipients would be able to verify the integrity and authentic.
To comply with US laws, Zimmermann had to print the source code of the first version of Pretty Good Privacy in a physical book known as PGP Source Code and Internals and export it outside the US. This is how Pretty Good Privacy began to be used.
Today, businesses, whistleblowers, and software engineers rely on Pretty Good Privacy to ensure the information they receive from others is trustworthy.
The most common implementation of PGP is GNU Pretty Good Privacy. Werner Koch was inspired by a talk Richard Stallman gave on the importance of ensuring encryption is available in the US. To get around the legal ban for encryption at that time--someone had to develop PGP outside of that. Werner Koch decided he could do it. And he did for over 24+ years.
Werner Koch endured tough times to fund the project over the years. Thankfully, Stripe and Facebook have now pledged to each donate $50,000 annually to support Koch and his family--giving him enough space to improve the project.
What Cryptosystems Does GPG Use?
Many of the same ones that DNSSEC uses. Here is a full list from the version of GPG that I have on my desktop:
Here are a list of cryptographic hashes GPG supports:
The list of supported ciphers is rather long. The most important ones are AES, ChaCha20, and Serpent.
Transport Layer Security
Today, TLS is ubiquitous in Internet browsing. This is what stops people from seeing your credit card credentials when you pay for merchandise online. It ensures people cannot eavesdrop on your messages on social media. Without it--we should not be using the Internet.
As I said earlier the release of free-of-charge programs to automate the launch and maintenance of TLS for websites helped increase adoption.
The Discovery of the SSL Stripping Attack
In 2009, Moxie Marlinspike, a security researcher that is now known to be one of the co-founders of the Signal Messaging Project, gave a lecture at Black Hat announcing how it's possible to downgrade an SSL connection to a bare HTTP plaintext one.
Moxie published his tool SSLStrip to the world. Later, more advanced tools were made.
Today, TLS version 1.3 and future releases are designed to be resistant to the SSL Stripping Attack. So be sure to support it for your website like I did!
BlockChain Technology (Cryptocurrency)
Did you know the blockchain was not invented by Satoshi Nakomoto? It was invented by a team of Stanford Researchers. Haber and Stornetta invented the blockchain to help people verify the integrity and authenticity of timestamps for documents. Whoever Satoshi Nakomoto was or were took the idea of the blockchain and used it to to invent the world-famous peer-to-peer payment system that needs no bank: Bitcoin.
The Bitcoin Whitepaper explains it was invented to allow people to settle financial debts with each other without needing a bank and to resist government inflation. Bitcoin has a fascinating history. It all began with a string of emails sent by the anonymous Satoshi Nakomoto -- offering others the currency to anyone who would dare try it.
Hal Finney was one of the earliest adopters of the currency. Finney and Nakomoto practiced sending and receiving transactions.
How Bitcoin Works
Imagine you need to send a payment to someone. You do not want to use a bank. You made up your mind to use Bitcoin. How will the Bitcoin blockchain system ensure that you do not get to double-spend your money?
A Chain of Digital Signatures
When you send a payment to the Blockchain Network there are several pieces of information you need to upload. You must upload the source address the payment is coming from--which is a payment address you previously received money to. This will help the chain know that the payment came from a real person and was not made up. You must also upload the destination address. Of course, that is how the blockchain will keep track of where that money is transferred to! You also have to timestamp your payment--the date and time the payment was made. Finally, you digitally sign the Bitcoin invoice and send it to the Bitcoin blockchain.
Bitcoin Nodes and Bitcoin Miners
So how do you verify payments without a bank. Whenever you send a payment with Bitcoin or any other cryptocurrency you must upload your payment invoice to a blockchain node. These are computers that verify all payments on the Bitcoin blockchain--every last one made since the first coinbase transaction by Satoshi Nakomoto. So how does that work?
Nakomoto Consensus Algorithm
In the 1990's, Adam Back made a program called HashCash. It was not meant to be a digital currency. It was meant to be a technique to fight spam. The idea is that before an email server accepts an email the sender had to solve a puzzle. The puzzle was this: given a block of data the sender had to guess a number such that the SHA-256 hash had a specific number of leading zeros.
Bitcoin's Nakomoto Consensus Algorithm is a little different. A Bitcoin node collects transactions that wish to be verified. The Bitcoin code also retrieves the SHA-256 hash of the previous block of transactions verified to be authentic in the Blockchain. Why Bitcoin does this will be made clear soon. For now, know that this is called a block of transactions. The node must then guess a number that when appended to the block and then the block is hash results in a SHA-256 hash. All hashes generate numbers. The Bitcoin Blockchain system requires nodes solving the Nakomoto Consensus Algorithm to find a nonce such that the resulting SHA-256 hash is less than a threshold number.
The first Bitcoin node computer that solves this puzzle and uploads it gets awarded a Bitcoin coinbase transaction--a finite amount of Bitcoin assigned to the Bitcoin wallet of the person that owns the Bitcoin node that solved the puzzle. What is unique about coinbase transactions is that it does not rely on someone else sending you a payment.
The person that owns the Bitcoin node that first solved the puzzle is assigned the coinbase transaction out of thin air. This is how payments on Bitcoin can be truly anonymous--they have no transaction history!
The verified payment is broadcast to other nodes around the world. Said node verifies the puzzle solution is correct. When majority nodes confirm the puzzle solution for the block of payments featuring your payment is correct your payment is considered validated on the Blockchain. In reality, the same transaction is confirmed several times. This is done to prevent the sender from reversing the transaction.
The longer the chain of transactions the more difficult it is for someone to forge an illegitimate chain of blocks of transactions, or blockchain for short. Building illegitimate chain of blocks is known as a Chain-Rewrite Attack. If done the attacker can reverse transactions--stealing money back from people the attacker sent money to in the past after they have verified the transaction!
The attacker can also forge their own blockchain. The longest valid blockchain is considered the authentic blockchain--so if the attacker(s) beat honest attackers at producing a valid chain--they can steal all Bitcoins for themselves!
Why It's Hard to Forge Payments on Bitcoin
Earlier I mentioned each block of transactions must include the SHA-256 validated hash of the previous block of transactions. The reason for this is simple: the attacker is required to solve puzzles in succession: in order to corrupt a block of transactions that exist on the blockchain the attacker must also change all blocks of transactions that come after it.
Bitcoin survived because of this proof-of-work system. In other words, if you want to hog all the Bitcoins for yourself you have to somehow team up with enough people to solve Nakomoto puzzles faster than the entire network of honest people validating the real blockchain!
You can now see why Bitcoin survived the test of time--good luck hashing faster than:
hashes. You are going to need it.
Call for Beta Readers
Are you interested in learning how to program the cryptography featured in the tech introduced in this article like I am? Are you trying to become a cryptographic engineer in the future? If so, please consider reading the beta draft of my upcoming book: Program Cryptography.
I admit I only wrote the Preface + Table of Contents for now. That's because I want to see if people really care about it :). If you do, please feel free to leave any comments on the beta draft webpage.
And Thanks for Reading this Blog!
Frontal Image Credits
Comments