Understanding Public Key Infrastructure (PKI) - Part 3 (Digital Signature Verification)

 Verifying the certificate you receive from the other end is one of the crucial steps in the PKI. Lets get back to Alice and Bob.

Now that Bob received Alice's certificate, Bob need to verify if that certificate is really signed by the CA, before he accepts and uses the public-key present in the certificate of Alice. 

Certificate verification is a simple process, if you understand how a digital signature is created and verified. If you are not sure on how a digital signature works, please refer back to part-1 of this blog.

Remember, when Alice's certificate was created, the CA had digitally signed her certificate with CA's private-key. So, if  something was signed by a private-key, we need the corresponding public-key to decrypt and verify the signature. Right? 

So, if Bob wanted to verify Alice's certificate, Bob needs CA's public-key. Where will Bob go to find the public-key of the CA? Can you guess?

Yes, CA's public-key will be in CA's certificate. To verify Alice's certificate, Bob needs the certificate of the CA that has signed the certificate of Alice. Note that every CA also has a certificate similar to Alice's and Bob's, but mostly they are self-signed by the CA themselves. The CA certificate will contain the public-key of the CA. This certificate is commonly known as root-certificate of CA.

Most browsers and Operating Systems will come with pre-loaded root certificates of all the well-known Certificate Authorities on the Internet. Alice's certificate will tell the name of the CA that issued her certificate. So, Bob can pick up that certificate and fetch the publc-key of CA.

Using this public-key of CA, Bob will be able to verify if Alice's certificate is in fact signed by this CA.

If the verification goes successfully, then Bob will accept the public-key present in Alice's certificate and use that key to communicate with her.

Do you think the story ends here? Not quite :)

One last thing. Someone could be using Alice's certificate to communicate with Bob. Digital Certificates are not secret items. They are freely distributed in public domain. So, it is possible that someone can take Alice's certificate and use that to communicate with Bob. Even though the certificate verification will go through successfully, the person at the remote end may not be really Alice! Ooops...!!! Possible, right?

So, one last thing Bob will have to verify is this. Does the person claiming to be Alice at the remote end is really Alice. In other words, Bob will have to confirm that the remote end does possess the private-key corresponding to the public-key in the certificate. How is this done?

Bob generates a random text, say 17Ms66, and encrypts this random number with the public-key present in the certificate of Alice, say XbjZq3. Bob sends this cipher text to Alice. If Alice has the private-key with her, she will decrypt with her private-key and send back the plain text 17Ms66 back to Bob. If Bob gets back the original random text, he is now sure that Alice in fact possesses the private-key corresponding to the public-key in her certificate. At this point, all the verification is complete, Bob can now safely use the public-key of Alice to talk to her.

If the remote party is not able to decrypt the cipher text back to original random text, that means, the remote party does not have the private-key. Bob will stop communication with the remote end.

That's it.

I hope this blog has clarified some of your questions regarding PKI and Digital Certificates.

I would appreciate your comments below.

Have fun with PKI 😊

 Stay Safe!!! 

Mohan Muthu

mohan.bestroute@gmail.com

Viptela Routing between SDWAN and Non-SDWAN sites via Data Center

Are you working on Cisco Viptela SD-WAN migration and wondering how to go about it? Are you puzzled about how the non-SDWAN sites communicate with SDWAN migrated sites during the migration? Maybe this blog might throw some light on this matter.

I have just jotted my understanding of how SDWAN migrated sites can communicate with non-SDWAN sites via the Data Center, taking examples from both MPLS and Internet sites. I have made two diagrams, one shows the control plane, on how the routes can be exchanged between various sites and the other one shows the data plane on how the traffic between various sites flow.

I also have a third diagram that shows how the vEdge, Data Center core router, DMVPN router, and the Internet Firewall can be connected.

All the diagrams are self-explanatory for network engineers. The arrows in the Control Place diagram indicate the direction of route advertisements and the arrows in the Data Plane diagram indicate the direction of the data flow. To keep it simple, I have used much simpler notation for subnets, such as 10.X for Data Center etc.

