E-MAIL, IP & WEB SECURITY E-mail Security: Security Services for E-mail-attacks possible through E-mail – establishing keys privacy-authentication of the source-Message Integrity-Non-repudiation-Pretty Good Privacy-S/MIME. IPSecurity: Overview of IPSec – IP and IPv6-Authentication Header-Encapsulation Security Payload (ESP)-Internet Key Exchange (Phases of IKE, ISAKMP/IKE Encoding). Web Security:

1. CS6701 CRYPTOGRAPHY AND
NETWORK SECURITY
UNIT – V
Dr.A.Kathirvel, Professor, Dept of CSE
M N M Jain Engineering College, Chennai

2. UNIT - V
E-MAIL, IP & WEB SECURITY
E-mail Security: Security Services for E-mail-attacks possible
through E-mail – establishing keys privacy-authentication
of the source-Message Integrity-Non-repudiation-Pretty
Good Privacy-S/MIME. IPSecurity: Overview of IPSec – IP
and IPv6-Authentication Header-Encapsulation Security
Payload (ESP)-Internet Key Exchange (Phases of IKE,
ISAKMP/IKE Encoding). Web Security: SSL/TLS Basic
Protocol-computing the keys- client authentication-PKI as
deployed by SSLAttacks fixed in v3- Exportability-
Encoding-Secure Electronic Transaction (SET).
2

3. Email Security
• email is one of the most widely used and
regarded network services
Example
From : abc @gmail.com
To : cdf@yahoo.com
Sub: Hi
How are you?
3

4. Single mail to group of recipients
• Remote Exploder
mail mail
mail
• Local Exploder mail
Req list
reterive list
mail mail mail
Sender
Recipient 2
Recipient 1
Distribution
site
Recipient 3
Sender
Distribution list
maintenance
Recipient 3Recipient 1 Recipient 2 4

5. Email Security Services
1. Confidentiality- protection from
disclosure
2. Authentication of the source
3. message integrity -protection from
modification
4. non-repudiation of origin -protection
from denial by sender
5

6. Email Security Services
5. Proof of submission
6. Proof of delivery
7. Message flow confidentiality-intruder unable to
know whether msg sent/not between users
8. Anonymity- Hiding the sender details
9. Containment- ability to maintain n/w security
10.Audit
11.Self Destruct
12.Message Sequence
6

7. Possible attacks of Emails
1. Phishing attack- attempt to find info like
username, password either directly/indirectly
2. Malware Distribution
3. Spam attack- junk mail attack
4. Denial of Secure attack- attacker send bulk
mail either make overflow/crash
7

8. Pretty Good Privacy (PGP)
• widely used de facto secure email
• developed by Phil Zimmermann
• selected best available crypto algs to use
integrated into a single program
• available on Unix, PC, Macintosh and Amiga
systems
• originally free, now have commercial versions
available also
8

9. PGP Services
1 Authentication
2. Confidentiality
3. Compression
4.E-mail Compatibility
5.Segmentation & Reassembly
9

10. 10

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

12. PGP Operation – Confidentiality
1. sender generates message and random 128-bit
number to be used as session key for this message
only
2. message is encrypted, using CAST-128 / IDEA/3DES
with session key
3. session key is encrypted using RSA with recipient's
public key, then attached to message
4. receiver uses RSA with its private key to decrypt and
recover session key
5. session key is used to decrypt message
12

13. PGP Operation – Confidentiality &
Authentication
• uses both services on same message
–create signature & attach to message
–encrypt both message & signature
–attach RSA encrypted session key
13

14. PGP Operation – Compression
• by default PGP compresses message after
signing but before encrypting
– One can store uncompressed message & signature
for later verification
– & because compression is non deterministic
• uses ZIP compression algorithm
14

15. PGP Operation – Email Compatibility
• when using PGP will have binary data to send
(encrypted message etc)
• however email 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(ASCII)
– also appends a CRC
• PGP also segments messages if too big
15

16. PGP Operation
16

17. Segmentation & Reassembly
• PGP subdivides the
original message(if
length >50000
octects) which is too
large to small
enough to send via
mail.
• On the receiving
end, PGP
reassemble entire
original block
17

18. 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
18

19. 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
19

