Enhancing Network Security Architecture: Encryption Insights

1. Chapter 10 Electronic Mail Security

2. Session 8 – Contents • What encryption won’t do • Pretty Good Privacy • S/MIME

3. What encryption won’t do • Prevent users from leaving an unencrypted version of a sensitive file on their hard disk. • Prevent unencrypted data from leaking into the swap/paging file. • Keep users from selecting a poor encrypting key. • Prevent keystroke-capturing software or hardware from stealing your encryption key and passing to someone else. • Prevent from someone nearby from using commercially available Van Eck radiation interceptor systems to capture users’ data.

4. What encryption won’t do • Hide the email connectivity of who is sending the encrypted file and to whom. • Hide the alerting fact that the file is encrypted. • Negate a hidden overhead camera aimed at users’ keyboard or screen. • Prevent the intended recipient of the encrypted file from publishing. • Protect users from compromising users encryption and decryption keys. From: M. Caloyannides, “Keeping Offline Computer Usage Private.” IEEE Security & Privacy. September/October 2003

5. Security Architecture • Network Security • Secures the ingress and egress points of the network and authenticates users and data. • Provides the first layer of infrastructure defense through traffic management and inspection devices, such as Ethernet switches, and routers with advanced functionality that can perform packet inspection. • Network-assisted Security functions • Enable security services to be customized to perform more thorough packet inspection of data traffic to detect security threats. Virtual private networks (VPNs) and devices that provide encryption, for example, serve this function. • Application Layer Security • Provides security to remote users and for traveling employees who must access data outside of the network perimeter. SSL Accelerators and Web switches provide content filtering. • Secure Access Management • Provides authentication for users with preset profiles. Access management may be employed to assign user specific network privileges and may segregate those privileges by user and by resource. • Security Policy Management • Ensures that the business objectives of the enterprise take precedence in the design of their communications infrastructure. • Network Management • Provides security policy management, as well as secure access and network management security. • Encompasses control of the network and must be securely integrated to ensure that network administrators are the only ones able to effect network configurations.

6. TCP/IP Stack and Security Related Protocols • IPSec (ISAKMP) • S-HTTP • SET • S/MIME • PGP SMTP, Telnet, FTP, Gopher Application Layer • SOCKS V5 • SSL, TLS Transport Layer TCP UDP • IPSec (AH, ESP) • Packet Filtering • Tunneling Protocols Network Layer IP ARP RARP Ethernet, Token-Ring, FDDI, X.25, Wireless, Async, ATM, SNA...Data Layer • PPP-EAP, IEEE 802.1X, CHAP, PAP, MS-CHAP Data Layer

7. Pretty Good Privacy • Designed by Philip R. Zimmerman. • PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. • There are no Key Certificate Authorities. All users generate and distribute their own public key. • Users can sign one another’s public key. Someone who signs another’s public key becomes an introducer for that person. • When a user receives a new public key and trusts one of the introducers, then he has reason to believe that the public key is valid.

8. Why Is PGP Popular? • Available free on a variety of platforms. • Based on well known algorithms. • Has wide range of applicability • Not developed or controlled by governmental or standards organizations

9. Operational Description • Consists of five services: • Authentication • Confidentiality • Compression • E-mail Compatibility • Segmentation

10. Message Encryption Key Message Encryption Key Encipher Cast-128, IDEA or 3DES Compression ZIP Hash SHA-1 Encipher DSA / RSA Decipher DSA / RSA Decipher Cast-128, IDEA or 3DES Decompress ZIP Hash SHA-1 Verification PGP Authentication and Confidentiality Encipher RSA or ElGamal Recipient’s Public Key RADIX 64 Cleartext Message Digital Envelope Message Compressed Signed Cipher Message Digital Signature Sender’s Private Key Digital Envelope Sender Hash Decipher RSA or ElGamal Recipient’s Private Key DigitalSignature Digital Signature Sender’s Public Key Compressed Signed Cipher Message Deciphered Message Hash Hash Recipient Yes/No

