Cryptographic digital signatures use public key algorithms to provide data integrity. When you sign data with a digital signature, someone else can verify the signature, and can prove that the data originated from you and was not altered after you signed it. For more information about digital signatures, see Cryptographic Services.
What is the difference between a digital signature and a digital certificate
Both digital signatures and digital certificates play a huge part in the SSL/TLS ecosystem, and understanding their similarities and differences can be instructional in understanding Public Key Encryption.
Digital Certificate vs Digital signature
Let’s start with a digital signature, then we’ll look at digital certificates and finally we’ll put them all together.
What is a digital signature?
A Digital Signature is, in reality, nothing more than a numeric string that can be affixed to emails, documents, certificates almost anything. We use digital signatures to help determine authenticity and to validate identity. It’s not the same as encryption, it actually works in conjunction with encryption. Digital Signatures fall more into the category of hashing.
Here’s how it works. When you digitally sign something you use cryptographic key to leave a digital signature – that string of numbers – on whatever it is you’re signing. The signature is then hashed along with the file and both the signed file and the hash value forwarded along. When the intended recipient receives the signed file, it’s going to perform the same hash function that signer performed. Hashing takes data of any length and then outputs a fixed-length hash value.
For instance, SHA-256, the hashing algorithm associated with most SSL certificates outputs hash values that 256 bits in length, this is usually represented by a 64 character hexadecimal string. If the hash values match, the signature is authentic and the file’s integrity intact.
What is a digital certificate?
A digital certificate is an X.509 certificate that asserts endpoint identity and facilitates encrypted connections—at least in the context of SSL. We use digital certificates for all range of things, everything from web servers to IoT devices. For the sake of this discussion, let’s stick to SSL/TLS and how they work in that context.
When a browser arrives at the website, it receives a copy of the SSL certificate that’s installed on that server (for the respective site) and performs a series of checks to ensure that the certificate is authentic. The certificate asserts the identity of the server (and possibly organization information depending on certificate type). It also facilitates secure connections between the sites and its users by helping to establish the parameters of the connection (what ciphers and algorithms will be used).
How do Digital Signatures and Digital Certificates differ?
Well, as we’ve just established a digital signature is a string of decimals that is affixed to a file to assist with identifying the signer and ensuring its integrity. A digital certificate is itself a file that is used to assert identity and to facilitate encrypted connections.
How do digital signatures and digital certificates work together in SSL?
Have you ever wondered how your browser knows whether to trust an SSL certificate? Here’s how it works. Every browser uses a root store, which is a collection of trusted roots that is pre-downloaded on your system. Each one of these roots has trusted status by virtue of being saved on your computer. When an SSL certificate is issued, what’s really happening is you’re sending an unsigned certificate to a trusted Certificate Authority, they then validate the information contained in the certificate and applies its digital signature using one of its roots’ private keys.
Or at least, that’s how it works in theory. In reality, trusted roots are much too valuable to issue directly from. Any issue that caused revocation of the root would end up invalidating every SSL certificate it had ever digitally signed. So instead, CAs spin up Intermediate roots. These Intermediate certificates are digitally signed with one of the roots’ private keys, and then the intermediate’s private key is used to digitally sign end user (or leaf) SSL certificates.
Sometimes CAs spin up Intermediate roots for sub-CAs or just use them to issue themselves. There can be multiple intermediates involved in the certificate chain, too.
In order for a browser to trust an end user SSL certificate, it has to follow the certificate chain. It does this by checking what certificate’s private key was used to digitally sign the certificate. Then it looks at the intermediate certificate to see what certificate’s private key was used to sign that. It continues following digital signatures up to the certificate chain until it links back to one of the roots in its trust store.
If the leaf certificate is descendant from one of the trusted roots, by extension the browser trusts it, too. If not, a browser warning is displayed instead.
The digital signature is crucial for authenticating the digital certificate itself.
Both Digital Certificate and Digital Signature is must for the encryption and security of our website and our sensitive/confidential information.
-->Cryptographic digital signatures use public key algorithms to provide data integrity. When you sign data with a digital signature, someone else can verify the signature, and can prove that the data originated from you and was not altered after you signed it. For more information about digital signatures, see Cryptographic Services.
This topic explains how to generate and verify digital signatures using classes in the System.Security.Cryptography namespace.
Generating Signatures
Digital signatures are usually applied to hash values that represent larger data. The following example applies a digital signature to a hash value. First, a new instance of the RSACryptoServiceProvider class is created to generate a public/private key pair. Next, the RSACryptoServiceProvider is passed to a new instance of the RSAPKCS1SignatureFormatter class. This transfers the private key to the RSAPKCS1SignatureFormatter, which actually performs the digital signing. Before you can sign the hash code, you must specify a hash algorithm to use. This example uses the SHA1 algorithm. Finally, the CreateSignature method is called to perform the signing.
Due to collision problems with SHA1, Microsoft recommends SHA256 or better.
Signing XML Files
The .NET Framework provides the System.Security.Cryptography.Xml namespace, which enables you sign XML. Signing XML is important when you want to verify that the XML originates from a certain source. For example, if you are using a stock quote service that uses XML, you can verify the source of the XML if it is signed.
The classes in this namespace follow the XML-Signature Syntax and Processing recommendation from the World Wide Web Consortium.
Verifying Signatures
To verify that data was signed by a particular party, you must have the following information:
The public key of the party that signed the data.
The digital signature.
The data that was signed.
The hash algorithm used by the signer.
To verify a signature signed by the RSAPKCS1SignatureFormatter class, use the RSAPKCS1SignatureDeformatter class. The RSAPKCS1SignatureDeformatter class must be supplied the public key of the signer. You will need the values of the modulus and the exponent to specify the public key. (The party that generated the public/private key pair should provide these values.) First create an RSACryptoServiceProvider object to hold the public key that will verify the signature, and then initialize an RSAParameters structure to the modulus and exponent values that specify the public key.
The following code shows the creation of an RSAParameters structure. The Modulus property is set to the value of a byte array called modulusData and the Exponent property is set to the value of a byte array called exponentData.
After you have created the RSAParameters object, you can initialize a new instance of the RSACryptoServiceProvider class to the values specified in RSAParameters. The RSACryptoServiceProvider is, in turn, passed to the constructor of an RSAPKCS1SignatureDeformatter to transfer the key.
The following example illustrates this process. In this example, hashValue and signedHashValue are arrays of bytes provided by a remote party. The remote party has signed the hashValue using the SHA1 algorithm, producing the digital signature signedHashValue. The RSAPKCS1SignatureDeformatter.VerifySignature method verifies that the digital signature is valid and was used to sign the hashValue.
This code fragment will display 'The signature is valid' if the signature is valid and 'The signature is not valid' if it is not.