20. PGP Key Rings
• 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
keyed from a hashed passphrase
20

22. 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 have signed
– 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
22

23. S/MIME (Secure/Multipurpose Internet
Mail Extensions)
• security enhancement to MIME email
– original Internet RFC822 email was text only
– MIME provided support for varying content types
and multi-part messages
– with encoding of binary data to textual form
– S/MIME added security enhancements
• have S/MIME support in various modern mail
agents: MS Outlook, Netscape etc
23

24. S/MIME Functions
• enveloped data
–encrypted content and associated keys
• signed data
–encoded message + signed digest
• clear-signed data
–cleartext message + encoded signed digest
• signed & enveloped data
–nesting of signed & encrypted entities
24

25. S/MIME Cryptographic Algorithms
• hash functions: SHA-1 & MD5
• digital signatures: DSS & RSA
• session key encryption: ElGamal & RSA
• message encryption: Triple-DES, RC2/40 and
others
• have a procedure to decide which algorithms
to use
25

26. S/MIME Certificate Processing
• S/MIME uses X.509 v3 certificates
• managed using a hybrid of a strict X.509 CA
hierarchy & PGP’s web of trust
• each client has a list of trusted CA’s certs
• and own public/private key pairs & certs
• certificates must be signed by trusted CA’s
26

27. IP Security
• have a range of application specific security
mechanisms
– eg. S/MIME, PGP, Kerberos, SSL/HTTPS
• however there are security concerns that cut
across protocol layers
• would like security implemented by the
network for all applications
27

28. IP Security
• general IP Security mechanisms
• provides
– authentication
– confidentiality
– key management
• applicable to use over LANs, across public &
private WANs, & for the Internet
• need identified in 1994 report
– need authentication, encryption in IPv4 & IPv6
28

29. IPSec Document Overview
29

30. IP Security Uses
30

31. Benefits of IPSec
• in a firewall/router provides strong security to
all traffic crossing the perimeter
• in a firewall/router is resistant to bypass
• is below transport layer, hence transparent to
applications
• can be transparent to end users
• can provide security for individual users
• secures routing architecture
31

32. IP Security Specification
The IPSec specification has become quite complex. key management. The totality of the IPsec
specification is scattered across dozens of RFCs and draft IETF documents, making this the
most complex and difficult to grasp of all IETF specifications. The best way to keep track of
and get a handle on this body of work is to consult the latest version of the IPsec document
roadmap. The documents can be categorized into the following groups:
• Architecture: Covers the general concepts, security requirements, definitions, and
mechanisms defining IPsec technology, RFC 4301, Security Architecture for the Internet
Protocol.
• Authentication Header (AH): AH is an extension header for message authentication, now
deprecated.
• Encapsulating Security Payload (ESP): ESP consists of an encapsulating header and trailer used
to provide encryption or combined encryption/authentication. .
• Internet Key Exchange (IKE): a collection of documents describing the key management
schemes for use with IPsec
• Cryptographic algorithms: a large set of documents that define and describe cryptographic
algorithms for encryption, message authentication, pseudorandom functions (PRFs), and
cryptographic key exchange.
• Other: There are a variety of other IPsec-related RFCs, including those dealing with security
policy and management information base (MIB) content.
32

33. IPSec Services
• Access control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets
– a form of partial sequence integrity
• Confidentiality (encryption)
• Limited traffic flow confidentiality
33

34. Transport and Tunnel Modes
• Transport Mode
– to encrypt & optionally authenticate IP data
– can do traffic analysis but is efficient
– good for ESP host to host traffic
• Tunnel Mode
– encrypts entire IP packet
– add new header for next hop
– no routers on way can examine inner IP header
– good for VPNs, gateway to gateway security
34

35. Transport
and
Tunnel
Modes
35

36. Transport
and
Tunnel
Mode
Protocols

37. Security Associations
• a one-way relationship between sender &
receiver that affords security for traffic flow
• defined by 3 parameters:
– Security Parameters Index (SPI)
– IP Destination Address
– Security Protocol Identifier
• has a number of other parameters
– seq no, AH & EH info, lifetime etc
• have a database of Security Associations
37

38. Security Policy Database
• relates IP traffic to specific SAs
– match subset of IP traffic to relevant SA
– use selectors to filter outgoing traffic to map
– based on: local & remote IP addresses, next layer
protocol, name, local & remote ports
38

