Just another article on Cryptography, SSL and Digital Signature

Introduction

There are millions of articles/ tutorials on the web that do the same, however in this article I would try to be as concise as possible and explain concepts that would be helpful in my forthcoming articles (on security).

I absolutely love feedback and corrections (if any). Moderators/ experts please feel free to correct me whereever I am wrong and help with your valued suggestions.

Background

Though some programming knowledge will be helpful, it's not necessary to understand this article.

Hashing and Padding

A cryptographic hashing function generates an output value which is practically impossible to convert back to original input value. On top of this, the generated output changes drastically even if there is small change in the input. Such hashing function involves complex mathematics.

So for e.g.:

“Hello world” -------Gets converted to something like------------> D8 A2 13 A1 98 93 8B F5.....

“Hello world.”-------Gets converted to something like------------> C2 23 43 AA B2 49 8D E1....
MD5 and SHA1/156 are the popular hashing algorithms (functions). You may not be required to know the in-depths of these functions, however in most modern programming languages you will find their implementation in some form.

Modern Hashing algorithms process messages in fixed length blocks and additional data is added to such message blocks to make these message blocks of the required size if shorter. This is called padding.

Padding is also done to prevent vulnerabilities in hashing functions (like 'length extension attacks'). In this case a fixed string (read: bytes) is appended to the input to make the hash even more complex. In this case the padded string is also referred to as a 'Salt'.

Now how can all this help in security and cryptography? As an example, imagine if you are saving user password in the database as a Hash of the actual password (instead of saving the password in plain text). Even if someone reads the database, user password won't be revealed. However your application can generate hash of the user password (provided by the user on login screen) and compare it with the database password hash to authenticate the user.

We will refer to 'Hash' a lot in this and future posts.

Symmetric Key Cryptography

Symmetric key cryptography is easy conceptually. A mathematical 'key' is used to encrypt the message and the same key is used to decrypt the message. The complexity of the key and algorithm used has direct effect on how easily the message can be 'hacked' (decrypted).

Symmetric key cryptography is relatively faster (in performance). However, transferring and retaining the key can become a considerable issue and single cause of security failure.

AES (Rijndael), Serpent and Twofish are popular Symmetric key algorithms.

Asymmetric Key Cryptography

Asymmetric key cryptography is a bit involved. There is a set of keys: one 'private' key and many 'public' keys. However, the secrecy of the private key is compromised if there are multiple public keys. Hence practically in all forms of Asymmetric Key Encryption, only one public to a private key is used. Please remember that these keys are JUST mathematical values. However, practically they are long, random set of numbers, generally represented in hexadecimal system.

A public key can encrypt the message, however only the private key can decrypt it. Also, a private key can encrypt a message that a public key can decrypt. However this reverse encryption is called 'sign' and 'validate' rather than 'encrypt' and 'decrypt' since the algorithm used is different.

DSA/DSS, RSA and Elliptic Curves are popular algorithms in asymmetric key cryptography.

What is a Digital Certificate?

A Digital Certificate relates to asymmetric key cryptography. It is a piece of information containing details like (1) a public key value (2) who issued it (3) whom is it issued to (4) validity and may contain (5) a private key value. The public key is generally a large value, hence the operating system also deduces a hash of the public key and saves it as fingerprint of the certificate (Microsoft calls it thumbprint).

The digital certificate can be in the form of a file, or saved (in case of MS-Windows) in Registry. If the digital certificate is a file and contains a private key, it may also have password protection. If digital certificate is in registry (saved in Certificate Store), the operating system saves the associated private key separately as a file (we will get back to this later in this article).

Windows OS has a Certificate Store where it categorically saves (installs) the certificates. To view an installed certificate in Windows Certificate Store:

1. Start-> Run -> mmc ←
2. File -> Add/Remove Snap-in…
3. Select 'Certificates Snap-in' from left panel and click 'Add' button. Select 'Local Computer' option when asked.
4. In the mmc console, open Certificates-> Trusted Publishers -> Certificates. Double click any certificate on the left

A certificate can have many uses, for e.g. (1) Server Authentication (in SSL) (2) Client Authentication (3) Code Signature (4) Document Signing etc. If you right click a certificate in the certificate store and select ‘Properties’, the ‘General’ tab will show you the list of intended purposes of that certificate.

Public Key Infrastructure (PKI)

Now the question is: who issues a Digital Certificate? The answer is: a Certificate Authority (CA) does it. A CA can be an internal (to your organisation) or external authority. The CA's have a hierarchal structure. Which means there are few top level CAs (like Microsoft, Google and Verisign etc), and several intermediate CAs that are authorised by the top level CAs to issue certificates. These CAs are 'trusted' by your computer. Such trust is established by the presence of related server certificate (public keys of these CAs) in the 'Trusted Root Certification Authorities', 'Enterprise Trust' and 'Intermediate Certification Authorities' stores on your computer. Your operating system has a number of root certificates pre-installed and keeps updating these with security updates. If a certificate is issues by such external well known CAs, your certificate would be valid everywhere around the world (since the well-known CA's are globally recognised). This entire ecosystem made of Digital Certificates, Certificate Authorities and Trust is called Public Key Infrastructure (PKI). This has become one of the most essential and inseparable part of modern day internet and security.