11. 6-bit Blocks 001000 110101 1110010 010001 8 53 50 17 y I 1 R 01001001 00110001 01111001 01010010 8-bit ASCII Format 6-bit Value Character Encoding 6-bit Value Character Encoding 6-bit Value Character Encoding 6-bit Value Character Encoding 0 A 16 Q 32 g 48 w 1 B 17 R 33 H 49 x 2 C 18 S 34 I 50 y 8 I 24 Y 40 O 53 1 9 J 25 15 P 31 47 63 (Pad) = E-mail Compatibility • The scheme used is Radix-64 (base64) Encoding. • The use of Radix-64 expands the message by 33%. Radix-64 Conversion Only the characters in the Character Encoding Table will appear in the encrypted email.

12. Segmentation and Reassembly • Email is often restricted to a maximum message length of 50,000 octets. • Longer messages must be broken up into segments. • PGP automatically subdivides a message that is too large. • The receiver strips of all e-mail headers and reassembles the message.

13. Function Algorithm Used Description Digital Signature DSA/SHA or RSA/SHA The message is hashed using SHA-1 and signed with DSA or RSA using sender’s private key, creating a digital signature. Compression ZIP The cleartext message is concatenated with the digital signature and the result is compressed using a compression package called ZIP. Message Encryption Algorithm (Symmetric Encryption) CAST, IDEA, 3DES (CFB mode), Blowfish, or AES. The ZIP compressed cleartext message and digital signatures are enciphered with a symmetric algorithms (Cast-128, IDEA, or 3DES) using the one-time secret key generated by the sender. Key Encryption Algorithm RSA or ElGamal The one-time message encrypting key is enciphered with RSA or ElGamal using the recipient’s public key. E-mail Compatibility Radix-64 conversion The enciphered message concatenated with the enciphered one-time message encryption key is converted to 8-bit printable ASCII characters using an encoding technique called RADIX-64 for compatibility with emails applications. Segmentation To accommodate maximum message size limitations, PGP performs segmentation and reassembly. Summary of PGP Services

14. + + + + + + Cipher Feedback (CFB) Mode InitializationVector Input Block 1 CIPHK Output Block 1 Select Discard s Bits (b–s) bits Input Block 2 (b-s) Bits s Bits CIPHK Output Block 2 Select Discard S Bits (b–s ) bits Input Block n (b-s) Bits s Bits CIPHK Output Block n Select Discard s Bits (b–s) bits Encrypt Plaintext 1 Plaintext 2 Plaintext n Ciphertext 1 Ciphertext 2 Ciphertext n InitializationVector Input Block n (b-s) Bits s Bits CIPHK Output Block 2 Select Discard s Bits (b–s) bits Input Block 1 CIPHK Output Block 1 Select Discard s Bits (b–s) bits Input Block 2 (b-s) Bits s Bits CIPHK Output Block 2 Select Discard s Bits (b–s) bits Decrypt Ciphertext 1 Ciphertext 2 Ciphertext n Plaintext 1 Plaintext 2 Plaintext n

15. PGP Random Number Generation • True Random Numbers • Based on the content and timing of user keystrokes. • Used to generate RSA key pairs (public key and private key). • Provide initial seed for the pseudorandom number generator. • Contribute additional input during pseudorandom number generation. • Pseudorandom numbers • Used to generate message encryption keys. Message encryption keys are used only to encipher and decipher one message (one-time key). • Used to generate initialization vectors (IVs) for use with the message encryption key in the CFB mode encryption.

16. PGP Key IDs and Key Rings • Sender and Recipient may have multiple public/private key sets. • Sender needs to indicate which of his public keys and which of the recipient private keys were used. • PGP assigns a key ID to each public/private key. It consists of the least significant 64 bits of the sender’s or recipient’s public key. • Each node stores the information in two tables: • The Public Key Ring stores the public key of other users known to the node. • The Private Key Ring stores the public and private keys owned by the node. The private key is encrypted before being stored. A 160-bit hash code is generated from a pass phrase, which is used to encipher the private key using CAST-128, IDEA, or 3DES.

17. Hash SHA-1 Message Encryption Key Decipher CAST-128, IDEA, 3DES Random Number Generator Hash SHA-1 Encipher DSA / RSA Encipher Cast-128, IDEA or 3DES Compression ZIP PGP Public and Private Keyrings Sender Password Private-Key Ring Public-Key Ring Select IDA Select IDB Encrypted Private Key Sender’s Private Key Recipient’s Public Key DigitalSignature Encipher RSA or ElGamal Key ID RADIX 64 Enciphered Digital Signature Digital Envelope Compressed Signed Cipher Message Key ID Message Clear Message