39. Transport Mode SA Tunnel Mode SA
AH Authenticates IP payload
and selected portions of IP
header and IPv6 extension
headers
Authenticates entire inner
IP packet plus selected
portions of outer IP header
ESP Encrypts IP payload and any
IPv6 extesion header
Encrypts inner IP packet
ESP with
authentication
Encrypts IP payload and any
IPv6 extesion header.
Authenticates IP payload
but no IP header
Encrypts inner IP packet.
Authenticates inner IP
packet.
39

40. Before
applying AH
Transport Mode
(AH Authentication)
40

41. Tunnel Mode (AH
Authentication)
Encapsulating Security Payload (ESP)
• provides message content confidentiality, data origin
authentication, connectionless integrity, an anti-replay
service, limited traffic flow confidentiality
• services depend on options selected when establish
Security Association (SA), net location
• can use a variety of encryption & authentication algorithms
41

42. Encapsulating Security Payload
42

43. Encryption & Authentication
Algorithms & Padding
• ESP can encrypt payload data, padding, pad
length, and next header fields
– if needed have IV at start of payload data
• ESP can have optional ICV for integrity
– is computed after encryption is performed
• ESP uses padding
– to expand plaintext to required length
– to align pad length and next header fields
– to provide partial traffic flow confidentiality
43

44. Anti-Replay Service
• replay is when attacker resends a copy of an
authenticated packet
• use sequence number to thwart this attack
• sender initializes sequence number to 0 when a
new SA is established
– increment for each packet
– must not exceed limit of 232 – 1
• receiver then accepts packets with seq no within
window of (N –W+1)
44

45. Combining Security Associations
• SA’s can implement either AH or ESP
• to implement both need to combine SA’s
– form a security association bundle
– may terminate at different or same endpoints
– combined by
• transport adjacency
• iterated tunneling
• combining authentication & encryption
– ESP with authentication, bundled inner ESP & outer
AH, bundled inner transport & outer ESP
45

46. Combining Security Associations
46

47. IPSec Key Management
• handles key generation & distribution
• typically need 2 pairs of keys
– 2 per direction for AH & ESP
• manual key management
– Sys-admin manually configures every system
• automated key management
– automated system for on demand creation of keys
for SA’s in large systems
– has Oakley & ISAKMP elements
47

48. Oakley
• a key exchange protocol
• based on Diffie-Hellman key exchange
• adds features to address weaknesses
– no info on parties, man-in-middle attack, cost
– so adds cookies, groups (global params), nonces,
DH key exchange with authentication
• can use arithmetic in prime fields or elliptic
curve fields
48

49. ISAKMP
• Internet Security Association and Key
Management Protocol
• provides framework for key management
• defines procedures and packet formats to
establish, negotiate, modify, & delete SAs
• independent of key exchange protocol,
encryption alg, & authentication method
• IKEv2 no longer uses Oakley & ISAKMP terms,
but basic functionality is same
49

50. IKEV2 Exchanges
50

51. • The IKEv2 protocol involves the exchange of messages in pairs.
• The first two pairs of exchanges are referred to as the initial exchanges).
In the first exchange the two peers exchange information concerning
cryptographic algorithms and other security parameters they are willing
to use along with nonces and Diffie-Hellman (DH) values. The result of
this exchange is to set up a special SA called the IKE SA
• This SA defines parameters for a secure channel between the peers over
which subsequent message exchanges take place. Thus, all subsequent
IKE message exchanges are protected by encryption and message
authentication. In the second exchange, the two parties authenticate
one another and set up a first IPsec SA to be placed in the SADB and
used for protecting ordinary (i.e. non-IKE) communications between the
peers.
• Thus four messages are needed to establish the first SA for general use.
The CREATE_CHILD_SA exchange can be used to establish further SAs
for protecting traffic. The informational exchange is used to exchange
management information, IKEv2 error messages, and other
notifications.

52. ISAKMP
52