The green tunnels in the control plane diagram are the DTLS/TLS Control connections to vSmart.
The red tunnels in the data place diagram are the IPSec tunnels between SDWAN sites.
The purple tunnel is the static (or DMVPN) IPSec tunnel to an Internet-only non-SDWAN site.
The blue lines depict the data traffic flow between various sites.

Please excuse my hand made diagram. It is a lot easier to make this with the hand rather than using software.

I am posting this to know your opinion/comments on this. If you have any questions or need any information, please feel free to ask in the comments section.

The Control Plane:

The Data Plane:

The Firewall Connections:

Thank you.

How PAC Works with EAP-FAST?

In this blog, let me explain in simple terms, on how PAC, Protected Access Credentials, is used in  EAP-FAST (Extensible Authentication Protocol - Flexible Authentication via Secure Tunneling).

I assume that you already know what PAC and EAP-FAST are. In this blog, I will take you through the steps involved in EAP-FAST authentication.

PAC Provisioning Process. (Phase 0)

1. A-ID (PAC Server) creates a Master secret key and it is known only to the A-ID. This is like a PRIVATE Key in PKI.

2. I-ID (PAC Client) Client sends a request to A-ID requesting for a PAC.

3. A-ID and I-ID use Diffie Hellmann algorithm to create a secure communication channel

4. A-ID Generates a random secret key, called the PAC-Key, specific to this client I-ID.

5. A-ID encrypts this PAC-Key (along with I-ID and Lifetime) with its Master Secret key. This encrypted information is called PAC Opaque

6. A-ID creates a PAC-Info field, that contains the information about the A-ID itself (PAC server)

7. All the below 3 fields are put together and is called PAC

PAC = [ PAC-Key + PAC Opaque + PAC-Info ]

8. This PAC is now sent to the client securely over the secure channel created by the DH algorithm.

9. DH channel is taken down.

10. A-ID forgets the PAC.

How PAC is used during EAP-FAST Authentication (Phase 1)

1. The client sends its ID to the PAC-Server. This is anonymous id and not the real id of the client. 

2. PAC Server returns its A-ID to the client. 

3. The client verifies if it has received a PAC that was generated by this A-ID. If so, it returns the PAC-Opaque to the A-ID (PAC-Server).

4. PAC Server decrypts the PAC-Opaque using its Master Secret Key (only known to the A-ID. This is like the Private Key in PKI) and obtains the PAC-Key for that client. Remember from step 5 above, PAC-Opaque contains the PAC-Key in the encrypted format.

5. Now that the client and the server have the PAC-Key, only known to both of them, they can use the PAC-Key to encrypt and decrypt the traffic between them, creating the Phase 1 tunnel of EAP-FAST. (Remember from step 7 and 8 above, the client also has the PAC-Key received from the Server as part of PAC)

Phase 2

1. In Phase 2 of EAP-FAST, another authentication method such as MS-CHAPv2 or EAP-TLS will be used to authenticate the client to the server, inside the secure tunnel that was built in Phase 1.

2. After the authentication is successful, the EAP-FAST tunnel is taken down.

3. The client and the server lived happily, until the next authentication.

I hope that was useful. Please feel free to leave your comments below.

IEEE 802.1X, EAP and RADIUS. Whats all this and how they work together?

OK. Let me dive straight into the subject without any preamble. You landed on this page because you are not very clear on what these are and more importantly, how these technologies work together and what do they achieve in today's security landscape. Let me first give you an overview of these and then show you how they work hand-in-hand to achieve what they are made to achieve.

Before anything, I assume that you are a network/security engineer/architect and have a good understanding of basic networking and security technologies.

Please note that what I have explained is a lot simplified versions, so that you understand the basic concepts behind these technologies. In real life networks, there will be more complex exchange of messages and more advanced features might be implemented. I have not covered these in this blog. This blog aims to give you just the basic concepts behind these technologies.

IEEE 802.1X

IEEE 802.1X is a port-based authentication mechanism. Let me explain what it means. You walk up to your desk on Monday morning at 8:00 AM and connect your laptop to the RJ-45 plug in your cubicle. Voila, you are on the corporate network and start your day's work; viewing your e-mails, surfing the Internet, processing orders for your company etc. How did this happen? The moment you connect your laptop to the switchport, say Gi1/3, the switch immediately granted you access to the corporate network. Your corporate network does not recognize you, from what device (Windows PC or Mac OS or Linux etc.) are you connecting etc. This is what happens when IEEE 802.1X authentication is not enabled on the switch. Absolutely no security, no questions asked, the switch simply connects you to the corporate network.

