When talking about Secure Communications the following goals apply:
Confidentiality - Only those who should see it can see it
Integrity - Data has not been tampered with
Authenticity - Can verify the sending user/true source
lets first walk through some basic security concepts of how the above goals are applied to keep our data safe.
Confidentiality
Encryption/Decryption:
Encryption = Confidentiality
Encryption is where we take clear text add a cipher/key to scramble the text so it's illegible ciphertext. Decryption is the reverse process.
We need to know the Cipher/key to be able to decrypt the message to plaintext.
The longer key length used the more secure your data but the trade off is usually CPU performance as the work involved to encrypt and decrypt is more intensive.
We also have two types of encryption:
- Symmetrical Encryption/Decryption = Same key used to encrypt and decrypt (Shared Key Principle)
- Asymmetrical Encryption/Decryption = Uses a Private and Public Key pair (More on this later)
Encryption Algorithms:
DES
3DES
AES
RC4
Integrity
Hashing
We can run our data through a hash algorithm to generate a "message digest/thumbprint" of that data. The thumbprint is unique to the data meaning if that data is changed (even down to a single letter) when the hash is run on the receivers side the thumbprint will have changed meaning the data integrity has been lost.
Hash algorithms:
MD5 (weak)
SHA1
SHA2-256/512
SHA3
HMAC
Hashing can go one step further with HMAC (Hash-based Message Authentication Code). We can use a shared key to generate a MAC along with our digest. This is important because not only do we verify the data hasn't changed but it also verifies the Sender as only the sender and receiver will have exchanged keys.
So now we have seen how to encrypt our data, verify the sender and the message integrity. However for those curious among you might be thinking, how on earth do we exchange shared keys securely over an unsecured medium? The answer is Diffie-Hellman
Diffie-Hellman
Used to agree on shared keys across unsecured medium. Both parties have a public and private key pair. They swap Public keys then do a mathematical computation with the shared public key along with their own private key. A new shared key is derived from this but not transferred. (See below Example):
Diffie-Hellman is susceptible to man-in-the-middle attacks because there is nothing special about the public values. A third party can easily create a private and public key pair and send over the public key to one of the peers to manipulate the derived key from the diffie-hellman process. We can get around this by signing the public key values. This involves Asymmetric Encryption.
Authenticity
Data Signing with Asymmetric Encryption
Lets put everything we have learned together along with data signing with the below Example:
We run a hash on the data to create the digest/thumbprint we then add encryption with our own private key. Our peer then decrypts the digest with our public key runs the data against a hash to verify the result matches the decrypted hash.
Because we use asymmetric encryption we don't need to agree on shared keys before hand like with Symmetric Encryption.
Asymmetric Encryption is resource intensive so we tend to use this to establish secure connections. We then switch to symmetric Encryption to transfer bulk data.
So another Question?
How does BOB know that the public key received is actually ALICE's? Digital or x.509 Certificates.
Digital Certificates
Digital Certificates tie an entity to a Public Key.
Imagine you apply for a driving license or passport, an issuing authority (usually government based in this scenario) has to verify your identity with data you provide against data held. They then issue you an official signed document from them for you to show to prove your identity which usually includes a unique number/photo/validity period the type of document also describes the purpose (e.g passport for valid travel)
A Digital Certificate is the same principle. an issuer (certificate Authority) signs to verify the public key in question belongs to X individual its validity period and purpose.
Public Key Infrastructure
now we know about Certificates we will briefly discuss Public Key Infrastructure (PKI) the mechanisms for issuing certificates.
Root CA = top level Certificate Authority that sign their own certificates known as ROOT Certificate. They also issue certificates to intermediate CAs or endpoints in a single tier architecture.
Intermediate CA = Second level CA that can sign and issue certificates on behalf of the root CA. Normally the root CA is taken offline to protect the private key. IF the private key is discovered it can compromise your whole PKI infrastructure.
End Entities = Server certificates or user certificates issued by intermediate or root CA's
Companies can choose to implement their own private PKI infrastructure such as Windows Server Certificate Authority or you can use public certificate signing such as Digicert.
The process a CA takes to sign a certificate is similar to our asymmetric encryption example earlier, take the certificate and public key and run through a hash algorithm, encrypt the hash with the CA private key = signed Certificate.
Some examples of certificates and purposes in real world implementations:
WIFI Authentication
Windows Encrypting File System
Always on VPN
Remote Access VPN authentication
This just about sums up this blog post. This is a very high overview of how we secure our data across insecure mediums. Each of the topics only scratches the surface but I hope is enough to give you a base understanding.
Image refs: Aruba Certified Network Security Associate OFFICIAL CERTIFICATION STUDY GUIDE
Allred , Miriam. Aruba Certified Network Security Associate (HPE6-A78): Official Certification Study Guide (p. 1). HPE Press