However, a CA can be a local CA server in your organisation. In this case, the certificates issued by it won't be recognized outside of your organisation. However, the server certificate of your internal CA can be installed on such external computer (as a trusted root/ intermediate certificate authority) to trust certificates issued by this CA.

A certificate has an expiry date and/or can also be revoked if in case security is breached in any ways (for e.g. if the private key is stolen). In this case the certificate needs to be renewed. Also note that if the root certificate of the issuing CA of a certificate is revoked/ expired, all certificates issued by this CA would be considered invalid. A Certificate Revocation List (CRL) is maintained by CAs and is used during SSL handshake (explained later) to validate Certificates.

If you want to buy a new server certificate (or renew it), the proper way of doing it is to create a CSR (Certificate Signing Request) and send that request to a certificate authority (CA). To generate a CSR, you first need to create a public-private key and embed only the public key in the CSR. Private Key is NEVER shared with anyone. Not even the CA. It is a personal secret (for you/ your organisation). CSR consists of other details like your Organization name, address and Common Name (FQDN of your server). Tools like IIS Management Console or 'Symantec SSL Assistant' (https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=AR235) help you create the CSR. The certificate (pending for signing by CA) is saved in 'Certificate Enrollment Requests' certificate store on your computer, until the CSR is responded (positively) by the CA. The CSR response is in the form of a .cer file. You can use this to install the certificate. (Note: if your public key is somehow unlinked to the private key (during this process), you can use "Certutil –repairstore" command (from command prompt in admin mode) using the certificate thumbprint to repair the link.)

You can also create a self-signed certificate. This would be valid on your computer only and would be useful in development scenario. Open IIS Management Console (I am using IIS 7.5), click on the top level node (where your server name/computer name is shown) and open 'Server Certificates' in the Features View panel. On the 'Actions' panel on left, you will see several options to create certificate requests (as in image below). Go and explore these options a bit to understand it. Visual Studio creates its own self-signed certificate (and takes care of trusting it). It is shown in the image below:

You can also generate certificates using tools like OpenSSL/ MakeCert to use in your development environment. There are plenty of tutorials on the web on how to use them. Tools like Fiddler can also create certificates for their own use (for e.g. for https traffic debugging). In all scenarios, remember the basic concept: for a computer /user to trust a certificate, the issuer (or root issuer) MUST be trusted.

When a certificate is saved in a file, the file can be in one of the following formats:

1. .cer, .crt or .der: These file contain only the public key part of the certificate (and other certificate info), but NOT the private key. These files can be either Base64 encoded (enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" strings) or Distinguished Encoding Rules (DER) encoded (with a restriction of storing only a single certificate). If the file is Base64 encoded, you can open the file in Notepad and see the entire certificate as an encoded string. Note: this is not the thumbprint. A thumbprint string is much smaller and is a hash of the certificate.
2. .pfx (Personal Information Exchange) or .p12: Contains private key and other extended properties. This is the ONLY format in which private key of a certificate can be exported.
3. .csr (Certificate Signing Request): This is the file that contains the CSR (as discussed above) in encoded format. The data is enclosed between "-----BEGIN NEW CERTIFICATE REQUEST-----" and "-----END NEW CERTIFICATE REQUEST-----".
4. .crl (Certificate Revocation List): Certificate Revocation List as explained previously
5. .key: This contains only the private key. You can see this file if using OpenSSL.
6. There are other lesser known formats like .sst and .sto (Microsoft specific), .pem (used more in Unix world), .p7b, .pp7r and .spc etc.

Secure Socket Layer (SSL)

SSL stands for Secure Socket Layer. In very broad terms, it provides security over http traffic on the internet. It is an Application layer protocol (in OSI stack). Its newer version is called TLS. SSL/ TLS uses underlying SCHANNEL, which relates to transport layer and provides support for various Cipher Suits and encryption etc. SSL 1.0 never got into production in www. However SSL 2.0 and SSL 3.0 are widely in use. SSL 3.1 onwards it got the new name of TLS.

SSL/TLS provides 3 very important features: privacy, authenticity and data integrity. It encrypts the unsecure http traffic using a secure tunnel. The resultant protocol is called 'https'. It uses the PKI at its core.

Before trying to understand SSL, let us first understand few important terms:

1. Server Certificate: It is a Digital Certificate (with a related private key) issued by a well-known CA to a Server. Its 'Issued To' property is typically the host name (for e.g. blah.com) or a domain name with wild card (for e.g. *.blah.com) relating to the website. The Server Certificate (for use in SSL) must be present in 'Personal' store in 'Local Computer account. IIS won't read 'User' account. The certificate must be marked for 'Server Authentication' as it's intended purpose (using it's Enhanced Key Usage property). Also, for use with SSL, make sure that the certificate's private key can be read by the user account the application pool (for the website) runs under (this can be checked by right-clicking the certificate-> All Tasks-> Manage Private Keys).
2. Client Certificate: It is a Digital Certificate (with a related private key) issued by a CA to a Client. The client (in this case) can be the user or the client computer. The certificate must be marked for 'Client Authentication' as it's intended purpose. This certificate is used only if client authentication using certificates is configured for the web application/ web service.