Wouldn't it be nice for the switch (and hence the network) to know who the user that is connecting to Gi1/3, so that the network can apply appropriate network security policies pertaining to that user? If the user is Sam from HR, then the network can dynamically put that switchport in VLAN 30 (the HR VLAN) and apply an ACL (the HR ACL) that will only allow him to access the HR payroll database and not the Financial Forecast data of your organization. Wouldn't this be a more secure way to provide network access to your employees instead of simply granting full access to anyone? You agree, right? Great. Now the question is, how will the network know about the user sitting behind the device? This is where IEEE 802.1X comes into the picture.

IEEE 802.1X is an authentication framework that helps the network to gather user information from the devices such as Windows PCs etc. and also control (open and close) the switchport where the user is connected. This is how it works: 

IEEE 802.1X has three entities for it to function;

The Supplicant: This is a small piece of software that resides on the endpoints such as Windows PC. This piece of software will recognize the IEEE 802.1X authentication request messages from the switch

The Authenticator: This is the network device where the PC gets connected to. In our case, this is the access layer switch. For wireless connectivity, this will be the Wireless LAN Controller or an Access Point.

The Authentication Server: This is the server that is responsible for making the authentication decisions and also decides the level of access (VLAN, ACL etc.)  to be granted to a user. This is typically a RADIUS Server residing somewhere in the Data Center. This server is the one that has the user credentials (such as username, password etc.) and also has the authorization level to be granted to the users (or user groups).

OK. Its time to put all this together. Once the switch is enabled for 802.1X authentication, the switchports will be in an 'unauthorized' (closed) state and no data traffic can pass through the switchport. The port will move to an 'authorized' state after the user successfully authenticates with the authentication server. The port will allow data traffic to pass through it in the authorized state. This is analogous to putting a security guard at the front door of your office. If someone walks up to your office, he/she will have to prove his/her identity before the security guard opens the door for him/her. If they cannot prove their identity, the security guard keeps the door closed. This prevents unauthorized access to your office. IEEE 802.1X provides similar security to you network and prevents unauthorized access to your network.

Simple, right? Now let's look at the sequence of events that take place when someone, say Sam, tries to connect to the network Monday morning at 8:00 AM. We will assume that Sam's credentials are already present in the authentication server.

1. User Sam connects his laptop to the switch and the link between the switch and the laptop comes up. (show interface Gi1/3 will show hardware up and line protocol up on the switch side)