18. Hash SHA-1 Encipher CAST-128, IDEA, 3DES Public Key Private Key Adding PGP Public Keys to a Key Ring 3. Upload public key into server Alice’s Public-Key Ring Create IDA 1. Generate keys PGP Key Server 4. Download public key from server Alice’s Private-Key Ring PGP Key Search 5. Import to local key ring. 2. Enter Password 6. Sign the key with Bob’s private key Password Bob’s Public-Key Ring 7. Assign trust level: Complete, Marginal, No Trust.

19. PGP Keys

20. Signing a PGP Key

21. PGP Key & Options

22. PGP Centric Models • In any digital certificate model, the digital signature needs to be signed and certified, by someone the user trusts. • In a centralized PGP environment, users get certified by a specific Certificate Authority (CA) whom everyone trusts. • In a decentralized environment PGP uses the user-centric trust model in which any user can act as a certifying authority and validate another PGP user’s public key certificate. • In the user-centric model, each user is directly responsible for deciding which certificates to accept and which ones to reject. Root CA Bob Alice Jason Sandra Rick’s Friend Root CA Rick

23. PGP Trust Levels • Do you trust the validity of the public key? This level of trust is computed by PGP, and it is called key legitimacy field. • Complete: The user is confident that the public key is valid. • Marginal: The user do not completely trust the CA who issued the certificate. • Untrusted: The user cannot say whether the public key is valid or not. • Do you trust the signer to certify public keys? This level of trust is calculated by PGP and is called signature trust field. • Do you trust the owner of this public key to sign other public-key certificates? This level of trust is assigned by the user, and it is called owner trust field. • Full: The owner of this public key is fully trusted to introduce another public key. • Marginal: The owner of this public key can be trusted to introduce another public key, but, it is uncertain whether the owner is fully competent to do so. • Untrustworthy: The owner of this public-key should not be trusted to introduce another, therefore any occurrence of this key as a signature on another public-key should be ignored. • Don't know: There are no expressions of trust made about the owner of this public key.

24. S/MIME • The S/MIME specification consists of two documents: • S/MIME Message Specification V3 (RFC 3851). Describes a protocol for adding cryptographic signature and encryption services to MIME data. • S/MIME Certificate Handling V3 (RFC 3850). Describes the mechanisms S/MIME uses to create and validate keys using certificates. In order to validate the keys of a message sent to it, an S/MIME agent needs to certify that the key is valid. • Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. • S/MIME agents MUST use PKIX certificates to validate public keys as described in RFC 4325 “Internet X.509 Public Key Infrastructure (PKIX) Certificate and Certificate Revocation List (CRL) Profile.” • S/MIME agents MUST meet the certificate processing requirements documented in RFC 3850, S/MIME Version 3 Certificate Handling, in addition to those stated in RFC 4325.

25. S/MIME • S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a method to send and receive secure MIME messages. • S/MIME provides the following cryptographic security services for electronic messaging applications: • Authentication • Message integrity and non-repudiation of origin (using digital signatures) • Privacy and data security (using encryption). • S/MIME uses symmetric encryption to encipher the message and public-key algorithm for key exchange (digital envelope). A public-key algorithm is also used for digital signatures. • Symmetric encryption algorithms: DES, 3DES, AES and RC2. • Key Generation: Diffie-Hellman, DSS, and RSA key-pairs. • Registration: Public keys must be registered with X.509 CA. • Certificate Storage: Local (as in browser application) for different services. • Signed and Enveloped Data: Various orderings for encrypting and signing. • S/MIME uses Public-Key Certificates - X.509 version 3 signed by Certification Authority.

26. S/MIME V 3.1 Supported Algorithms

27. S/MIME Content Types • Multipart/Signing Data: The message is signed to provide authentication, but it is not encrypted and it is not encoded with Radix 64. • Signed Data: The message digest is signed to provide integrity, it is encoded with Radix 64, but it is not encrypted. • Enveloped Data: The message is encrypted to provide confidentiality, but it is not signed. • Signed and Enveloped Data: The message is either encrypted first and then signed, or signed first and then encrypted.

28. SMIME Multipart/Signing Outer MIME Format • SignerInfo • Signer’s public- key certificate • Identifier of the hash algorithm • Identifier of the algorithm used to encipher hash message MIME Header Hash SHA or MD5 Encoded into base64(Radix 64) CMS MIME Body Sender’s Private Key Encipher RSA Enciphered Message Digest (Digital Signature) Clear Content Cryptographic Message Syntax (CMS) consists of the concatenated form of SignerInfo and the digital signature. Message can be viewed by recipients without S/MIME capability

