Changes to 05-SEP-2013: PKI and Tcl between r12 and r13
'''It's secure. Trust me.'''
Public Key Infrastructure (PKI) is, as the name implies, all of the infrastructure required to operate a public key cryptography system. The name also implies that PKI is a complex system with lots of mandatory parts however this is not the case. A simple PKI implementation is fairly straight-forward.
(blank line)
The goal of PKI is to provide a mechanism to trust an unknown party. This is done using certificates, which certify that another entity (which you may trust) has verified that this entity is who it claims to be. This certificate is presented by the unknown party as a means of identifying itself to you.
(blank line)
So what is to stop someone from providing false information in a certificate ? Well, that's where the public key aspect of PKI comes into play. Certificates are digitally signed by the issuer (also called a "Certificate Authority") of the certificate using public key cryptography.
(blank line)
To explain how digital signatures work we must first explain public key cryptography. Public key cryptography uses the properties of certain mathematical operations to perform operations on numerical values that can only be reversed or verified with the "opposite" key. That is, if something is encrypted with the private key it can only be decrypted or verified with the public key and conversely if something is encrypted with the public key it can only be decrypted or verified with the private key (and not the public key).
(blank line)
The most common public key cryptography algorithm in use today is RSA [[citation needed]], and it is also one of the easiest to demonstrate. RSA is named for Ron Rivest, Adi Shamir, and Leonard Adleman who made the algorithm public and are thus widely credited as the inventors of the algorithm.
(blank line)
RSA is described in PKCS #1 [http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf] which was later published as RFC 3447 [http://www.ietf.org/rfc/rfc3447.txt] but a simple definition of applying RSA is "modular exponentation". That is modular arithmetic (as in the modulus operator) applied to values that have had the the exponentiation operator applied to them. For example
The purpose of Public Key Infrastructure (PKI) is to provide a mechanism to establish the authenticity of an unknown party. Most people assume PKI is a complex system with a lot of moving parts. However, this is not the case. A simple PKI implementation is fairly straight-forward.
(blank line)
PKI establishes authenticity by using certificates, which certify that another entity (whom you already trust) has verified that this entity is who it claims to be. This certificate is presented by the unknown party as a means of identifying itself to you.
(blank line)
So what is to stop someone from providing false information in a certificate? That's where the public key aspect of PKI comes into play. Certificates are digitally signed by the issuer, also called a Certificate Authority, using public key cryptography.
(blank line)
To explain how digital signatures work, we must first explain public key cryptography. Public key cryptography uses mathematical operations to perform operations on numerical values that can only be reversed or verified with the ''opposite'' key. That is, if something is encrypted with the private key it can only be decrypted or verified with the public key. Conversely, if something is encrypted with the public key it can only be decrypted or verified with the private key.
(blank line)
The most common public key cryptography algorithm in use today is RSA [citation needed]. It is also one of the easiest to demonstrate. A simple definition of applying RSA is ''modular exponentiation''. Modular arithmetic (as in the modulus operator) is applied to values that have had the the exponentiation operator applied to them. For example:
26729 (plain-text) ^ 65537 (public-exponent) mod 37837 (public-modulus) = 36784 (cipher-text)
is modular exponentiation of `26729` raised the power of `65537` all modulo `37837`, which results in `36784`.
Looking closer at this example of modular exponentiation we can see some of the public key cryptography properties that we need starting to emerge. Specifically we cannot take the `cipher-text` and convert it back to the `plain-text` with just the information that we know. We must know the `private-exponent` (or be able to derive it by factoring the `public-modulus`, but more on that later).
Thus the above example is also an example of encrypting the value `26729` (which is 0x6869, or "hi" in ASCII) with an RSA key whose `public-exponent` (often simply referred to as the exponent) is `65537` and whose public-modulus (often simply referred to as the modulus) is `37837` resulting in the encrypted value of `36784`.
However, if we know the private key we can reverse the operation:
36784 (cipher-text) ^ 40193 (private-exponent) mod 37837 (public-modulus) = 26729 (plain-text)
This is not too useful for digital signatures because it requires the `private-exponent` to do anything meaningful. With a digital signature we want to perform an operation on some plain-text using our private data (for RSA `private-exponent`) that can be verified using only public information (such as `public-exponent` and `public-modulus`). Fortunately RSA allows us to do that by simply swapping the values around. That is:
This is not very useful for digital signatures because it requires the `private-exponent` to do anything meaningful. With a digital signature, we want to perform an operation on some plain-text using our private data (for RSA `private-exponent`) that can be verified using only public information (such as `public-exponent` and `public-modulus`). Fortunately RSA allows us to do that by simply swapping the values around. That is:
12345 (plain-text) ^ 40193 (private-exponent) mod 37837 (public-modulus) = 3293 (cipher-text)
which CAN be reversed using only public information, as in:
3293 (cipher-text) ^ 65537 (public-exponent) mod 37837 (public-modulus) = 12345 (plain-text)
RSA guarantees that the chance of there being another value of `private-exponent` which generates the same `cipher-text` for a given `plain-text` is extremely low relative to the size of the key. In this way we can assert that if a given `cipher-text` can be decrypted to a `plain-text` using a given `public-exponent` and `public-modulus` then it must have been encrypted with the secretly held `private-exponent` and thus as long as `private-exponent` is protected as a secret only the holder could have generated this message.
(blank line)
RSA guarantees that the chance of there being another value of `private-exponent` which generates the same `cipher-text` for a given `plain-text` is extremely low relative to the size of the key. Therefore we can assume that if a given `cipher-text` can be decrypted to a `plain-text` using a given `public-exponent` and `public-modulus` then it must have been encrypted with the secretly held `private-exponent` and thus as long as `private-exponent` is protected as a secret, only the holder could have generated this message.
(blank line)
So to generate a digital signature one just encrypts the data with the "private key" (`private-exponent` in RSA) and the message is valid when decrypted with the "public key" (`public-exponent` in RSA) then it must have been written by the holder of the private key. --> So to generate a digital signature, one just encrypts the data with the "private key" (`private-exponent` in RSA) and the message is valid when decrypted with the "public key" (`public-exponent` in RSA) then it must have been written by the holder of the private key.
This is certainly a valid and workable solution for some messages, however there are some limitations of RSA that make it not a desirable general solution. Specifically RSA cannot encrypt messages larger than the size of the key. That is, if the key is 16 bits then the `plain-text` message can be no larger than 16 bits.
(blank line)
Instead what is done is a cryptographically secure message digest algorithm such as MD5 (defined in RFC '''???'''), SHA1 (defined in RFC '''???'''), SHA256 (defined in RFC '''???'''), etc is used to compute a digest of the message which is typically much smaller than the message itself. This digest is then encrypted with the private key and verified with the public key. In this way arbitrarily long messages can be digitally signed using RSA.
(blank line)
This property of digital signatures means that if the certificate is altered or forged after being signed it will be detected.
(blank line)
This is a workable solution for short messages. However, RSA cannot encrypt messages larger than the size of the key. That is, if the key is 16 bits then the `plain-text` message can be no larger than 16 bits. Instead a cryptographically secure message digest algorithm such as MD5 (defined in RFC '''???'''), SHA1 (defined in RFC '''???'''), or SHA256 (defined in RFC '''???''') is used to compute a digest of the message which is typically much smaller than the message itself. This digest is then encrypted with the private key and verified with the public key. In this way, arbitrarily long messages can be digitally signed using digital signatures, ensuring that if the certificate is altered or forged after being signed it will be detected.
(blank line)
So what makes up a certificate ? Certificates are specified by the ITU-T standard X.509 [http://www.itu.int/rec/T-REC-X.509-200811-I/en] and contain the following information:
1. X.509 Standard version number (optional), which identifies the revision of X.509 that this certificate is written in; --> 1. X.509 Standard version number (optional) which identifies the revision of X.509 that this certificate is written in
2. Issuer, which is the "distinguished name" of the entity who issued (that is, signed) the certificate; --> 2. Issuer, which is the "distinguished name" of the entity who issued (that is, signed) the certificate
3. Serial Number, which is a unique number per issuer to uniquely identify this certificate from the issuer; --> 3. Serial Number, which is a unique number per issuer to uniquely identify this certificate from the issuer
4. Subject, which is the "distinguished name" of the entity who is being certified (and also who holds the private key); --> 4. Subject, which is the "distinguished name" of the entity who is being certified (and also who holds the private key)
5. Issue date and Expiration date, which define the time frame in which the certificate is valid; --> 5. Issue date and Expiration date, which define the time frame in which the certificate is valid
6. The public key, including the algorithm and algorithm-specific public key data -- for RSA this is the `public-modulus` and `public-exponent`; --> 6. The public key, including the algorithm and algorithm-specific public key data -- for RSA this is the `public-modulus` and `public-exponent`
7. If this is X.509 version number 3 then X.509 extensions may be specified which restrict the uses of this certificate; and --> 7. If this is X.509 version number 3 then X.509 extensions may be specified which restrict the uses of this certificate
8. The digital signature of all of the previous data, which for RSA is the cryptographic message digest of the previous data (encoded in ASN.1 Distinguished Encoding Rules (DER) as specified by ITU-T standard X.690 [https://www.itu.int/rec/T-REC-X.690-200811-I/en]) and then encrypted with the private key of the Issuer
So now we have a system where an unknown and untrusted can assert to you a fully-qualified (also known as "distinguished") name and also provide a reference to who is certifying that this assertion is true within the parameters specified in the certificate.
(blank line)
What is to stop someone from taking a certificate from an existing entity, which must be publicly accessible otherwise there would be no way to identify the entity, and using it ? Once again, public key cryptography is the answer here. You see a certificate is not proof of anything other than the Issuer signed a request for the Subject -- it does not prove that you you are talking to is legitimately the subject specified in the certificate. But it ''does'' provide you a mechanism to do that. The public key being certified are in the certificate so all that is needed is for you to issue some sort of challenge for the party presenting the certificate to prove that it has the private key that corresponds with the certified public key.
(blank line)
So now we have a system where an unknown and untrusted party can assert to you a fully-qualified (also known as "distinguished") name and also provide a reference to who is certifying that this assertion is true within the parameters specified in the certificate.
(blank line)
How this challenge is done depends on the protocol and is outside the scope of this document. --> What is to stop someone from taking a certificate from an existing entity, which must be publicly accessible otherwise there would be no way to identify the entity, and using it? Once again, public key cryptography is the answer here. A certificate only proves that the Issuer signed a request for the Subject -- it does not prove that you you are talking to is legitimately the subject specified in the certificate. But it ''does'' provide you a mechanism to do that. The public key being certified is in the certificate so all that is needed is for you to issue some sort of challenge for the party presenting the certificate to prove that it has the private key that corresponds with the certified public key. How this challenge is done depends on the protocol and is outside the scope of this document.
Only in r12
Only in r13 --> Modified slightly between r12 and r13