53. • An ISAKMP message consists of an ISAKMP header followed by one or more payloads,
carried in a transport protocol (UDP by default).
• Figure1 shows the header format for an ISAKMP message, which includes the fields:
• Initiator SPI (64 bits): chosen by the initiator to identify a unique SA
• Responder Cookie (64 bits): chosen by responder to identify unique IKE SA
• Next Payload (8 bits): type of the first payload in the message.
• Major/Minor Version (4 bits): Indicates major/minor version of IKE in use
• Exchange Type (8 bits): type of exchange.
• Flags (8 bits): specific options set for this IKE exchange.
• Message ID (32 bits): control retransmission, matching of requests /responses.
• Length (32 bits): of total message (header plus all payloads) in octets.
All ISAKMP payloads begin with the same generic payload header shown in Figure 2. The
Next Payload field has a value of 0 if this is the last payload in the message; otherwise
its value is the type of the next payload. The Payload Length field indicates the length in
octets of this payload, including the generic payload header. The critical bit is zero if the
sender wants the recipient to skip this payload if it does not understand the payload
type code in the Next Payload field of the previous payload. It is set to one if the sender
wants the recipient to reject this entire message if it does not understand the payload
type.

54. IKE Payloads & Exchanges
• have a number of ISAKMP payload types:
– Security Association, Key Exchange, Identification,
Certificate, Certificate Request, Authentication,
Nonce, Notify, Delete, Vendor ID, Traffic Selector,
Encrypted, Configuration, Extensible
Authentication Protocol
• payload has complex hierarchical structure
• may contain multiple proposals, with multiple
protocols & multiple transforms
54

55. Web Security
• Web now widely used by business,
government, individuals
• but Internet & Web are vulnerable
• have a variety of threats
– integrity
– confidentiality
– denial of service
– authentication
• need added security mechanisms
55

56. Web Traffic Security Approaches
56

57. SSL (Secure Socket Layer)
• transport layer security service
• originally developed by Netscape
• version 3 designed with public input
• subsequently became Internet standard
known as TLS (Transport Layer Security)
• uses TCP to provide a reliable end-to-end
service
• SSL has two layers of protocols
57

58. SSL Architecture
• SSL connection
– a transient, peer-to-peer,
communications link
– associated with 1 SSL
session
• SSL session
– an association between
client & server
– created by the Handshake
Protocol
– define a set of
cryptographic parameters
– may be shared by multiple
SSL connections
58

59. SSL Record Protocol Services
• confidentiality
– using symmetric encryption with a
shared secret key defined by
Handshake Protocol
– AES, IDEA, RC2-40, DES-40, DES,
3DES, Fortezza, RC4-40, RC4-128
– message is compressed before
encryption
• message integrity + authentication
– using a MAC with shared secret key
– similar to HMAC but with different
padding
59

60. SSL Change Cipher Spec Protocol
• one of 3 SSL specific protocols which use the SSL
Record protocol
• a single message
• causes pending state to become current
• hence updating the cipher suite in use
60

61. SSL Alert Protocol
• conveys SSL-related alerts to peer entity
• severity
• warning or fatal
• specific alert
• fatal: unexpected message, bad record mac,
decompression failure, handshake failure, illegal
parameter
• warning: close notify, no certificate, bad certificate,
unsupported certificate, certificate revoked, certificate
expired, certificate unknown
• compressed & encrypted like all SSL data
61

62. SSL Handshake Protocol
• allows server & client to:
– authenticate each other
– to negotiate encryption & MAC algorithms
– to negotiate cryptographic keys to be used
• comprises a series of messages in phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
62

63. SSL Handshake
Protocol

64. Cryptographic Computations
• master secret creation
– a one-time 48-byte value
– generated using secure key exchange (RSA / Diffie-
Hellman) and then hashing info
• generation of cryptographic parameters
– client write MAC secret, a server write MAC
secret, a client write key, a server write key, a
client write IV, and a server write IV
– generated by hashing master secret
64

65. TLS (Transport Layer Security)
• IETF standard RFC 2246 similar to SSLv3
• with minor differences
– in record format version number
– uses HMAC for MAC
– a pseudo-random function expands secrets
• based on HMAC using SHA-1 or MD5
– has additional alert codes
– some changes in supported ciphers
– changes in certificate types & negotiations
– changes in crypto computations & padding
65

66. TLS