29. SMIME Signed Data Outer MIME Format • SignerInfo • Signer’s public- key certificate • Identifier of the hash algorithm • Identifier of the algorithm used to encipher hash message MIME Header Hash SHA or MD5 Encoded into base64(Radix 64) MIME Body Sender’s Private Key Encipher RSA Enciphered Message Digest (Digital Signature) Clear Content Message can only be viewed by a recipient with S/MIME capability

30. SMIME Enveloped Data Random Number Generator Recipient’s Public Key Message Encryption Key Encipher RSA Outer MIME Format MIME Header Encipher RC2/40 3DES, or AES • RecipientInfo • Identifier of the recipient’s public- key certificate (X.509). • Identifier of the enciphering algorithm used. • Encrypted message encryption key MIME Body Encoded into base64(Radix 64) Encrypted Content Data integrity (encryption) without signing the message

31. S/MIME Certificate Processing • Hybrid between the strict X.509 certification hierarchy and PGP’s web of trust. • Users should maintain the certificates needed to verify incoming signatures and to encrypt outgoing messages. • Certificates are signed by Certification Authorities. • Certificate Authorities • VeriSign https://digitalid.verisign.com/cgi-bin/OEenroll.exe?name=&email= • GlobalSign http://www.globalsign.net/digital_certificate/ • British Telecom http://www.btignite.com/uk/products/trustservices/ • Thawte Certification http://www.thawte.com/html/COMMUNITY/personal/index.html • VeriSign Levels of Security for Public-key Certificates • Class-1: Buyer’s email address is confirmed by emailing vital info. • Class-2: Postal address is confirmed as well, and data checked against directories. • Class-3: Buyer must appear in person, or send notarized documents.

32. RFC 2311 S/MIME Version 2 Message Specification http://www.ietf.org/rfc/rfc2311.txt RFC 2312 S/MIME Version 2 Certificate Handling http://www.ietf.org/rfc/rfc2312.txt RFC 3852 Cryptographic Message Syntax http://www.ietf.org/rfc/rfc3852.txt?number=3852 RFC 2631 Diffie-Hellman Key agreement Method http://www.ietf.org/rfc/rfc2631.txt?number=2631 RFC 3850 S/MIME Version 3.1 Certificate Handling http://www.ietf.org/rfc/rfc3850.txt?number=3850 RFC 3851 S/MIME Version 3.1 Message Specification http://www.ietf.org/rfc/rfc3851.txt?number=3851 RFC 5035 Enhanced Security Services for S/MIME http://www.ietf.org/rfc/rfc2634.txt?number=2634 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS http://www.ietf.org/rfc/rfc2984.txt?number=2984 RFC 4134 Examples of S/MIME Messages http://www.ietf.org/rfc/rfc4134.txt?number=4134 RFC 5008 Suite B in S/MIME http://www.ietf.org/rfc/rfc5008.txt?number=5008 S/MIME RFCs

33. To Probe Further • Atkins D., Stallings W., Zimmermann P. (1996). PGP Message Exchange Formats. RFC 1991. IETF. http://www.ietf.org/rfc/rfc1991.txt?number=1991 • Housley, R. (1999). Cryptographic Message Syntax, RFC 2630. • PGP 7.0 Windows 95/98/NT/2000 User's Guide. http://www.pgpi.org/doc/guide/7.0/en/win/ • Oppliger, R. (2001). Secure Messaging with PGP and S/MIME. Norwood, Massachusetts: Artech House, Inc. • Stallings, W. (2003) Network Security Essentials, Applications and Standards. Upper Saddle River, New Jersey: Prentice Hall. • Zimmermann, P. (2000). An introduction to Cryptography. http://www.pgpi.org/doc/guide/6.5/en/intro/ • S/MIME Information at RSA http://www.rsasecurity.com/standards/smime/faq.html • S/MIME Working Group Status http://www.ietf.org/proceedings/02jul/slides/smime-4/ • http://www.dartmouth.edu/~pkilab/pages/Using_SMIME_e-mail.html • The S/MIME specifications can be found linked off the IETF S/MIME workgroup page at: http://www.ietf.org/html.charters/smime-charter.html