12/26/24

12/26/24

 Email is one of the most widely used

and regarded network services
 Currently message contents are not

secure
 May be inspected either in transit
 Or by suitably privileged users on

destination system

3
 12/26/24

 Confidentiality
 Protection from disclosure
 Authentication
 of sender of message
 Message integrity
 Protection from modification
 Non-repudiation of origin
 Protection from denial by sender

4
 12/26/24

 Widely used de facto secure email

 Developed by Phil Zimmermann
 Selected best available crypto algs to
use
 Integrated into a single program
 On Unix, PC, Macintosh and other
systems
 Originally free, now also have
commercial versions available
5
 12/26/24

1. Sender creates message

2. Make SHA-1 160-bit hash of message
3. Attached RSA signed hash to message
4. Receiver decrypts & recovers hash code
5. Receiver verifies received message hash

6
 12/26/24

1. Sender forms 128-bit random session key

2. Encrypts message with session key
3. Attaches session key encrypted with RSA
4. Receiver decrypts & recovers session key
5. Session key is used to decrypt message

7
 12/26/24

 Can use both services on same

message
 Create signature & attach to message
 Encrypt both message & signature
 Attach RSA/ElGamal encrypted session key

8
 12/26/24

 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
 (Appendix G)

9
 12/26/24

 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
 Also appends a CRC
 PGP also segments messages if too big

10
12/26/24

11
 12/26/24

 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

12
 12/26/24

 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
 Least significant 64-bits of the key
 Will very likely be unique
 Also use key ID in signatures

13
12/26/24

14
 12/26/24

 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
 Security of private keys thus depends on
the pass-phrase security

15
12/26/24

16
12/26/24

17
12/26/24

18
 12/26/24

 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

19
12/26/24

20
 12/26/24

 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 many mail agents
 eg MS Outlook, Mozilla, Mac Mail etc

21
 12/26/24

EMAIL FORMAT
 Current standard for e-mail format:
 RFC 822 -> RFC 5322
 Standard for e-mail transfer:
 RFC 821 (Simple Mail Transfer Protocol, SMTP)
 Standard for MIME: extension to email format
 RFC 2045-2049
 To address the problems and limitations of
SMTP/RFC5322

22
 12/26/24

LIMITATIONS OF SMTP/RFC5322
 SMTP cannot transmit binary files
 SMTP cannot transmit text that includes
national language characters
 SMTP may reject mails over a certain
size
 SMTP might have translation problem in
character codes
 Some implementations do not adhere
completely to the SMTP standard
23
 12/26/24

MULTIPURPOSE INTERNET MAIL

EXTENSIONS
 MIME includes
 5 New message header fields
 MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-ID, Content-Description
 Multimedia content formats
 MIME content types: RFC 2045
 text, multipart, message, image, video, audio,
application
 Transfer encodings
 7bit, 8bit, binary, quoted-printable, base64, x-
token
24
 12/26/24

MIME CONTENT TYPES

25
 12/26/24

MIIME TRANSFER ENCODINGS

26
 12/26/24

A MULTIPART EXAMPLE
 (See Fig.7.8)

27
 12/26/24

 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

28
 12/26/24

 Digital signatures: DSS & RSA

 Hash functions: SHA-1 & MD5
 Session key encryption: ElGamal & RSA
 Message encryption: AES, Triple-DES,
RC2/40 and others
 MAC: HMAC with SHA-1
 Have process to decide which algs to
use
29
 12/26/24

 S/MIME secures a MIME entity with a

signature, encryption, or both
 Forming a MIME wrapped PKCS object

 Have a range of content-types:

 Enveloped data
 Signed data

 Clear-signed data

 Registration request

 Certificate only message

30
 12/26/24

 S/MIME uses X.509 v3 certificates (Ch.4)

 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

31
 12/26/24

 Have several well-known CA’s

 Verisign one of most widely used
 Verisign issues several types of Digital IDs
 Increasing levels of checks & hence trust
Class Identity Checks Usage
1 name/email check web
browsing/email
2 + enroll/addr check email, subs, s/w
validate
3 + ID documents e-banking/service
access
32
 12/26/24

 3 proposed enhanced security services:

 Signed receipts
 Security labels

 Secure mailing lists

33
 12/26/24

 A specification for cryptographically

signing email messages
 So signing domain claims responsibility
 Recipients / agents can verify signature
 Proposed Internet Standard RFC 4871
 Has been widely adopted: by gmail,
