Certificate-Based Operations

Module Objectives By the end of this module participants will be able to: Define how cryptography is used to secure information from unintended audiences Identify the information stored in a digital certificate Describe how digital certificates are used for authentication on the FortiGate unit Create a certificate request and submit the request to an authorized CA Import digital certificates onto the FortiGate unit Describe how SSL content inspection is performed

Cryptography Internet Click here to read more about cryptography

Cryptography Internet Cryptography provides a base for protecting data exchanged between two parties in an electronic transaction Elements include: Data privacy Data integrity Authentication Non-repudiation Click here to read more about cryptography

Cryptography – Data Privacy ?

? Encryption can be used to hide information as it travels across the network Data is private while in transit since the encrypted information is unintelligible to an intruder Only the intended recipient will have the ability to decipher (decrypt) the data

Cryptography – Data Integrity Data as created Data as received Match

Cryptography – Data Integrity Data as created Data as received Match Allows the recipient to verify that information has not been modified while in transit Date as created matches the data as received Data has not been tampered with between sender and recipient

Cryptography – Authentication Identity information appended to data Sender identify verified and trusted

Cryptography – Authentication Identity information appended to data Sender identify verified and trusted Recipient can verify the identity of trusted senders Confirm the origin of the data

Cryptography – Non-Repudiation Identity information appended to data Sender can not deny participating in exchange

Cryptography – Non-Repudiation Identity information appended to data Sender can not deny participating in exchange Sender can not deny participating in the transaction at a later date Identity information binds sender to the data exchanged

Symmetric Cryptography Algorithm PlaintextSymmetric algorithm Encrypted text Symmetric algorithm Plaintext At senderAt recipient Random number between 40 and 256 bits

Symmetric Cryptography The key used to encrypt is the same as the one used to decrypt This key must be shared between the sender and the recipient Key must be securely delivered to the recipient before they can decrypt the data Conversion from plaintext to encrypted text and back is fast Suitable for bulk data Key management issues Number of keys that must be managed by a user increases with size of community

Asymmetric Cryptography Symmetric Cryptography Each user holds one key for each recipient they communicate securely with. This key must be securely delivered to each recipient. Asymmetric Cryptography Each user holds a pair of keys; one key is freely distributed (public key), the other key is kept secret by the holder (private key). Public Private

Asymmetric Cryptography Public Private Public Private Data encrypted using the public key must be decrypted using the private key Data encrypted using the private key must be decrypted using the public key

Asymmetric Cryptography Public Private Public Private Data encrypted using the public key must be decrypted using the private key Data encrypted using the private key must be decrypted using the public key Public and private keys work as matched pairs Any operation performed with one key (for example, encryption) must be undone (for example, decryption) with the other key in the pair

Asymmetric Cryptography Public Private Public database Public Private Public Private

Asymmetric Cryptography Public database Public keys can be made available to the community of users through a public repository or distributed in any other method Public keys is freely available Private key must be stored securely and accessible only to the key holder Must be password protected to prevent unauthorized access

Asymmetric Cryptography Algorithm PlaintextAsymmetric algorithm Encrypted text Asymmetric algorithm Plaintext At senderAt recipient Public Private

Asymmetric Cryptography Key lengths longer 512 to over 8,000 bits Only intended recipient will have private key to decrypt Must be kept secure Removes need to deliver secret key to recipient Solution to key management issues

Diffie-Hellman This variation of asymmetric algorithm allows the exchange of secret key data without any prior secrets Combine private key of one party with public key of other Can compute same shared key Resulting key used for cryptography Generates keys only Diffie-Hellman does not encrypt data

Digital Certificates Private Certification Authority Public database Public Click here to read more about digital certificates

Digital Certificates Private Certification Authority Public database The public portion of the key pair is submitted to a Certification Authority User information and key data is verified Data published in industry-standard format and the digital signature of CA is applied Signature guarantees integrity of data and that it has been verified by a trusted party Digital certificate published to public repository Click here to read more about digital certificates

Digital Certificate Contents Certificate Format Version Certificate Serial Number CA Signature Algorithms Issuer Name (X.500) Validity Period Subject Name (X.500) Public Key Issuer Alternate Identifier User Alternate Identifier Extension V RSA with MD5 dc=com, dc=company, ou=ca1 August 15, 2008 to August 15, 2011 dc=com, dc=company, ou=ca1, ou=John Doe 73ks6dm3s34pm Value Certification Authority Digital Signature

Digital Certificates Algorithm PlaintextAsymmetric algorithm Encrypted text Asymmetric algorithm Plaintext At senderAt recipient Private Issued by trusted CA? Expiration? Revocation? Public