67. HTTPS
• HTTPS (HTTP over SSL)
– combination of HTTP & SSL/TLS to secure
communications between browser & server
• documented in RFC2818
• no fundamental change using either SSL or TLS
• use https:// URL rather than http://
– and port 443 rather than 80
• encrypts
– URL, document contents, form data, cookies,
HTTP headers
67

68. HTTPS Use
• connection initiation
– TLS handshake then HTTP request(s)
• connection closure
– have “Connection: close” in HTTP record
– TLS level exchange close_notify alerts
– can then close TCP connection
– must handle TCP close before alert exchange sent
or completed
68

69. Secure Shell (SSH)
• protocol for secure network communications
– designed to be simple & inexpensive
• SSH1 provided secure remote logon facility
– replace TELNET & other insecure schemes
– also has more general client/server capability
• SSH2 fixes a number of security flaws
• documented in RFCs 4250 through 4254
• SSH clients & servers are widely available
• method of choice for remote login/ X tunnels
69

70. SSH Protocol Stack
70

71. SSH Transport Layer Protocol
• server authentication occurs at transport layer,
based on server/host key pair(s)
– server authentication requires clients to know host
keys in advance
• packet exchange
– establish TCP connection
– can then exchange data
• identification string exchange, algorithm negotiation, key
exchange, end of key exchange, service request
– using specified packet format
71

72. SSH User Authentication Protocol
• authenticates client to server
• three message types:
– SSH_MSG_USERAUTH_REQUEST
– SSH_MSG_USERAUTH_FAILURE
– SSH_MSG_USERAUTH_SUCCESS
• authentication methods used
– public-key, password, host-based
72

73. SSH Connection Protocol
• runs on SSH Transport Layer Protocol
• assumes secure authentication connection
• used for multiple logical channels
– SSH communications use separate channels
– either side can open with unique id number
– flow controlled
– have three stages:
• opening a channel, data transfer, closing a channel
– four types:
• session, x11, forwarded-tcpip, direct-tcpip.
73

74. SSH
Connection
Protocol
Exchange
74

75. Port Forwarding
• convert insecure TCP connection into a secure
SSH connection
– SSH Transport Layer Protocol establishes a TCP
connection between SSH client & server
– client traffic redirected to local SSH, travels via
tunnel, then remote SSH delivers to server
• supports two types of port forwarding
– local forwarding – hijacks selected traffic
– remote forwarding – client acts for server
75

76. Secure Electronic Transactions (SET)
• Protocol- to protect Internet credit card
transactions
• developed in 1996 by Mastercard, Visa etc
• not a payment system
• rather a set of security protocols & formats
– secure communications amongst parties
– trust from use of X.509v3 certificates
– privacy by restricted info to those who need it
76

77. SET Components
77

78. SET Transaction
1. customer opens account
2. customer receives a certificate
3. merchants have their own certificates
4. customer places an order
5. merchant is verified
6. order and payment are sent
7. merchant requests payment authorization
8. merchant confirms order
9. merchant provides goods or service
10.merchant requests payment
78

79. Dual Signature
• customer creates dual messages
–order information (OI) for merchant
–payment information (PI) for bank
• neither party needs details of other
• but must know they are linked
• use a dual signature for this
–Signed(by encryption) and concatenated
hashes of OI & PI
79

80. Purchase Request – Customer
80

81. Purchase Request – Merchant
81

82. Purchase Request – Merchant
1. verifies cardholder certificates using CA signs
2. verifies dual signature using customer's public
signature key to ensure order has not been
tampered with in transit & that it was signed
using cardholder's private signature key
3. processes order and forwards the payment
information to the payment gateway for
authorization (described later)
4. sends a purchase response to cardholder
82

83. Payment Gateway Authorization
1. verifies all certificates
2. decrypts digital envelope of authorization block to obtain
symmetric key & then decrypts authorization block
3. verifies merchant's signature on authorization block
4. decrypts digital envelope of payment block to obtain
symmetric key & then decrypts payment block
5. verifies dual signature on payment block
6. verifies that transaction ID received from merchant matches
that in PI received (indirectly) from customer
7. requests & receives an authorization from issuer
8. sends authorization response back to merchant
83

84. Payment Capture
• merchant sends payment gateway a
payment capture request
• gateway checks request
• then causes funds to be transferred
to merchants account
• notifies merchant using capture
response
84