The in depths of SSL is beyond the scope of this article, however, the following image will give a brief understanding. The 'Server' here can be IIS hosted on Windows Server, and the 'Client' can be a browser on user's computer:

Obviously SSL is much more complicated, but the essence is that the server's public key is used by the client to encrypt a symmetric key which only the server can decrypt. Once SSL handshake is done, all further communication is done using symmetric key encryption. If you are asking, why is asymmetric key encryption not used throughout, the answer is that it is complicated, time and resource consuming. So its use is limited to initial handshake only.

Note that for successful SSL handshake, the server's certificate (or the issuer of that certificate) should be trusted by the client, and should be valid.

Let us go through few questions:

1. What if a man-in-the-middle is listening to the entire communication?

   He hasn't got the server's private key. So he cannot know what pre-master key the client has sent or any communication thereafter.

2. What if a hacker pretends to be Server and sends his own self-signed certificate?

   The self-signed certificate sent by the server won't be validated by the client and the user will see SSL error message in the browser (or whatever the client is)

3. What if the hacker's root certificate is already present in the user's trusted certificate store?

   Well this could be a problem. However installing a certificate on the user's computer requires admin privileges. Besides, the hacker won't get a server certificate from a well-known CA for a domain (/website) he doesn't own.

4. How if the hacker just keeps repeating the server response to the client or the client request to the server without knowing the content of the encrypted message (a.k.a. repeat attack)?

   SSL uses 'Message Authentication Code' (MAC) for data integrity. MAC is a hash of the message being sent along with sequence number, message length and two fixed character strings. For further details read this(https://technet.microsoft.com/en-au/library/cc783349%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396#w2k3tr_schan_how_hkrr).

   This mechanism ensures that even if a repeat attack is performed, the server and/or the client will reject the packet.

5. Isn't it possible for the hacker to guess the private key of the server or the symmetric key used after SSL handshake?

   Mathematically it's possible, however practically it is not. The key is generally very complicated and long, it will take considerable time for the hacker to figure it out even if using the latest IT infrastructure.

6. What if a root (well-known) CA is compromised?

   Then the world is in big troubleJ. But this never happens. The root CAs have the highest possible security (and auditing) measures implemented. Hypothetically, if this happens, Microsoft will release a security update that will revoke the root certificate of the compromised CA from user's computer, resulting in SSL failure. Tip: keep your OS updated with critical security updates

7. Does that mean SSL is never hacked?

   There have been instances where vulnerabilities in older versions of SSL were identified (for e.g. the 'Poodle' vulnerability). However technology stacks have been updated to take care of these.

8. Does SSL encrypt images, css, JavaScript and cookies etc?

   Yes it does, however, if you are serving images/css/JavaScript in your html using absolute links and if these links are http (on an https webpage), there is an issue. Different browsers seem to handle such issue differently. Chrome, for example, will display the following error message (seen through developer tools): net::ERR_INSECURE_RESPONSE

   However, IE will display the following:

   

   Figure: IE SSL error

Your entire website (if it is a website) MUST fully use https. Any non http content served over an https channel is a security flaw. Similarly on an ideal ground, make sure that all your cookies are securely saved on client machine (encrypted).

Digital Signature

The three reasons for using Digital Signature are: Authentication, Integrity and Non-repudiation.

Remember how I mentioned earlier that a private key can encrypt (sign) a message as well that the related public key can decrypt (validate)? So if the server is sending a message with digital signature in it, clients can decrypt it and be sure that the message is coming from server only. This is the "Authentication" feature of Digital Signatures.

Now on top of that let's say that the server hashes the entire message (it is sending) and signs the hash with the private key. When the client receives the digital signature (along with the actual message), it can decrypt it and get the hash out of it. It can then generate the hash of the message itself and compare the generated hash with the hash sent by the server. What can be achieved out of all this? : Assurance that the message has not been tempered and is sent only by the server. This is the "Integrity" feature of Digital Signatures.

Digital Signature algorithms also timestamp the message; which means that the message is assured to be sent (by the sender) at that given time. This is the "Non-repudiation" feature of Digital Signatures. Compare this with a manual signature on a paper document. We sign and date the document to acknowledge that we verified the document at the given date (and time).

Please note that the same digital certificate used for SSL should not be used for signing since the purpose of SSL (encryption) is different to digital signature (authentication, integrity and non-repudiation). It is best practice to keep the two functionally and logically separated.

Points of Interest

I hope you enjoyed this article. Please leave your feedback and comments. Lots more coming soon...