Day 17 - How Trust Works on the Internet - Digital Signatures PKI
Yesterday, I took a step back to look at the big picture with the CIA Triad. It was a crucial lesson, but it left me with a burning question, especially regarding the 'I' for Integrity. We need a way to be certain that the data we receive is exactly what the sender sent, and that the sender is truly who they claim to be. How do we achieve that in a world full of impersonators and attackers?
Today, I'm diving into the answer: Digital Signatures. And as I quickly learned, while digital signatures are a brilliant solution, they introduce a fascinating new problem of their own—one that is solved by a massive, global system called the Public Key Infrastructure (PKI).
What is a Digital Signature?
A digital signature is a cryptographic mechanism that mimics the function of a physical, handwritten signature, but with far stronger security guarantees. Its purpose is to provide three critical security services:
- Integrity: Proof that the message has not been altered or tampered with since it was signed.
- Authentication: Proof of who the sender is. Since signatures are created with a private key, they confirm the identity of the signer.
- Non-repudiation: This is the key one. Non-repudiation means the sender cannot later deny having signed the message. Because only the sender has access to their private key, they can't claim someone else forged their signature. This is a crucial difference from symmetric MACs, where either of the two parties with the shared key could have created the tag.
How It Works: The Signing & Verification Process
The magic of digital signatures lies in a clever reversal of the public/private key roles we use for encryption.
The Signing Process (Sender's Side)
- Hash the Message: First, the sender takes the message (it could be an email, a document, or a software update) and uses a hash function like SHA-256 to create a unique, fixed-size "digital fingerprint" or digest.
- Encrypt the Hash: Next, the sender uses their own private key to encrypt this hash value. The resulting encrypted hash is the digital signature.
- Send It: The sender then sends the original message along with the newly created digital signature.
The Verification Process (Receiver's Side)
- Separate the Message and Signature: The receiver gets both the message and the signature.
- Decrypt the Signature: The receiver uses the sender's public key to decrypt the signature. If it decrypts successfully, the result is the original hash digest (let's call it Hash A).
- Re-Hash the Message: The receiver takes the message they received and calculates its hash using the same hash function (e.g., SHA-256). Let's call this Hash B.
- Compare the Hashes: Finally, the receiver compares Hash A and Hash B. If they are identical, the signature is valid! This proves the message came from the owner of the private key and that it wasn't changed a single bit along the way.
The Lingering Problem: The Man-in-the-Middle
The process above seems perfect, but it has a potential Achilles' heel. I found myself asking a critical question:
This all works perfectly, if and only if I can be 100% certain that the public key I'm using for verification truly belongs to the sender I think it does.
What if an attacker (Oscar) intercepts the initial communication where I'm supposed to get my friend Alice's public key, and substitutes his own public key instead? From that point on, Oscar can sign malicious messages, and I would believe they were from Alice. This is a classic Man-in-the-Middle (MitM) attack, and it undermines the entire system.
The Solution: Digital Certificates and PKI
This is where the real-world infrastructure of trust comes in. The problem of trusting a public key is solved using Digital Certificates.
Digital Certificates
A digital certificate is like a digital passport or ID card. It's a data file that cryptographically binds an identity (like a person's name, an email address, or a website's domain name) to a public key. But who issues this passport?
The Certificate Authority (CA)
Certificates are issued by a trusted third party called a Certificate Authority (CA). Think of a CA as the government's passport office. It is their job to verify an entity's identity before issuing a certificate. To issue the certificate, the CA digitally signs it with its own highly protected private key.
The Chain of Trust
So how do we trust the CA? This is the brilliant part. Our computers, operating systems, and web browsers come pre-installed with a list of public keys from major, globally trusted CAs. These are called "root certificates."
When my browser connects to an HTTPS website (like Google or my bank), the website presents its digital certificate. My browser then performs these checks:
- "Who signed this certificate?" It looks at the issuer information.
- "Do I trust this issuer?" It checks its built-in list of trusted root CAs.
- If the issuer is on the list, my browser uses the CA's public key to verify the signature on the website's certificate.
If the signature is valid, my browser knows that a trusted authority has verified that the public key belongs to that website. This creates a chain of trust. Because I trust my browser manufacturer, I trust the CAs they included, and because I trust the CA, I can now trust the website's public key. The padlock icon appears, and I know my connection is secure. The entire system of CAs, certificates, and policies is known as the Public Key Infrastructure (PKI.
Conclusion
Learning about Digital Signatures and PKI felt like discovering the 'glue' that holds internet security together. The RSA concepts that felt purely theoretical in the CTF challenges now seem incredibly practical, as I can see them working to protect me every time I see that padlock icon in my browser. It solves the great puzzle of how to trust someone you've never met in a digital world. This was one of the most important 'big picture' days for me so far; it connects the math, the protocols, and the real-world application of cybersecurity into a single, coherent system.
#IDNBootCampCyber
Komentar
Posting Komentar