Presentation is loading. Please wait.

Presentation is loading. Please wait.

ITEC559 Secure Internet Protocols

Similar presentations

Presentation on theme: "ITEC559 Secure Internet Protocols"— Presentation transcript:

1 ITEC559 Secure Internet Protocols
Lecture 11 POSTECH Prof. Jong Kim © 2003

2 Lecture Topics Week3 : Secure Email Mon : E-mail, SMTP Security
Wed : PEM, S/MIME Fri : PGP, openPGP


4 PGP PGP=“Pretty Good Privacy” Widely used de facto secure email
First released in 1991, developed by Phil Zimmerman, provoked export control and patent infringement controversy. Selected best available crypto algs to use; Integrated into a single program;

5 Pretty Good Privacy (PGP)
Available on Unix, PC, Macintosh and Amiga systems ; Originally free, now have commercial versions available also. Freeware: OpenPGP and variants: Commercial: formerly Network Associates International, now PGP Corporation at OpenPGP specified in RFC 2440 and defined by IETF OpenPGP working group. Available as plug-in for popular clients, can also be used as stand-alone software.

6 PGP Functionality similar to S/MIME:
encryption for confidentiality. signature for non-repudiation/authenticity. One level of processing only, so less flexible than S/MIME. Sign before encrypt, so signatures on unencrypted data - can be detached and stored separately. PGP-processed data is base64 encoded and carried inside RFC822 message body.

7 PGP Algorithms Broad range of algorithms supported:
Symmetric encryption: DES, 3DES, AES and others. Public key encryption of session keys: RSA or ElGamal. Hashing: SHA-1, MD-5 and others. Signature: RSA, DSS, ECDSA and others.

8 PGP Operation – Authentication
Sender creates a message; SHA-1 used to generate 160-bit hash code of message; Hash code is encrypted with RSA using the sender's private key, and result is attached to message; Receiver uses RSA or DSS with sender's public key to decrypt and recover hash code; Receiver generates new hash code for message and compares with decrypted hash code, if match, message is accepted as authentic.

9 PGP Operation – Confidentiality
Sender generates message and random 128-bit number to be used as session key for this message only; Message is encrypted, using CAST-128 / IDEA/3DES with session key; Session key is encrypted using RSA with recipient's public key, then attached to message; Receiver uses RSA with its private key to decrypt and recover session key; Session key is used to decrypt message.

10 PGP Operation – Confidentiality
(Stallings Fig 15.1b)

11 PGP Operation – Confidentiality & Authentication
Uses both services on same message: Create signature & attach to message, Encrypt both message & signature, Attach RSA (or ElGamel) encrypted session key. (Stallings Fig 15.1c)

12 PGP Operation – Compression
By default PGP compresses message after signing but before encrypting: So can store uncompressed message & signature for later verification, & because compression is non deterministic; Uses ZIP compression algorithm.

13 PGP Operation – Email Compatibility
When using PGP will have binary data to send (encrypted message etc); However was designed only for text; Hence PGP must encode raw binary data into printable ASCII characters; Uses radix-64 algorithm: Maps 3 bytes to 4 printable chars, Also appends a CRC; PGP also segments messages if too big.

14 PGP Operation – Summary
Stallings Fig 15-2. (Stallings Fig 15.2)

15 Format of PGP Message (Stallings Fig 15.3)

16 PGP Session Keys Need a session key for each message:
of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit Triple-DES; Generated using ANSI X12.17 mode; Uses random inputs taken from previous uses and from keystroke timing of user; Random input is used to provide key and plaintext which is encrypted to provide session key.

17 PGP Public & Private Keys
Since many public/private keys may be in use, need to identify which is actually used to encrypt session key in a message; Could send full public-key with every message, but this is inefficient; Rather use a key identifier based on key: is least significant 64-bits of the key, will very likely be unique, Also use key ID in signatures.

18 PGP Key Rings PGP supports multiple public/private keys pairs per sender/recipient. Keys stored locally in a PGP Key Ring – essentially a database of keys. Each PGP user has a pair of keyrings: Public-key ring contains all the public-keys of other PGP users known to this user, indexed by key ID, Private-key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted using a key derived from a hashed passphrase.

19 PGP Key Rings (Stallings Fig 15.5)

20 PGP Key Management Rather than relying on certificate authorities in PGP every user is own CA: can sign keys for users they know directly; Forms a “web of trust”; Trust keys signed by someone you “trust”, Can trust keys others have signed if have a chain of signatures to them; Key ring includes trust indicators; Users can also revoke their keys.

