CS6004 CYBER FORENSICS

UNIT – I

Dr.A.Kathirvel, Professor, Dept of CSE M N M Jain Engineering College, Chennai

UNIT - I

NETWORK LAYER SECURITY &TRANSPORT LAYER SECURITY

IPSec Protocol – IP Authentication Header – IP ESP – Key Management Protocol for IPSec . Transport layer Security: SSL protocol, Cryptographic Computations – TLS Protocol.

2

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

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 3 Recipient 1 Recipient 2 4

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

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

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

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

PGP Services

1 Authentication

2. Confidentiality

3. Compression

4.E-mail Compatibility

5.Segmentation & Reassembly

9

10

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

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

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

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

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

PGP Operation

16

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

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

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

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

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

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

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

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

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

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

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

IPSec Document Overview

29

IP Security Uses

30

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

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

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

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

Transport and

Tunnel Modes

35

Transport and

Tunnel Mode

Protocols

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

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

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

Before applying AH

Transport Mode (AH Authentication)

40

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

Encapsulating Security Payload

42

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

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

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

Combining Security Associations

46

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

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

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

IKEV2 Exchanges

50

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

ISAKMP

52

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

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

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

Web Traffic Security Approaches

56

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

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

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

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

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

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

SSL Handshake Protocol

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

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

Introduction

• Transport Layer Security (TLS) [RFC2246]

• TLS provides transport layer security for Internet applications

• It provides for confidentiality and data integrity over a connection between two end points

• TLS operates on a reliable transport, such as TCP, and is itself layered into

– TLS Record Protocol

– TLS Handshake Protocol

66

Advantage of TLS

–applications can use it transparently to securely communicate with each other

–TLS is visible to applications, making them aware of the cipher suites and authentication certificates negotiated during the set-up phases of a TLS session

67

TLS Record Protocol

• TLS Record Protocol layers on top of a reliable connection-oriented transport, such as TCP

• TLS Record Protocol – provides data confidentiality using symmetric key

cryptography

– provides data integrity using a keyed message authentication checksum (MAC)

• The keys are generated uniquely for each session based on the security parameters agreed during the TLS handshake

68

TLS Record Protocol

• Basic operation of the TLS Record Protocol

1. read messages for transmit

2. fragment messages into manageable chunks of data

3. compress the data, if compression is required and enabled

4. calculate a MAC

5. encrypt the data

6. transmit the resulting data to the peer

69

TLS Record Protocol

• At the opposite end of the TLS connection, the basic operation of the sender is replicated, but in the reverse order 1. read received data from the peer

2. decrypt the data

3. verify the MAC

4. decompress the data, if compression is required and enabled

5. reassemble the message fragments

6. deliver the message to upper protocol layers

70

TLS Handshake Protocol • TLS Handshake Protocol is layered on top of the TLS

Record Protocol

• TLS Handshake Protocol is used to

– authenticate the client and the server

– exchange cryptographic keys

– negotiate the used encryption and data integrity algorithms before the applications start to communicate with each other

• Fig 14.1 illustrates the actual handshake message flow

– [Step1]

• the client and server exchange Hello messages

• the client sends a ClientHello message, which is followed by the server sending a ServerHello message

71

• these two messages establish the TLS protocol version, the compression mechanism used, the cipher suite used, and possibly the TLS session ID

• additionally, both a random client nonce and a random server nonce are exchanged that are used in the handshake later on

• [Step2]

– the server may send any messages associated with the ServerHello

– depending on the selected cipher suite, it will send its certificate for authentication

– the server may also send a key exchange message and a certificate request message to the client, depending on the selected cipher suite

– to mark the end of the ServerHello and the Hello message exchange, the server sends a ServerHelloDone message

72

•Digest of all the

handshake messages

•means the results

of applying a one-

way hash function

to the handshake

messages

73

• [Step3]

– next, if requested, the client will send its certificate to the server

– in any case, the client will then send a key exchange message that sets the pre-master secret between the client and the server

– optionally, the client may also send a Certificate Verify message to explicitly verify the certificate that the server requested

• [Step4]

– then, both the client and the server send the ChangeCipherSpec messages and enable the newly negotiated cipher spec

– the first message passed in each direction using the new algorithms, keys and secrets is the Finished message, which includes a digest of all the handshake messages

– each end inspects the Finished message to verify that the handshake was not tampered with

74