Glossary

Advanced Encryption Standard (AES)

 

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.
 

Asymmetric Key Management

 

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.

 

Asymmetric Keys

 

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.

 

Authenticate

 

To either 1) provide credentials to prove one's identity or 2) validate credentials provided by an individual or system to verify the identity.

 

Authentication

 

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.

 

Brute-Force Attack

 

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 at http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.

 

Certificate

 

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:

  1. Valid From (notBefore) – The issue date of the Certificate. The Certificate should not be used for Encryption prior to this Date. In addition, any Digital Signatures applied prior to this date with the Private Key that corresponds to the Certificate should not be considered valid.
  2. Valid To (notAfter) – The date the Certificate expires (see Expiration Date).
  3. Subject DN – The fully distinguished name of the Subject (the individual or system the Certificate is issued to and whose Public Key is contained in the Certificate).
  4. Issuer DN – The fully distinguished name of the Certificate Authority
  5. Serial Number – A unique identifier for the Certificate from the CA. The combination of the Serial Number and the Issuer DN should allow the Certificate to be identified versus all other Certificates.
  6. Public Key – The Public Key of the Subject.
  7. Signature – The Digital Signature of the CA on the Certificate. This is what Relying Parties used to verify that the Certificate was issued by the CA.
  8. Extensions – X.509 v3 allows for standard and proprietary extensions to be added to Certificate which contain additional information that may be useful to Relying Parties. Examples of extensions include Key Usage (what types of operations the Public Key and Certificate be used for, such as data encryption, CA, digital signature), Subject Alternative Names (names in addition to the Subject DN that the Subject may be identified by), and CRL Distribution Points.
 

Certificate Authority (CA)

 

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.

 

Certificate Authority Compromise (CA Compromise)

 

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:

  1. Certificate Authority System Compromise: A perpetrator infiltrates (e.g. via malware) the system at the Certificate Authority where Certificates are signed and (without getting a copy of the Certificate Authority Signing Key), gets one or more Counterfeit Certificates issued.
  2. Certificate Authority Signing Key Theft: A perpetrator steals a copy of the Certificate Authority Signing Key and is able to issue Counterfeit Certificates at will.
  3. Certificate Authority Signing Key Derivation: A perpetrator uses computational methods (e.g. Brute-Force Attack or Factoring) to derive or determine the Certificate Authority Signing Key and is then able to issue Counterfeit Certificates at will.

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.

 

Certificate Authority Signing Key

 

This is the Private Key used by a Certificate Authority to digitally sign Certificates. Certificate Authority Signing Keys must be kept very secure so that Counterfeit Certificates cannot be issued.

 1 2 3 >  Last ›