21 PGP Key Management PGP adopts a completely different trust model – the web of trust. No centralised authority like a root of trust in X.509. Individuals sign one another’s public keys, these “certificates” are stored along with keys in key rings. PGP computes a trust level for each public key in key ring. Users interpret trust level for themselves.

22 PGP Trust Model Example
(Stallings Fig 15.7)

23 Key Management for PGP and S/MIME
PGP and S/MIME use public keys for encrypting session keys / verifying signatures. private keys for decrypting session keys / creating signatures. Where do these keys come from and on what basis can they be trusted?

24 PGP Trust Levels Trust levels for public keys dependent on:
number of signatures on the key; trust level accorded to each of those signatures. Trust levels recomputed from time to time. See Stallings pp for details.

25 PGP Key Mgmt Issues Original intention was that all users would contribute to web of trust. Reality is that this web is sparsely populated. How should security-unaware users assign and interpret trust levels? Later versions of PGP support X.509 certs. PGP fine for small groups and out-of-band public key distribution (eg floppy).

26 E-mail Security: Beyond PGP and S/MIME
PGP and S/MIME counter the basic threats to confidentiality, integrity and authenticity of quite well (assuming good key management). They don’t protect against other threats (virus, DoS, disclosure, unauthorized use,…) They don’t provide any protection against traffic analysis. Additional security measures are needed.

27 Anti-virus and Content Filtering
Supplement mail server (or client desktop?) with content filtering software Block s with active content or specific attachment types. Reject suspected spam . Scan incoming and outgoing for viruses and inappropriate content. Add legal disclaimers. Server cannot apply content filter to encrypted ! Significant load on mail server, may annoy end users (but whose is it anyway?)

28 Anti-spamming Protection
Configure mail server to disallow mail relay feature. Prevents server being used as an agent to forward for third parties. Discard all from servers on Open Relay Blacklist (ORB).

29 Firewalls and Mail Servers
Place mail server behind a firewall in network. Configure firewall to block all external traffic to/from MTA except on port 25 (SMTP). Configure firewall to block all internal traffic to/from MTA except on ports 25, 110 (POP3) and 143 (IMAP) and other ports as needed – eg SNMP management. Limits attack possibilities on mail server, but successful attack may give access to internal systems. Need additional security measures on server. Other (better) firewall/mail server/border router configurations possible – see Lecture 10.

30 Mail Server Hardening Take additional measures on mail server:
Harden OS: Remove unnecessary accounts, applications and network services. Apply latest OS vulnerability patches. Harden mail server application (eg sendmail, M’soft exchange): Use latest versions of software. Choose appropriate configuration settings (eg limit attachment sizes, mail relay features and file permissions). Specific guidelines in NIST Report Appendices E&F.

31 Mail Server Administration
Log server data and review log files regularly (consider automated analysis). Keep up-to-date with latest patches and vulnerability alerts. Use only console-based administration, or use SSH if remote admin really needed. Take appropriate backups of mail server and user mail. More guidelines in NIST Report Chapter 8.

32 Client Side E-mail Security
Again, proper configuration and patching are essential: Disable automatic message preview. Disable active content processing (ActiveX, Java, Javascript,…). Disable POP/IMAP “remember this password?” dialogue boxes if possible. Consider use of SSL to protect SMTP, POP and IMAP. Be aware of extra risks of web-based access: Key stroke logging and user credential capture. Content over http may bypass content filters.

33 E-mail Policy and Training
Develop and publicise an policy for users Rules of use, definitions of abuse of service, clarify ownership of . Ensure users sign-up to policy before use. Raise awareness of security issues in your organisation through training. Local policy at:

34 Summary E-mail is routed across internal LANs and the public Internet.
is subject to many threats. also enables many threats! PGP and S/MIME can address part of the problem through encryption and signature mechanisms. Addressing the remaining issues requires a careful blend of computer and network security countermeasures.

35 E-mail Resources NIST Special Publication 800-45:
Guidelines on Electronic Mail Security by S. Bisker, M. Tracy and W. Jansen. Available from: Stallings Chapter 5: more on PGP and S/MIME Open PGP: PGPv7 on ISG lab machines. S/MIME: All the RFCs are at as usual.

Download ppt "ITEC559 Secure Internet Protocols"

Similar presentations

Ads by Google