(RHCA)Red Hat Enterprise Linux RHS333: Red Hat Enterprise Security: Network Services

Unit 3

Cryptography
Objectives

Upon completion of this unit, you should be able to:
  • Network communication security
  • Introduction into cryptography
  • OpenSSL
Network Security

  • Communication channels are often vulnerable to a “man in the middle” attack
    • Eavesdropping
    • Data injection
    • Session hijacking
  • Authentication and encryption of messages can protect data integrity and confidentiality
Switches and Security

  • A network switch does not provide security
    • Provides improved bandwidth management
  • Attacks on network switches include
    • MAC Flooding
    • MAC Duplication
    • ARP Redirection
  • Port security, static ARP entries, and arptables may provide some defense
Cryptography

  • Key building block of secure protocols
  • Authentication and confidentiality of data
    • Encryption does not automatically imply authentication, and vice versa
    • Generally does not hide the fact that communication is taking place, or with whom
  • Cryptography does not solve every problem
    • May be easier to break host security than break an encrypted communication
Cryptography

  • Kerckhoffs' Principle
    • Security must depend on secrecy of the key, not on secrecy of the encryption method
    • Harder to replace algorithms than secret keys
  • Secure authentication and integrity can be more important than secure encryption
    • Cryptography can help with both
    • Authentication may not automatically handle blocked or repeated messages
OpenSSL

  • libcrypto: Generic encryption support
    • Provides cryptographic functions
  • libssl: Support for TLS/SSL protocols
    • Connection-based security for authentication, confidential data transfer, session integrity
  • openssl: Multi-purpose encryption utility
    • Generate encryption keys, digital certificates
    • Encrypt/decrypt data manually
Symmetric Encryption

  • Secret key used to both encrypt and decrypt
  • Block ciphers encrypt fixed-size blocks of plaintext as fixed-size blocks of ciphertext
    • Block cipher modes are used to encrypt data larger than a single block (ECB, CBC, etc.)
  • Algorithms: DES, 3DES, Blowfish, AES, etc.
  • Utilities: gpg, openssl enc
Cryptographic Hashes

  • Converts an input string of any length to an output string of fixed length
    • One-way: not feasible to get plaintext from hash
    • Collision-free: not feasible to find two strings that hash to the same output
  • Algorithms: CRC-32, MD5, SHA-1, etc.
    • CRC-32 is not cryptographically secure!
  • Utilities: sha1sum, md5sum, cksum, openssl dgst
Message Authentication Codes

  • Secret key maps plaintext to random output
  • Used for preventing message tampering
    • Attacker needs secret key to forge MAC value
  • CBC-MAC: use block cipher to construct
    • Encrypt the message in CBC mode and throw away all but the last block of output
  • HMAC: use keyed cryptographic hash
User Authentication

  • Cryptographic hash of account password is stored in on-line database
    • Made more difficult to break by adding random “salt” to password
    • MD5-based hash by default, old modified DES version also available
  • System hashes password given to login
  • If passwords match, user is authenticated
  • Utilities: passwd, openssl passwd

Asymmetric Encryption

  • Public key to encrypt, private key to decrypt
    • Based on trapdoor one-way functions
  • Partial solution to key distribution problem
    • Can give the public key to everybody
  • Algorithms: RSA, ElGamal
  • Utilities: gpg, openssl rsautl
Digital Signatures

  • Private key to encrypt, public key to decrypt
    • Any holder of the public key can decrypt the message, but only a holder of the private key could have encrypted it
  • For speed and improved security, hash the plaintext and sign that, then encrypt
  • Algorithms: RSA, ElGamal, DSA
    • DSA is intended for digital signatures only
Key Distribution

  • Diffie-Hellman key exchange
    • Client and server agree on shared secret without transmitting it over the network
    • Use digital signatures to authenticate messages
  • Public key encryption key exchange
    • Client generates symmetric session keys, sends to server encrypted with server's public key
  • Still need to verify that the public key belongs to the other host
Digital Certificates

  • Trusted third party digitally signs public key
    • Certificate Authority (CA) has a public key that is known by everyone involved
  • The resulting digital certificate contains
    • Server's public key and expiration date
    • Information about the owner of the key
    • Information about the CA and the CA's signature
    • Information on how the certificate may be used

TLS/SSL Handshake

Generating a RSA Private Key

  • Generates private key file, includes information needed to compute public key
    • make *.key in /etc/pki/tls/certs
    • openssl genrsa command
  • Can encrypt the key for theft protection
    • Service will prompt for password when started
    • Attacker may be able to recover the password from main memory in any case
Generating a Certificate Signing request (CSR)

  • CA creates the final certificate from the Certificate Signing Request
    • Does not contain the private key!
    • CA must verify the identity of the CSR owner before signing
  • Need a key pair for the CSR
    • make *.csr creates key if necessary
    • openssl req command
Creating a CA-signed Certificate

  • $ openssl ca -in my.csr -out my.crt
    • Verify information, then approve
  • Every certificate issued should have a unique serial number (stored in index.txt)
  • Keep a copy of the final CRT file so the certificate can be revoked if necessary
Certificate Expiration

  • Expiration is a safety measure to help reduce the risk of a private key compromise
    • Short expiration periods are inconvenient, but speed recovery if the key is compromised
  • CA certificates typically have a long lifetime
  • Individual certificates have shorter lifetime
  • Be sure to deploy new certificates well before the old ones expire!
Certificate Revocation

  • Revocation of a compromised key is hard
  • One solution is a certificate revocation list (CRL)
    • Requires periodic downloads of the latest CRL
    • Many users or clients do not bother!
  • Some key distribution systems use very short expiration times and simply allow certificates to expire naturally
Managing a CRL

  • To revoke a certificate:
    • $ openssl ca -revoke 01.crt
  • To build an up to date CRL from index.txt:
    • $ openssl ca -gencrl -out my.crl
  • Some programs can automatically download and import the latest CRL from a web URL
    • Mozilla, expects the CRL in DER format
Operational Issues

  • Programs and users fail to check identities
  • Programs and users fail to use CRLs
  • A third-party CA can issue bogus certificates
    • If standard CA is not to be trusted, may need to be disabled manually
  • A private CA must make sure all clients have its CA certificate installed
GnuPG

  • GnuPG is a powerful encryption tool
  • To generate a key: gpg --gen-key
  • Exchange public keys with others to encrypt email and verify signatures
End of Unit 3

  • Questions and Answers
  • Summary
    • Network communication vulnerabilities
    • Introduction to cryptography
    • Working with digital certificates for TLS/SSL
    • Operational issues with TLS

你可能感兴趣的:(linux,red,hat,rhca,RHS333,linux认证)