This article is a non-direct continuation of the “What is a Public Key Infrastructure (PKI)?” found on the Petri IT Knowledgebase.
Public-Key Cryptography and One-Way Functions
As written in previous articles, Public-Key cryptography (as opposed to symmetric key cryptography) relies on one-way functions, which are functions that are easy to calculate but hard to invert or reverse without prior knowledge. Public-key cryptography exploits this asymmetry of effort to create one-way functions: functions where anyone can perform one operation (encryption or verification of signature), but it is extremely difficult to invert the operation (which might be the decryption or creation of signature) without having full information.
This is accomplished cryptographically through the use of two related, but different keys – also known as a key pair. These keys are created at the same time and are mathematically related to each other. The private key is required to invert operations performed with the public key, and vice versa. The public key is widely distributed, but the private key kept private. This is called a many to one function, i.e. anyone can use the public key to perform cryptographic operations, but only the person holding the private key can invert it. But this mechanism also allows for a one-to-many function in which the person holding the private key can perform an operation, and anyone holding the public key can invert. These two functions are used for encryption (many people can encrypt, only one can decrypt), and signature (only one can sign, many people can verify signature).
http://msdn.microsoft.com/workshop/security/capi/PKCB/crypt2.asp
Symmetric Cryptography
Symmetric algorithms are the most common type of encryption algorithm. The reason why they are known as symmetric is because the same key is used for both encryption and decryption. Unlike the keys used with public-key algorithms, symmetric keys are frequently changed. For this reason, they are referred to here as session keys.
When compared to public-key algorithms, symmetric algorithms are very fast and require less CPU-intensive calculations. That is why they are preferred when encrypting large amounts of data. Some of the more common symmetric algorithms are RC4, and the Data Encryption Standard (DES).
Many modern cryptographic protocols use a combination of public-key cryptography and symmetric cryptography to obtain the benefits of both: public-key algorithms to exchange a symmetric key, and then use symmetric algorithms to quickly encrypt or decrypt data. Such encryption protocols include TLS, SSL, IPSec, EFS, S/MIME and others.
http://msdn.microsoft.com/workshop/security/capi/PKCB/crypt3.asp
Encryption and Decryption
When using data encryption, a plaintext message can be encoded so it appears like random gibberish and is very difficult to transform back to the original message without a secret key. The plaintext message can consist of ASCII text, a database file, or any data you want to store or transmit securely.
Note: Plaintext is used to refer to data that has not been encrypted, while cipher text refers to data that has.
Once a message has been encrypted, it can be stored on any non-secure media or transmitted on a non-secure network, and still remain secret. Later, the message can be decrypted into its original form.
When a message is encrypted, an encryption key (or public key) is used. The encryption key is analogous to the physical key that is used to lock a padlock. To decrypt the message, the corresponding decryption key (or private key) must be used. It is very important to properly restrict access to the decryption key, because anyone who possesses it will be able to decrypt all messages that were encrypted with the matching encryption key.
The interesting thing about using this type of encryption is not the data encryption/decryption process itself – that is pretty straightforward – but how to keep the keys safe, and how to transmit them securely to other users.
http://msdn.microsoft.com/workshop/security/capi/PKCB/crypt4.asp
Hashing, Digital Signatures, and Verification
Unlike encryption which prevents the message from being read by anyone besides the holder of the private key, digital signatures can be used when you have a message that you plan to distribute in plaintext form, and you want the recipients to be able to verify that the message comes from you and that it hasn’t been tampered with since it left your mailbox. Signing a message does not alter the message, it simply generates a digital signature string you can bundle with the message or transmit separately.
Digital signatures are generated using public-key signature algorithms. A private key is used to generate the signature, and the corresponding public key is used to validate the signature.
Digital signatures allow users to verify that a document came from the holder of a private key, and hasn’t changed since signature. The document may or may not be encrypted in addition to being signed.
Note: Good cryptographic procedure is always to sign before encrypting – that way you know what’s being signed. Imagine signing an envelope without knowing what’s inside!
Digital signatures are created by encrypting a hash of the document with a private key. The hash of the document is basically a miniature fingerprint of the document. The hashing functions used are similar to the hashing functions in use throughout computer science – functions that take a large data input and return a smaller output of fixed size.
Hashing functions should be as “one- way” as possible: if you know the value of a hash (and potentially the original document), it should be very difficult to create another document with the same hash value. It should be especially difficult (ideally impossible) to modify the original document by a character here or there and obtain the same hash value.
A digital signature is hash encrypted with a private signature key. Verifying a digital signature is done by decrypting the signature using the public signature key, and matching the result against a hash of the original document.
Note: Good cryptographic procedure recommends using a different key specifically for signature, rather than a general purpose key for both encryption or key exchange and signature.
The strength of a signature is dependent on the quality of the one-way hash function, and the strength of the encryption of that hash. If the one-way hash function can be subverted, than the original document might be changed. If the encryption isn’t sufficiently strong, then the document might have come from someone other than the holder of the private key.
So far, we are able to encrypt and decrypt documents, and sign and verify their signatures. However, both of these functions require our ability to distribute public keys and match them to the holder of the private key, which turns out to be one of the biggest issues with encryption.
- If Alice wants to send Bob some encrypted data, she needs to know his public key.
- If Bob wants to verify the digital signature on a document as coming from Alice, he needs to know her public key.
So, how does someone know that the public key they’ve just been handed does indeed belong to the person they claim they are? What if you were handed a public key and were told that this was the public key for your bank, would you believe it? One very appropriate answer to this question might be “Who told me?” or “who vouches for the credibility of this public key?”
http://msdn.microsoft.com/workshop/security/capi/PKCB/crypt5.asp
Certificates, Certificate Authorities (CAs) and Certificate Revocation Lists (CRLs)
Certificates are the ones that help answer the above questions. Basically, certificates are signed documents which match public keys to other information, such as a name or e-mail address. Certificates are signed by certificate authorities (CAs), which issue certificates. In essence, a certificate authority is a commonly trusted third-party, who is relied upon to verify the matching of public keys to identity, e-mail name, or other such information (e.g. issuance of credit, access privileges).
The benefit of certificates and CAs is that if two people both trust the same CA, then by exchanging certificates signed by the CA, they can learn each other’s public keys, and use them to encrypt data and send it to one another or to verify the signatures on document.
Certificate creation is straightforward, and has six steps:
- Key generation: the individual requesting certification (the applicant) (not the CA) generates key pairs of public and private keys.
- Matching of policy information: the applicant packages up the additional information necessary for the CA to issue the certificate (e.g. proof of identity, e-mail address and so on). The precise definition of this information is up to the CA.
- Sending of public keys and information: the applicant sends the public keys and information (often encrypted using the CA’s public key) to the CA.
- Verification of information: the CA applies whatever policy rules it might require to verify that the applicant should receive a certificate. Usually, you will pay more in order to reach a higher level of authenticity.
- Certificate creation: the CA creates a digital document with the appropriate information (public keys, expiration date, other data) and signs it using the CA’s private key.
- Sending/posting of certificate: The CA may send the certificate to the applicant, and/or post it publicly as appropriate.
To verify a certificate, all that is necessary is the public key of the CA (plus a possible check against a revocation list). Certificates and CA’s reduce the public-key distribution problem from verifying and trusting one (or more) public keys per individual to verifying and trusting the CA’s public key and relying on that to allow verification of others.
Multi-Level Certificate Authorities
Certificate authorities can also certify sub-authorities, also known as subordinate CAs, who can issue their own certificates. This allows “trees of trust” which among other things reduces the burden on a centralized server. For example, imagine a large corporation with 4 divisions. The main CA would certify four sub-CAs (one per division), which would issue certificates for everyone in each division. Cross-divisional certification works so long as everyone has the public key of the main CA, which it can use to verify the credential of the sub-CA.
The Life of a Certificate
Certificates have a limited life. They are requested, often paid for, created, and then either are revoked (if compromised) or expire. Expiration is important, as advances in computing power, and the potential for the discovery of holes in algorithms or protocols may make certificates unreliable. Revocation is important if private keys are compromised, or there has been a change in status or policy (e.g. a Certificate indicating that TomC is an employee of The Firm should be revoked if he leaves The Firm).
Revocation of a certificate uses a Certificate Revocation List (CRL). A CA might want to revoke a certificate in case of inappropriate use, frauds, CA compromise and so on, and in order to let all the potential users that might need to use the specific certificate, it publishes the certificate in a CRL.
It is possible to configure the applications using the certificate to check against a CRL to ensure validity of the certificate.
http://msdn.microsoft.com/workshop/security/capi/PKCB/crypt6.asp
Protocols and Examples
A cryptographic protocol is a combination of the basic cryptographic elements of encryption/decryption, hashing, signature, signature verification, certificate issuance, checking and revocation to accomplish some desired goal. For example:
- Key Exchange protocols, where two parties who want to communicate, but don’t already have each others’ public keys or access to certificates, can exchange keys;
- Secure Channel protocols (such as SSL), where two parties want private, authenticated communications over a public network.
Measures of Strength
The strength of the operations depends on a number of things. All public-key cryptographic operations and protocols require that the private keys be kept private. Here’s a summary of some of the additional measures:
- Public-key encryption: depends on the strength of the algorithm used (e.g. RSA), and the length of the keys used.
- Symmetric-key encryption: depends on the strength of the algorithm used (e.g. DES, RC4) and the length of the keys used.
- Hashes: depends upon the hash algorithm used.
- Digital signature: depends on the hash algorithm used, the encryption algorithm used to sign the hash, and the length of the keys used.
- Certificate: depends on the choice and implementation of policy by the CA, on the digital signature algorithms used, on the revocation policy used, and the availability and use of CRLs.
Related Articles
Recent Security Forum threads
Got a question? Post it on our Security Forums!