yahoo, and many ISPs

34
12/26/24

35
 12/26/24

 See RFC 4684: Analysis of Threats

Motivating DomainKeys Identified Mail
 Describes the problem space in terms
of:
 Range: low end, spammers, fraudsters
 Capabilities in terms of where submitted,
signed, volume, routing, naming etc
 Location: outside located attackers

36
 12/26/24

 Transparen
t to user
 MSA sign
 MDA verify

 For
pragmatic
reasons
37
12/26/24

38
12/26/24
 12/26/24

 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
40
 12/26/24

 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

41
12/26/24

42
 12/26/24

 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
43
 12/26/24

 specification is quite complex, with

groups:
 Architecture
 RFC4301 Security Architecture for Internet Protocol
 Authentication Header (AH)
 RFC4302 IP Authentication Header
 Encapsulating Security Payload (ESP)
 RFC4303 IP Encapsulating Security Payload (ESP)
 Internet Key Exchange (IKE)
 RFC4306 Internet Key Exchange (IKEv2) Protocol
 Cryptographic algorithms
 Other
44
 12/26/24

 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets
 a form of partial sequence integrity
 Confidentiality (encryption)
 Limited traffic flow confidentiality

45
 12/26/24

 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
46
12/26/24

47
12/26/24

48
 12/26/24

 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
49
 12/26/24

 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

50
 12/26/24

 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

51
12/26/24

52
 12/26/24

 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(integrity
check value) 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
53
 12/26/24

 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)
54
 12/26/24

 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

55
12/26/24

56
 12/26/24

 handles key generation & distribution

 typically need 2 pairs of keys
 2 per direction for AH & ESP
 manual key management
 sysadmin 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

57
 12/26/24

 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

58
 12/26/24

 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

59
12/26/24

60
12/26/24

61
 12/26/24

 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

62
 12/26/24

 variety of cryptographic algorithm

types
 to promote interoperability have
 RFC4308 defines VPN cryptographic suites
 VPN-A matches common corporate VPN
security using 3DES & HMAC
 VPN-B has stronger security for new VPNs
implementing IPsecv3 and IKEv2 using AES
 RFC4869 defines four cryptographic suites
compatible with US NSA specs
 provide choices for ESP & IKE
 AES-GCM, AES-CBC, HMAC-SHA, ECP, ECDSA 63
12/26/24
 12/26/24

 Web now widely used by business,

government, individuals
 But Internet & Web are vulnerable, and
have a variety of threats
 Integrity
 Confidentiality
 Denial of service
 Authentication
 Need added security mechanisms

65
 12/26/24

 In terms of passive and active attacks

 Eavesdropping
 Impersonating a user, altering messages

 In terms of location of the threat

 System: Web server, Web browser
 Network: network traffic between browser
and server

66
12/26/24

67
 12/26/24

 IPsec: general purpose

 Transparent to end users and applications
 SSL/TLS: above TCP
 Transparent: part of protocol suite
 Embedded in packages: e.g. Web browser
with SSL
 Application specific: Kerberos, S/MIME

68
 12/26/24

 Transport layer security service

 Originally developed by Netscape
 Version 3 designed with public input
(Internet draft)
 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
69
12/26/24

70
 12/26/24

 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
71
 12/26/24

 Confidentiality
 Using symmetric encryption with a shared
secret key defined by Handshake Protocol
 Block cipher: AES, IDEA, RC2-40, DES-40, DES,
3DES, Fortezza
 Stream cipher: RC4-40, RC4-128
 Message is compressed before encryption
 Message integrity
 Using a MAC with shared secret key
 Similar to HMAC but with different padding

72
12/26/24

73
12/26/24

74
 12/26/24

 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

75
 12/26/24

 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 76
 12/26/24

 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
77
12/26/24

78
 12/26/24

 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

79
 12/26/24

 IETF standard RFC 5246 similar to

SSLv3 with minor differences
 In record format: version number (minor:
3)
 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
80
 12/26/24

 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 4256
 SSH clients & servers are widely available
 Method of choice for remote login/ X tunnels

81
12/26/24

82
 12/26/24

 Server authentication occurs at

transport layer, based on server/host
key pair(s)
 Server authentication requires clients to
know public 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 83
 12/26/24

 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

84
 12/26/24

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

85
12/26/24

86
 12/26/24

 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
87