2. Because the switch is enabled for 802.1X, the port is in an 'unauthorized' state and does not permit any traffic through it, even DHCP packets. The switch now requests the laptop to provide the identity of the user. This request message is conveyed to the laptop through the EAP-Request/Identity message. EAP messages are sent over Layer 2 frames called EAPOL frames (EAPoverLAN) and hence no IP address is needed for this communication. Remember, at this point, the laptop does not have an IP address. (Don't worry about EAP now, I have explained it later in this blog)

3. Even though the laptop does not have an IP address yet, its NIC card is up and active. (see step 1). Therefore, it can receive Layer 2 frames from the switch. The laptop is running IEEE 802.1X supplicant, which recognizes the EAP Request/Identity message from the switch. (Note: If the laptop does not run 802.1X supplicant, it would not recognize EAP messages and would simply drop them). After receiving the EAP-Request/Identity message, the supplicant running in the laptop will prompt the user for a username and password. Sam will type in his username and password and click submit.

4. The supplicant will take the username/password and pass them on to the switch in the EAP-Response/Identity message. This message is also carried over EAPOL Layer 2 frames. Even though the switch port is in an 'unauthorized' state, it will receive EAPOL frames. EAPOL frames are the only frames the switch will allow in the "unauthorized" state.

5. The switch being the authenticator, does not have the user credentials to verify Sam's username and password. The username/password should be sent to the authentication server for validation. To do this, the switch will encapsulate the EAP-Response/Identity message into a RADIUS Access_Request message and sends it to the authentication server. Here the switch is the RADIUS Client and the authentication server is the RADIUS server. RADIUS works over UDP/IP and therefore can easily communicate over the Corporate Network. (See below for overview on RADIUS)

6. After receiving the RADIUS Access_Request message from the switch, the authentication server will extract the username/password from the message and will attempt to validate the username/password combination. This validation can be done by the authentication server itself if it has the user credentials or it can take help from external sources such as Microsoft Active Directory or LDAP server.

7. If the authentication succeeds (that is, Sam supplied his username and password correctly), the authentication server will convey the results of the authentication to the switch through RADIUS Access_Accept Message.

8. On getting the RADIUS Access_Accept message from the authentication server, the switch knows that the authentication was successful and will now move the port where Sam's laptop is connected from "unauthorized" state to "authorized" state. Remember, the port will pass traffic normally only in an "authorized" state. The switch then conveys the good news to the supplicant through the EAP Success message.

9. After receiving the EAP success message, the supplicant knows that the authentication was successful and it starts sending data over the connection to the switch. Remember, until this point, the supplicant was holding all communication from the laptop, including the DHCP requests. Now the laptop can send DHCP request to obtain an IP address and then happily communicates with the rest of the network.

10. The port will remain in the "authorized" state as long as Sam stays connected to that switchport. If Sam disconnects his laptop to go home, the line will go into down/down state and the switch port will move to the "unauthorized" state. If Sam connects back again to the same (or different port), all the steps from 1 to 9 will be repeated before he can access the network.

11. In step 7, if authentication had failed, that is, Sam had not supplied his password correctly, the authentication server will send RADIUS Access-Reject message to the switch. Upon receiving this message, the switch will keep the port in "unauthorized" state and will convey the bad news to the supplication through the EAP Failure message. Upon receiving EAP-Failure message, the supplicant knows that the authentication wasn't successful and will attempt to authenticate again. It will continue to hold any IP communication until it receives an EAP Success message.

EAP (Extensible Authentication Protocol)

Now, for EAP, I am going to keep it really simple. In the above example, Sam authenticated to the network using his username and password. Is that the only way a user can authenticate? How about using a Digital Certificate or even biometric methods? Different organizations use different ways to authenticate users. Also, why did the authentication server agree to authenticate using username/password? Why not using Digital Certificates? How did the supplicant and the authentication server agree to use username/password for authentication? This is where EAP comes into the picture. EAP tells how exactly the supplicant will authenticate to the authentication server.

In real networks, the supplicant and the authentication server must first negotiate and agree on a method (username/password, Digital Certificates, OTP etc.) to authenticate the user. Only if they both agree on a common method, the authentication process will move to the next step. For example, if the supplicant is configured to use username/password to authenticate and the authentication server is configured for Digital Certificate based authentication only, then the negotiations will fail.

You configure an EAP method on the supplicant and the authentication server must also support the same EAP method. (The authentication server might support more than one EAP methods to support different types of clients). There are many EAP methods available, but I list some of the common ones here:

EAP-TLS - Used for Certificate based authentication
PEAP-MSCHAPv2 - Used in username/password based authentication in Microsoft environments

If you noticed, in the above example, the actual authentication was happening between the supplicant and the authentication server. The switch (the authenticator) was just acting as an intermediate device simply encapsulating the EAP messages into RADIUS messages. The switch does not care how the supplicant authenticates to the authentication server, it is only interested in the results (Access_Accept or Access_Reject) of the authentication. In other words, the switch does not care what EAP methods the supplicant and the authentication server negotiates. In fact, there is no need to configure or enable EAP on the authenticator (the switch/WLC). It is enabled and configured only on the supplicant and the authentication server.


RADIUS (Remote Authentication for Dial-In User Service)

First of all, let's understand why is RADIUS protocol called so.

Around 15 years ago, as a home user in India, I used PSTN (the phone network) to connect to the Internet. My PC was connected to a modem, which in turn was connected to the PSTN network. The other end of the PSTN also had a modem (modem bank to be precise) and the modem was connected to a router (or Network Access Server, NAS), as shown.

Here is the sequence of events that took place before I could access the Internet from my home.

1. From my PC, using the software provided to me by my ISP, I dial-in to my ISP's modem and get connected to the Network Access Server (NAS) on the remote end. NAS is a router.

2. A PPP (Point-to-Point) connection is established between my PC and the NAS. The NAS prompts me for username and password, which I type on my PC's console.

3. Through PPP, the NAS collects my username/password. Using the RADIUS protocol, it verifies my credentials with a RADIUS server to make sure that I am a paid customer of the ISP. My username/password was added to the RADIUS server database at the time I purchased the service.

4. The NAS being the RADIUS Client here, uses RADIUS Access_Request message to pass on my credentials to the RADIUS server. If my credentials are valid, the RADIUS server replies with the RADIUS Access_Accept message to the NAS.

5. Upon receiving the RADIUS Access_Accept message, the NAS connects me to the Internet. I browse happily thereafter.

6. If my credentials are not valid, the RADIUS server replies with the RADIUS Access_Reject message and NAS does not connect me to the Internet. I had to repeat the authentication until I supply the correct credentials. What a sad day!

This is how RADIUS was used in olden days. RADIUS is a very mature protocol and has been there for more than 25 years. It was used to authenticate remote dial-in users (like me in this example) and hence the name.

Even though we don't use dial-in technology that much today, the RADIUS protocol is still used in the same way today. The only thing that has changed is that instead of PPP we are using IEEE 802.1X to get the credentials from the client.

RADIUS is a very simple client-server protocol and has only 4 basic messages.

1. Access_Request - This message always goes from the client to the server, requesting to start an authentication process. This message is also used to convey any additional parameters to the server from the client. This message is also used during the EAP negotiations.

2. Access_Challenge - This message always goes from the server to the client, when the server needs any additional information from the client, such as requesting a digital certificate etc. This message is also used during the EAP negotiations.

3. Access_Accept - This message conveys that the authentication request was successful and always goes from the server to the client.

4. Access_Reject - This message conveys that the authentication request was not successful and always goes from the server to the client.

Summary

In summary,

IEEE 802.1X specifies that the authentication is needed for the switch to "authorize" (open) the port and helps in getting the credentials from the supplicant.

EAP decides how the supplicant and the authentication server should authenticate. The authenticator (switch) is only interested in the outcome of the authentication, not in how exactly the supplicant authenticates to the authentication server. There is no need to enable EAP on the authenticator. It is enabled only on the supplicant and the authentication server, with at least one common EAP method.

RADIUS is the protocol that is used between the authenticator (switch) and the authentication server such as Cisco ISE or Microsoft RADIUS server.

Always Remember;

1. The supplicant and the authentication server should be configured/enabled with at least one common EAP method.

2. The authenticators are not configured or enabled with any EAP method because they are not interested in what EAP method was used in authentication, but only interested in the outcome of the authentication process.

3. Your laptop or the PC is not the RADIUS client. Your authenticator (switch/WLC) is the RADIUS client. Your PC/laptop does not run RADIUS. They only run the IEEE 802.1X supplicant.

4. If your laptop/PC is enabled for IEEE 802.1X supplicant, it can communicate with the switch even if the switch port is in an "unauthorized" state. Remember, an unauthorized port can send and receive Layer 2 EAPOL frames.

5. IEEE 802.1X/EAP/RADIUS works almost in a similar fashion on wireless networks, with some minor changes. I will explain this in a separate blog.

I hope you enjoyed reading this and hopefully got some basic understanding. Please feel free to share your thoughts and comments. Also if you find any mistakes or room for improving this blog, please let me know.

Have a Great Day!!!

Understanding Public Key Infrastructure (PKI) - Part 2 (Digital Certificates)

In part-1 of this blog, we discussed the basic building blocks of PKI infrastructure, such as encryption, hashing, digital signatures, etc. In part-2 here, we will continue to discuss the digital signature process and address the questions.

In part-1, under the 'Digital Signature' section, I said, Alice will have to send her 'public' key to Bob, so that Bob can verify her signature at the receiving end. Now, the first question is; How can Bob be sure that the 'public' key he received from Alice is in fact belongs to Alice? It is quite possible that an attacker can send his 'public' key to Bob and fool Bob into thinking that the key belongs to Alice. This way, the attacker can send any digitally signed message to Bob and if Bob uses the attacker's 'public' key, the attacker can send a message to Bob and it will appear that the message came from Alice.

So, the question is; How does Bob verify that the 'public' key he received from Alice is in fact belongs to Alice? This is where Digital Certificates come into play.

Digital Certificates

 

 Before Alice sends her 'public' key to Bob, she has to obtain a digital certificate from a third party, that both Alice and Bob trust. This thrid-party is called the Certificate Authority or CA for short. The digital certificate issued to Alice by the CA simply authenticates that the 'public' key mentioned in the digital certificate belongs to Alice. Here is the process of obtaining a digital certificate.

1. Alice generates the key-pair (public key and private key) on her computer. She keeps the private key safely on her computer.

2. She then generates a 'certificate signing request' to CA. In this request, she puts her name and her public key along with other information and sends this request to the CA.

3. Upon receiving this request from Alice, the CA will verify, through off-line methods such as phone or e-mail, that the requested person is genuine.

4. Once the CA is satisfied that the request is genuine and verified its requester, it will create a digital certificate for Alice and sign it with its own 'private' key.

Here is what happens at the CA end when the digital certificate is created:

1. The CA will take all the information in the certificate request, adds validity dates, issued to, issued by fields, and pass this information (like a message) into a hashing algorithm, such as SHA-1. The SHA-1 will produce a hash.

2. Then, the CA will digitally sign the contents of the certificate by simply encrypting the hash (in step 1) using its own 'private' key. The encrypted hash is the digital signature of the CA.

3. The CA then appends the digital signature to the contents such as name, public key, validity dates, etc. This now becomes the digital certificate of Alice, signed by CA.

4. CA will send the signed digital certificate to Alice.

From now on, Alice can use her digital certificate to prove that the 'public' key mentioned in the certificate belongs to her. In our case, instead of sending just the 'public' key to Bob, Alice will instead send her digital certificate to Bob.

Got it? Wait, the story is still not complete. If your head is spinning at this stage, you may want to take a break (or a beer) at this stage and fully understand the certificate signing process. Very important in understanding PKI.

Once you are sober...jus kidding...no offense... Continue on...

Now, after receiving Alice's digital certificate, how will Bob verify the authenticity of Alice's certificate? Part-3 of this blog will answer this question.

See you there.

 

Understanding Public Key Infrastructure (PKI) - Part 1 (Introduction)

Introduction

Ever wondered what happens behind the scenes when you do an online bank transaction? Do you know what goes on in the background to keep your transactions safe and secure from the prying eyes? Are you getting confused about terms like digital signature, digital certificate, hash functions, symmetric and asymmetric encryption, certificate authorities, SSL/TLS, etc? Then this blog might help you clear some concepts for you. Read on.

PKI, Public Key Infrastructure, is a very complex mix of security technologies. So, I am going to start by explaining individual components that make up the PKI. Once you are familiar with these components, understanding PKI becomes very easy.

 

Symmetric Key Encryption

 

This is the simplest thing to understand, and in high probability, you already know this. Encryption is the process of scrambling the data into an unrecognizable form, such that, if the traffic ends up in the wrong hands, it will be useless. To perform encryption, the data in clear text and a key is input to an encryption algorithm. The output of the encryption algorithm is the encrypted text or ciphertext. To get back the original data from the ciphertext, you need to use the same algorithm that was used to encrypt the data and also input the key. If the same key is used to encrypt and decrypt the data, then it is called 'Symmetric Key Encryption'. DES, 3DES, and AES are examples of symmetric key encryption. Symmetric key encryption is generally used to achieve confidentiality of your data.

 

Asymmetric key Encryption

 

Unlike symmetric key encryption, where only a single key is used to encrypt and decrypt the data, asymmetric key encryption involves two keys or a key pair. The keys in the key pair are mathematically related in such a way that any data encrypted with one key can only be decrypted using the other key and vise versa. It is important to note that the same key that was used to encrypt the data cannot be used to decrypt the data. RSA is an example of asymmetric key encryption.

 

Now, what is the difference between symmetric and asymmetric key encryption?

 

Symmetric key encryption is used when bulk encryption is needed. For example, symmetric key encryption is used when your browser and the web server are communicating via SSL/TLS communication. The reason for this is symmetric key encryption is faster and consumes less processing overhead.

On the other hand, asymmetric key encryption is slower and consumes more processing overhead. Therefore, asymmetric encryption is used for encrypting a small amounts of data, such as in digital signatures, digital certificates, etc. Asymmetric key encryption is generally not used to encrypt your data traffic.

 Great! I am sure that was a piece of cake for you. Let us move on. 

 

Hashing

 

While the encryption process keeps your data hidden from the bad guys, the hashing algorithm is used to ensure the integrity of the data. Let's say, you are sending a message to your bank to "Pay $100 to Mr. Scooby". What if Mr. Doo is able to intercept this communication and change the message to "Pay $1000 to Mr. Doo?" How will the bank know that the data has been modified in transit?  This is where hashing helps.

Hashing is a one-way mathematical function, that takes a message of arbitrary length, (could be one word or an entire book) and produces a fixed-size sequence of bits. These output bits are called the 'hash' or 'message-digest' of the message. MD5 and SHA are the two popular hashing algorithms. MD5 produces a 128-bit hash and SHA-1 produces 160 bit of hash.

So, how is hashing going to help in our case here? Before sending the message, you must calculate the 'hash' of your message "Pay $100 to Mr. Scooby" using, say MD5. Now, send the hash, along with the message to the bank. The bank will verify the integrity of the data by calculating the 'hash' of the received message (of course using the same algorithm) and compare it with the 'hash' received along with the message. If both the hashes match, that indicates to the bank that the message has not been altered in transit. Mr. Scooby gets his $100 happily. If Mr. Doo has modified the message in transit, the hashes won't match at the bank end, and the bank will discard the message. Mr. Doo is still wondering why $1000 is not credited to his account!

Even if one bit is modified in the original message, the resulting 'hash' will be entirely different from the original 'hash'.

And, read the first line of the second para above again. I said hashing is a one-way mathematical function. By one way, I mean, it is almost impossible to get the original message from the 'hash'.

A key can also be used to input to the hash algorithm (in addition to the message) to make it more secure. This is called HMAC, Hashed Message Authentication Code.

Getting interesting uh? Dig in for more.

Digital Signature

 

If you thought the digital signature is the scanned copy of your signature on a paper, then you are not alone. When I heard of this term many years ago for the first time, I really thought so. So cute, isn't it?

Before we talk about the 'digital' signature, let us see what paper signature is used for. As we all know, when a person puts a signature, with a pen on a paper, the person authenticates the message written on the paper. Right? A digital signature is also used for the same purpose, but to authenticate digital messages, such as an e-mail.

Before we see how a digital signature is created, let us take another look at asymmetric key encryption. In asymmetric key encryption, two keys (a key pair) are generated, a Private Key and a Public Key. These two keys are mathematically related in such a way that, a text encrypted with a private key can only be decrypted with its corresponding public key and vise versa. This is very important in understanding digital signatures and PKI.

So, if Alice wanted to sign a message digitally to authenticate it, she must first generate a private/public key pair, on her computer. The private key, as the name implies, is known only to Alice (her computer) and no one in the world. Alice must take at most care not to share her private key with anyone. However, she can distribute or share her public key with anyone in the world. 

Let's say, Alice wanted to send a digitally signed message to Bob. First, she must share her 'public' key with Bob. Then, she creates her message that says "Let's have coffee". Now, she will have to create a digital signature for her message.

Here is how a digital signature is created and used.

1. Alice takes the message "Let's have coffee" and runs it through a hashing algorithm, such as SHA-1. SHA-1 takes the message as input and generates a 160 bit hash as output. 

2. Alice encrypts the resulting hash (160 bit) with her 'private' key. The encrypted form of the hash is Alice's digital signature for that message.

3. Alice sends the message (Let's have coffee) to Bob and also appends the digital signature with it. 

4. Bob receives the message along with the digital signature. 

5. Bob runs the messages through the same hashing algorithm, SHA-1 in this case, and produces the hash. This hash will be the same hash generated by Alice in step 1.

6. Bob also decrypts the digital signature with Alice's 'public' key. The result will be the original hash of the message (same hash value in step 1). That is, Bob simply performs the reverse operation of step 2.

7. If the hash generated in step 5 and step 6 are the same, then Bob can be sure that Alice has signed the message, and also the message has not been modified in transit. The fact that only Alice has her private key and nobody else, the matching hash indicates that the message was in fact signed by Alice's private key.

8. If the hash generated in step 5 and step 6 do not match indicates either Alice has not signed the message or the message has been modified in transit. In this case, Bob will simply discard the message.

From the above steps, carefully note that the 'message' is not encrypted, but the 'hash' of the message is encrypted, which forms the digital signature.

Here, asymmetric key encryption is used to authenticate the message, but not used for encrypting the message. As I discussed earlier, message encryption is performed using symmetric key encryption. We will talk about this later.

I hope you now have a fairly good idea of how digital signature works! Great.

I know you have a few questions on the digital signature process we discussed above. I had them too. I will address them in part-2 of this blog.

See you there...

Mohan Muthu
mohan.bestroute@gmail.com

Locator ID Separation Protocol (LISP)

In this blog, I will explain how the Data Plane and Control Plane works in a LISP environment. I assume that the reader is already aware of what LISP is and why it is deployed.

LISP Data Plane:

1.  The source host sends an IP packet destined to another LISP site. The source IP is the EID of the      source host and destination IP is the EID of the destination host. Remember, the hosts are not aware of the LISP environment.

2.  This packet gets forwarded normally towards the edge router (ITR) of the EID domain.

3. The ITR looks to see if it has a mapping for the destination EID in its map-cache. If it has, the ITR encapsulates the original IP packet into a LISP packet. The outer header will have source IP of the ITR's RLOC IP and destination IP will be the one found in the map-cache. The ITR forwards the packet into the RLOC space. If the mapping is not found in the map-cache, the ITR will initiate a map-request. This process is explained in the Control Plane section below.

4. The LISP encapsulated packet will be routed normally in the RLOC space and will arrive at the ETR of the destination EID.

5. The ETR will examine the LISP packet. If the destination IP on the outer header is that of its own, it will decapsulate the LISP packet, take out the original packet and forward inside the EID domain towards the final destination.

LISP Control Plane:

The main job of the LISP control plane is to provide the EID-to-RLOC mappings to the requesting ITRs.

1.  The ETRs responsible for the EID space will send a map-register message to its configured Map Server (MS).

2. The MS will advertise (inject) the EID prefix into the ALT topology, just like any other prefix in BGP.

3. The Map Resolvers (MR) will learn the EID prefix via the ALT topology. Remember, MS and MR are part of ALT topology. The MR now knows how to reach the EID prefix.

4. Now, when the ITR does not have EID-to-RLOC mapping in its map-cache (see point 3 in Data Plane section), it sends a map-request message to its configured MR. If the ITR is not part of the ALT, it will encapsulate the map-request and send it towards the IP address of the MR. Also remember, if the EID-to-RLOC mapping is not available in the map-cache, the ITR will put the original EID destination IP in its outer header's destination IP.

If the ITR is part of the ALT topology, it will just forward the map-request in the ALT topology. Remember, the ALT routers have the EID prefix in its routing table. In this case, we assume ETR is also part of ALT, so that the map-request directly reaches the ETR, without using MR/MS. MR/MS mapping infrastructure is used to scale the LIPS for large deployments, such as Internet.

5. The MR will decapsulate the map-request and forward the map-request in the ALT. The map-request will have the destination EID as the destination IP in the packet. So, the map-request will be forwarded towards the MS over the ALT. Remember, MS is the one that injected the EID into the ALT.

6. After the map-request reaches the MS, it will consult its mapping database to find out the RLOC for the EID in question. MS knows this information because the ETR has registered with MS in step 1.

7. MS will encapsulate the map-request and forward it to the RLOC (ETR's outside IP address).

8. ETR will get the map-request and will directly send a map-reply to the ITR's outside IP address.

9. The ITR will receive the EID-to-RLOC mapping and keeps this mapping in its map-cache for future use.

Thanks for reading. Please leave a comment.