Section 1.3 covers the basics of cryptography:
1.3.a Describe key exchange
1.3.b Describe hash algorithm
1.3.c Compare and contrast symmetric and asymmetric encryption
1.3.d Describe digital signatures, certificates, and PKI
1.3 Cryptography concepts
Before we start, lets make a couple of quick notes about cryptography. If we refer back to CIA (Confidentiality, Integrity and Availability), we are talking about securing data either at rest or in motion.
- Data can be at rest (caches, hard drives, servers, memory etc.)
- Data can be in motion (currently on the network moving from place to place)
There are also some terms we should get to know:
- Infosec – information security – where is the data:
- NFP – Network Foundation Protection
- management plane – logical ability to manage device (Admin login)
- control plane – how routers communicate to each other
- Data plane – moving traffic through the device
1.3.a Describe Key Exchange
Each encryption method requires a key. The key plus the encryption method produces the encrypted data. To reverse the process, one has to reverse the encryption method, to decrypt, with the key to produce the original raw data.
See (http://www.simonsingh.net/The_Black_Chamber/caesar.html) for an example of the caesar cypher) where the key is the offset value.
One could add complexity by changing the offset based on hour of transmission (requires accurate clocks).
1.3.b Describe Hash Algorithm
Hash algorithms are used to ensure the integrity of data. Two methods commonly available:
- MD5 – 128bit
- SHA – 160bit
There are a number of SHA variants; SHA-256 and SHA384 for instance. They use larger numbers of bit and therefore are more secure. MD5 is old tech where as SHA256 and beyond is considered next generation.
Hashing uses a mathematical process to create a digest (small amount of data) from the bulk data. The sender will send the data plus digest.
The receiver takes data and runs its own hash to create a digest. The receiver then compares digests. If the two digests are the same, then the receiver can be sure the data was not manipulated in transit.
Cisco uses hash digests to secure its IOS downloads and if you need to check a downloaded file the following command can be used:
#: verify /md5 <file name>
While hash algorithms can indicate a change in the data, what they cannot protect against is malicious actors changing the data. For this we need a secure hash algorithm, or HMAC.
HMAC – Hashed Message Authentication Code
HMAC – or the Hash Message Authentication Code – is where we use the hash algorithm on the data plus a secret key that only the sender and receiver know. This prevents a man in the middle attacks by making it very difficult to modify the data and create a new hash.
Hashing is used to secure communications in networking such as:
- IPSEC VPN tunnels to ensure packet integrity and authenticity
- Routing protocol updates authentication
- Securing IOS images to guarantee they have not been tampered with.
1.3.c Compare and Contrast Symmetric and Asymmetric Encryption
There are two types of encryption key; symmetrical and asymmetric.
Symmetrical key – Use the same key to encrypt and decrypt.
This is less secure but the algorithms involved require lower overhead to run.
Asymmetric algorithms – Use one key to encrypt and a different key to decrypt.
This is an extremely complex algorithm called the Diffie Hellman algorithm and requires a lot of CPU overhead to run.
The Caesar cipher is an example of symmetrical encryption, as it uses one key for encryption and the same key for decryption (one key). Other current symmetrical algorithms are:
- DES – Data Encryption Standard – symmetrical 56 bit algorithm. Not very secure now and not recommended except for regions that cannot use next gen encryption. This is relatively easy to break.
- 3DES – where the DES algorithm is run three times in succession. This is more secure but is still not classified as a next generation algorithm.
- AES – Advanced Encryption standards – currently a 128 bit algorithm with 192 and 256 bit versions also available. AES256 is considered next generation and is a very secure algorithm.
- IDEA – International Data Encryption Algorithm (used in PGP)
Because symmetrical algorithms require low CPU overhead, these standards are used for bulk data transfer.
Asymmetrical algorithms use a key pair (2 keys). Data encrypted with Key 1 can be decrypted with Key 2 and vice versa. These algorithms require more overhead in terms of CPU but have better security, and are harder to crack.
Usually a key pair is a public and private key. Anything encrypted with the public key, can be decrypted with the private key. Asymmetrical algorithms are used mostly for authentication functions such as the Public Key Infrastructure (PKI). Typical asymmetric algorithms are:
1.3.d Describe digital signatures, certificates, and PKI
Digital signatures are used to prove who is sending the data.
- The sender generates key pair (private & public key)
- sends public key to the receiver
- takes data and creates a hash
- encrypts hash with private key
- This becomes the digital signature.
- The receiver receives the data and encrypted hash
- generates a hash from the data
- decrypts the received signature to reveal the sender’s hash
- compares hashes
If the two hashes are the same, the receiver can be assured that the data is genuine from the sender and not from a man in the middle attack or a spoof of some kind.
A certificate is a really handy way of sending a public key to an end user for public/private key encryption. Any data sent by the end user can be encrypted using the public key, and the certificate originator can decrypt using their private key.
The end user can also respond with its own certificate (if required) providing their public key.
However; how does the end user know the certificate it has been sent, with the public key, is valid? It could be a spoof attack, where a nefarious site is trying to get end user information by spoofing the connection certificate?
The way around this is the public Key Infrastructure. The public key infrastructure provides a mechanism for checking the authenticity of the issued certificate. It works like this:
PKI (Public Key Infrastructure)
Certificate Authorities like Verisign , Go Daddy, etc. form a network of trust, providing PKI services. Many browsers come with these CAs (certificate authorities) installed with their certificate, which include the public key for the CA.
The way this works is as follows:
- We generate public/private key pair with our own servers, then register (enrolls) with CA
- CA then checks authenticity (in real life, phone calls, visits etc)
- CA then creates a digital certificate for the organization.
- Different types of certificates available
- X.509 format (serial number, version number, hash (SHA), algorithm (RSA), issuer (GoDaddy) etc)
- Also date and digital signature.
- Digital signature (encrypted hash) can be verified because we (the browser) have the CA public key.
So lets use the example of logging into my bank to check my account.
- When I start a session with the bank, the bank will send a certificate with the public key.
- We can guarantee the authenticity of the certificate and thus the public key, because we have the CA public key.
- That means we can check the digital signature of the certificate
we perform a hash on the certificate
- we decrypt the certificate digital signature using the CA public key and compare the hash values
- If they are the same, we are sure it is the bank we are talking to
- we check the validity dates to make sure the certificate is valid
- we check the URL to make sure it matches the certificate URL
- we check the CA revocation list to make sure the certificate has not been revoked.
This gives a clean copy of the bank’s public key (from the certificate)
Now we can send an encrypted packet to the bank and negotiate a session key. Once that happens, we are in business.
Having your own internal PKI CA.
Many companies have their own internal CA server that is used for company internal certificates.
And finally some LAB work:
Installing a certificate on the ASA
When working in the lab with an ASA, we are usually working with the ASA’s own self signed certificate. This is fine for lab work, but in real world production environments, we need to have certificates that are recognized in the PKI.
Why? Because a self signed certificate is not recognized by browsers and users SHOULD not connect if their browser doesn’t trust the certificate.
So we need to obtain a trusted certificate from a Certificate Authority and install that as our root certificate on the ASA. Once that is done we can use certificates generated from that root to authenticate out SSL (and IPSEC) capabilities.
There are two ways we can do this:
- Low Budget – we generate a permanent self sign certificate. Then each machine that connects has to be configured to accept the certificate – this is manual and not scale able.
- Big Budget – we purchase a root certificate from a CA.(this runs about $270 or there abouts). The root certificate is really the certificate to authenticate our organization. Once we have the root certificate (which can have a wild card to support subdomains), we enroll the device, and that gives us an identity certificate. The device has its own key pair which is sent to the CA.
Once all this happens, we will have two certificates – the root and the identity. Both will be installed on the ASA
This is scaleable and requires no manual configuration of the client PCs.
It is also possible to create our own CA server – This is outside of the scope of the CCNA Sec, but if I have time I might look into this.
NTP is also important because certificates have expiration dates. The last thing we want to do is make this mistake.
To implement this on the ASA, we do the following:
- Set Up NTP
- Configuration > NTP > System Time
- Clock – check and set time zone etc
- NTP – add an NTP server
- Show Clock
- Sh NTP status
- sh ntp associations … to verify
- To Authenticate
- Configuration > Device Management > Certificate
- Management > CA Certificates
- Add a new CA – browse for a file or use SCEP
- SCEP or manual
To Enroll – we need to generate an identity certificate
- Configuration > Device Management > Certificate Management > Identity Certificates
- Add new certificate
- generate new key pair
- Advanced – add URL of CA server
- Add outside IP address of ASA
Apply to the interface
- Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles
- Where the access interface section is, select Device Certificate
- Select the identity certificate