A symmetric key encryption algorithm originally published as Rijndael that was later standardized by the U.S. government through the National Institute of Standards and Technology (NIST) in FIPS PUB 197. AES can be used with multiple key sizes, including 128-, 192-, and 256-bit keys.
Uses a two-part key. Each recipient has a private key that is kept secret and a public key that is published for everyone. The sender looks up or is sent the recipient’s public key and uses it to encrypt the message. The recipient uses the private key to decrypt the message and never publishes or transmits the private key to anyone. Thus, the private key is never in transit and remains invulnerable. This system is sometimes referred to as using public keys. This reduces the risk of data loss and increases compliance management when the private keys are properly managed.
Keys used with an asymmetric encryption algorithm, such as RSA, DSA, or Diffie-Hellman. Asymmetric keys come in pairs, with a Public and Private Key. Anything that is encrypted with the Public Key can only be decrypted with the Private Key and vice versa. Typically, the Private Key is kept secret. The Public Key is given out to others who use it to encrypt data. Once it is encrypted with the Public Key, the data can only be decrypted by the person/system that holds the Private Key. In a different use case, the Public Key can be used to verify Digital Signatures created using the Private Key. When using Asymmetric Keys, it is important to assure that the correct Public Key is being used to Encrypt data or verify Digital Signatures to prevent a Man-in-the-Middle Attack.
To either 1) provide credentials to prove one’s identity or 2) validate credentials provided by an individual or system to verify the identity.
The process of linking credentials provided by an individual or system to an identity for the purpose of granting access to a system. Credentials can take various forms –passwords or other ‘shared secrets’, certificates or other key pairs, and tokens are the most common forms. Credentials have different strengths and costs: passwords are inexpensive to set up but are subject to many different attacks (guessing; intercepting); certificates and key pairs are more resource intensive to generate and verify, but are more secure; tokens are more expensive to purchase and verify, but are simpler to use and secure.
A method used to derive or determine the value of an encryption key whereby the attacker tries to decrypt known ciphertext with all possible values of the key—although, in actuality, all possible values should not need to be tried since it is unlikely the key value is the last one that will be tried, especially if good randomization was not used. The length of time required for a Brute-Force Attack is impacted by the length of key, the computing resources available, and the randomness (or, conversely, the predictability) of the key. To minimize the possibility that Brute-Force Attacks are effective in your environment, it is critical to use encryption libraries with high quality pseudo-random number generators and key lengths that are beyond the Brute-Force Attack capabilities of currently available computing resources. Unless you have a staff of cryptographers, it is generally a best practice to track the encryption system certifications and key length recommendations of organizations like the U.S. National Institute of Standards and Technology (NIST), which are currently available athttp://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.
A system or systems where the CRL (Certificate Revocation List) is placed for retrieval by Relying Parties or others throughout the PKI environment. A CDP should be referenced in each Certificate so that Relying Parties can readily check the CRL before relying on the Certificate. Most CDPs are accessible via HTTP or LDAP.
A Certificate is used to reliably connect a Public Key with a particular individual or system (a Subject) so that people/systems (Relying Parties) wanting to Encrypt data for or verify a Digital Signature from that Subject are sure they are using the correct Public Key. X.509 was the original the standard by the ITU-T to define the structure and contents of Certificates. More recently, the IETF released RFC3280 (http://tools.ietf.org/html/rfc3280), which provides a good reference for Certificate contents and usage. Certificates are issued by Certificate Authorities and typically contain the following fields:
Certificate Authorities are organizations or individuals that issue X.509 Certificates and publish Certificate Revocation Lists (CRLs). The process of requesting a certificate typically begins with a Subject submitting a Certificate Signing Request along with any other information required by the CA. The identity of the (Subject) must then be verified. This identification is typically performed by a Registration Authority, which can be an individual or group within the same organization as the CA or in a separate organization. Once the identity has been verified, the CA uses the CSR provided with the request to verify that the Subject has the Private Key corresponding to the Public Key in the CSR. Once the CSR is verified, the CA creates the data structure of the Certificate and signs it. CAs must make their own Certificates (Root or Intermediate Root) available to Relying Parties so that the Certificates they issue can be verified. In addition to issuing Certificates, CAs also publish CRLs to indicate which Certificates have been revoked before they expire. CAs must take appropriate steps to authenticate revocation requests to ensure that Certificates are not improperly revoked.
An incident where a rogue person or organization is able to gain access to or use of the Private Key of a Certificate Authority (whether Intermediate Root or Root) to issue Counterfeit Certificates. There are several possible ways this can be accomplished, including:
If a Certificate Authority Compromise occurs to a Root Certificate Authority (the most damaging kind of compromise), the Root Certificate Authority must notify all Relying Parties who trust their Root Certificate (usually by being stored by their operating system, browser or encryption library) so those parties stop trusting any Certificate issued with that Root Certificate or any Intermediate Root Certificate Authorities under that Root Certificate Authority.
If a Certificate Authority Compromise occurs to an Intermediate Root Certificate Authority, any Root or other Certificate Authorities that have issued CA Certificates to that Certificate Authority must revoke those Certificates. Any Subjects who have been issued Certificates from that Certificate Authority must replace those Certificates immediately, since they can no longer be used due to the Revocation.