Digital Certificates Algorithm PlaintextAsymmetric algorithm Encrypted text Asymmetric algorithm Plaintext At senderAt recipient Private Issued by trusted CA? Expiration? Revocation? Public Applications performing encryption operations will always verify the digital certificate to confirm the following Certificate was issued by a trusted CA Verifies digital certificate on certificate Certificate is still within its validity period Certificate has not been deemed untrustworthy by the CA Verifies serial number against the certificate revocation list

Public-Key Infrastructure User registration Issuing certificates Maintaining revocation information Updating keys Updating certificates Publishing certificates Managing policies Creating keys System of policies, procedures and technologies for management of public key information

Secure Socket Layer Security Hello Issued by trusted CA? Still valid? Has it been revoked? Public Secret Encrypted Secret Private Secret Symmetric key Click here to read more about Secure Socket Layer security

Secure Socket Layer Security Hello Symmetric keys are derived from the exchange of shared secrets between the web browser and the FortiGate unit Used to encrypt data exchanged between the web browser and the FortiGate device These symmetric keys are valid for the session only Web browser authenticates identity of web server Will only accept data in certificates that are signed by trusted CAs Click here to read more about Secure Socket Layer security

Certificates On a FortiGate Unit Certificate signed by a trusted Certification Authority Certificate self-signed by FortiGate unit Private Public

Certificates On a FortiGate Unit Certificate signed by a trusted Certification Authority Certificate self-signed by FortiGate unit Private Public portion of key pair can be published in certificate format by either the FortiGate unit itself or a trusted Certification Authority Data published in industry-standard format and a digital signature is applied Signature guarantees integrity of data Digital certificate forwarded to the web browser whenever an SSL-encrypted session is requested

Generating a Certificate Request Request submitted to Certification Authority Private Public + PKCS#10 Certificate Request

Generating a Certificate Request Request submitted to Certification Authority Private + PKCS#10 Certificate Request Complete the Certificate Request form on the FortiGate unit to generate a PKCS#10 formatted request Request file will include the public key of the FortiGate unit Request file is then submitted to a trusted CA Status of certificate will be listed on FortiGate unit as Pending

Generating a Certificate Request

Importing Certificates Private Public CA CRL Certificate of FortiGate unit Verification certificate of CA Certificate Revocation List

Importing Certificates Private CA CRL The CA will generate the digital certificate which is then imported onto the FortiGate unit Verification certificate of the CA creating the certificate must be installed on the FortiGate unit Used to verify digital signatures on all certificates generated by the CA Certificate Revocation List must be imported onto FortiGate unit on a regular basis Revocation information from CA must be kept up to date

Importing the CA Certificate

Backing Up and Restoring Certificates Certificate of FortiGate unit CA Verification certificate of CA Private Password-protected PKCS#12 file

Backing Up and Restoring Certificates Certificate of FortiGate unit CA Verification certificate of CA Private Password-protected PKCS#12 file The FortiGate unit private key and certificates must be backed up in case the device configuration is restored TFTP server required for the backup Keys and certificates stored in a password-protected PKCS#12 file File is imported back onto FortiGate unit after the restore operation Password from backup required

Installing a CA Certificate in the Browser

The verification certificate from the FortiGate unit must be imported into the web browser certificate store if using self-signed certificates Prevent warnings about untrusted content

Certificate Revocation List Certification Authority Serial Number: CRL Serial Number: ?

Certificate Revocation List Certification Authority Serial Number: Serial Number: ? Certificate Revocation List (CRL) contains the serial numbers of all certificates deemed untrustworthy CRL will always be checked before a certificate is used to insure that it is still trusted CRLs must be kept up to date on the FortiGate unit Must be manually copied from the CA to the FortiGate unit on a regular basis

SSL Content Inspection ? Web server SSL-secured session Click here to read more about SSL content inspection on certain models of FortiGate unit

SSL Content Inspection ? Web server SSL-secured session FortiGate unit is unable to perform inspection operations on data exchanged during an SSL session Data is encrypted Filters are bypassed for SSL communication Click here to read more about SSL content inspection on certain models of FortiGate unit

SSL Content Inspection Web server SSL-secured session

SSL Content Inspection Web server SSL-secured session The FortiGate unit SSL proxy can serve as a middleman in the SSL communication between the web browser and the web server Data is decrypted by FortiGate unit, is scanned by application proxies, then is re- encrypted for delivery to the web server Available on certain models of FortiGate device

Enabling SSL Content Inspection

SSL Content Inspection Concerns Mimics man-in-the-middle attack Does security policy allow it? Self-signed certificates on FortiGate unit may be untrusted Untrusted Certificate warning presented to user Verification certificate of FortiGate unit must be installed on browser SSL content inspection not performed if using client certificates Forces client-side authentication Certificate on FortiGate unit between client and web server created on the fly Certificate of web server substituted by certificate created by FortiGate unit

Student Resources Click hereClick here to view the list of resources used in this module