cyber forensics - an abode for inceptional …...cyber forensics cs6004 vignesh.l.s ap/cse page 3...

CYBER FORENSICS CS6004

VIGNESH.L.S AP/CSE

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.

What are the types of IPSec Protocol?

There are two main transformation types that form the basics of IPsec, the Authentication

Header (AH) and the Encapsulating Security Payload (ESP). Both AH and ESP are two protocols that

provide connectionless integrity, data origin authentication, confidentiality and an anti-replay

service. These protocols may be applied alone or in combination to provide a desired set of security

services for the IP layer. They are configured in a data structure called a Security Association (SA).

What are the various security services provided at IP layer?

The set of security services provided at the IP layer includes access control, connectionless

integrity, data origin authentication, protection against replays and confidentiality. The modularity

which is designed to be algorithm independent permits selection of different sets of algorithms

without affecting the other parts of the implementation.

Define Security Association.

The SA is a key concept that appears in both the authentication and confidentiality

mechanisms for IPsec. An SA is a simplex connection between a sender and receiver that affords

security services to the traffic carried on it. If both AH and ESP protection are applied to a traffic

stream, then two SAs are required for two-way secure exchange.

What are the three parameters of Security Association?

Security Parameters Index (SPI) - This is assigned to each SA, and each SA is identified

through an SPI. A receiver uses the SPI to identify the security association for a packet. The SPI is

carried in AH and ESP headers to enable the receiver to select the SA under which a received packet

is processed.

IP Destination Address - Unicast addresses are only allowed by IPsec SA management

mechanisms, this is the address of the destination endpoint of the SA. The destination endpoint may

be an end-user system or a network system such as a firewall or router.

Security Protocol Identifier - This identifier indicates whether the association is an AH or ESP

security association.

What are the database models to process the IP Traffic?

There are two nominal databases in a general model for processing IP traffic relative to SAs,

namely, the Security Policy Database (SPD) and the Security Association Database (SAD). The SPD

specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host

or security gateways, while the SAD contains parameters that are associated with each security

association.

Define Security Policy Database.

The SPD, which is an essential element of SA processing, specifies what services are to be

offered to IP datagrams and in what fashion. The SPD is used to control the flow of all traffic


VIGNESH.L.S AP/CSE

(inbound and outbound) through an IPsec system, including security and key management traffic

(i.e. ISAKMP). The SPD contains an ordered list of policy entries. The entry for IPsec processing

includes SA (or SA bundle) specification, limiting the IPsec protocols, modes and algorithms to be

employed.

Define Security Association Database.

The SAD contains parameters that are associated with each security association. Each SA has

an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. For

inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type

and SPI.

Explain the two modes/ types of Security Associations.

A transport mode provides protection primarily for upper-layer protocols, i.e. a TCP packet

or UDP segment or an Internet Control Message Protocol (ICMP) packet, operating directly above

the IP layer. A transport mode SA is a security association between two hosts. In the case of AH, AH

in transport mode authenticates the IP payload and the protection is also extended to selected

portions of the IP header, selected portions of IPv6 extension headers and the selected options. In

the case of ESP, ESP in transport mode primary encrypts and optionally authenticates the IP payload

but not the IP header. A transport mode SA provides security services only for higher-layer

protocols, not for the IP header or any extension headers proceeding the ESP header.

Tunnel mode provides protection to the entire IP packet. A tunnel mode SA is essentially an

SA applied to an IP tunnel. Whenever either end of an SA is a security gateway, the SA must be

tunnel mode, as is an SA between a host and a security gateway. Note that a host must support both

transport and tunnel modes, but a security gateway is required to support only tunnel mode. When

the AH and ESP fields are added to the IP packet, the entire packet plus security field (AH or ESP) is

treated as the new outer IP packet with a new outer IP header. ESP in tunnel mode encrypts and

optionally authenticates the entire inner IP packet, including the inner IP header. AH in tunnel mode

authenticates the entire inner IP packet and selected portions of the outer IP header.

Explain the types of Message Authentication Functions and Message Authentication Code.

Message Authentication Functions

∑ Message authentication has two levels of functionality.

∑ At the lower level, a function that produces an authenticator, a value to be used to authenticate

a message.

∑ In a higher-level authentication protocol that enables a receiver to verify the authenticity of a

message.

∑ Different types of functions that may be used to produce an authenticator are grouped into

three classes:

1. Hash function: A function that maps a message of any length into a fixed length hash

value, which serves as the authenticator

2. Message encryption: The ciphertext of the entire message serves as its authenticator.

3. Message authentication code (MAC): A function of the message and a secret key that

produces a fixed-length value that serves as the authenticator.

Message Authentication Code

∑ An authentication technique that involves the use of a secret key to generate a small fixed-

size block of data, known as a cryptographic checksum or MAC, that is appended to the

message.


VIGNESH.L.S AP/CSE

∑ Assumes that two communicating parties, say A and B, share a common secret key K.

∑ MAC is calculated as MAC = C(K, M) where

M = input message, C = MAC function, K = shared secret key, MAC = message authentication

code. MAC(K, M) is the fixed-length authenticator, sometimes called a tag.

∑ The message plus MAC are transmitted to the intended recipient.

∑ The recipient performs the same calculation on the received message, using the same secret

key, to generate a new MAC. The received MAC is compared to the calculated MAC.

Explain in detail the working of H-MAC Algorithm with steps.

¸ HMAC stands for Hash-based MAC. It works by using an underlying hash function over a

message and a key.

¸ Any hash function could be used with HMAC, although more secure hashing functions are

preferable. Commonly used hash functions are MD5 and SHA-1.

¸ As computers become more and more powerful, increasingly complex hash functions will

probably be used.

¸ Speed is the main reason. Hash functions are much faster than block ciphers such as DES and

AES in software implementation

¸ Another advantage is that they are freely available, and are not subject to the export

restriction rules of the USA and other countries.

¸ However, HMAC, as a cryptographic mechanism, is repudiatable. That is, Bob cannot

demonstrate that data really came from Alice -- both a sender and a receiver can generate

an exactly same HMAC output (so Bob could have made the data himself). This is unlike

digital signatures which only the sender can generate.

¸ You use HMAC whenever you want integrity of the data maintained (and authenticity)

¸ The key is part of the HMAC, since it is a shared secret known between 2 parties only and

only they can create the HMAC and no one else. (Ensures authenticity)

¸ Length extension attacks are not possible on HMAC. MAC's on the other hand simply appends key to the message, which is susceptible to it. HMAC was introduced to overcome

this attack on MAC's.

HMAC Structure

HMAC is a secret-key authentication algorithm which provides both data integrity and data

origin authentication for packets sent between two parties. Its definition requires a cryptographic

hash function H and a secret key K. H denotes a hash function where the message is hashed by

iterating a basic compression function on data blocks. Let b denote the block length of 64 bytes or

512 bits for all hash functions such as MD5 and SHA-1. h denotes the length of hash values, i.e. h =

16 bytes or 128 bits for MD5 and 20 bytes or 160 bits for SHA-1. The secret key K can be of any

length up to b = 512 bits.

To compute HMAC over the message, the HMAC equation is expressed as follows:

where,

ipad = 00110110(0x36) repeated 64 times (512 bits)

opad = 01011100(0x5c) repeated 64 times (512 bits)

ipad is inner padding opad is outer padding.


VIGNESH.L.S AP/CSE

The following explains the HMAC equation:

1. Append zeros to the end of K to create a b-byte string (i.e. if K = 160 bits in length

and b = 512 bits, then K will be appended with 352 zero bits or 44 zero bytes 0x00).

2. XOR (bitwise exclusive-OR) K with ipad to produce the b-bit block computed in step 1.

3. Append M to the b-byte string resulting from step 2.

4. Apply H to the stream generated in step 3.

5. XOR (bitwise exclusive-OR) K with opad to produce the b-byte string computed in step 1.

6. Append the hash result H from step 4 to the b-byte string resulting from step 5.

7. Apply H to the stream generated in step 6 and output the result.

The alternative operation for computation of either HMAC–MD5 or HMAC–SHA-1 is described in the

following:

1. Append zeros to K to create a b-bit string K‘, where b = 512 bits.

2. XOR K‘ (padding with zero) with ipad to produce the b-bit block.

3. Apply the compression function f(IV, K‘ ⊕ipad) to produce (IV)i = 128 bits.

4. Compute the hash code h with (IV)i and Mi.

5. Raise the hash value computed from step 4 to a b-bit string.

6. XOR K‘ (padded with zeros) with opad to produce the b-bit block.

7. Apply the compression function f(IV, K‘⊕opad) to produce (IV)0 = 128 bits.

8. Compute the HMAC with (IV)o and the raised hash value resulting from step 5.

Draw the header format for Authentication Header and explain the fields in detail.

Authentication Header (AH) is a member of the IPsec protocol suite. AH guarantees connectionless

integrity and data origin authentication of IP packets. Further, it can optionally protect against replay

attacks by using the sliding window technique and discarding old packets.

∑ In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for

mutable fields (i.e. those that might be altered in transit), and also IP options such as the IP


VIGNESH.L.S AP/CSE

Security Option (RFC 1108). Mutable (and therefore unauthenticated) IPv4 header fields are

DSCP/ToS, ECN, Flags, Fragment Offset, TTL and Header Checksum.

∑ In IPv6, the AH protects most of the IPv6 base header, AH itself, non-mutable extension headers

after the AH, and the IP payload. Protection for the IPv6 header excludes the mutable fields:

DSCP, ECN, Flow Label, and Hop Limit.

∑ AH operates directly on top of IP, using IP protocol number 51.

Next header (8 bits)

This field identifies the type of the next payload after the AH. The value of this field is chosen

from the set of IP numbers defined in the Internet Assigned Number Authority (IANA).

Payload Len (8 bits)

The length of this Authentication Header in 4-octet units, minus 2. For example, an AH value

of 4 equals 3×(32-bit fixed-length AH fields) + 3×(32-bit ICV fields) − 2 and thus an AH value of 4

means 24 octets. Although the size is measured in 4-octet units, the length of this header needs to

be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to an

Authentication Header carried in an IPv4 packet.

Reserved (16 bits)

Reserved for future use (all zeroes until then).

Security Parameters Index (32 bits)

Arbitrary value which is used (together with the destination IP address) to identify the

security association of the receiving party.

Sequence Number (32 bits)

A monotonic strictly increasing sequence number (incremented by 1 for every packet sent)

to prevent replay attacks. When replay detection is enabled, sequence numbers are never reused,

because a new security association must be renegotiated before an attempt to increment the

sequence number beyond its maximum value.

Integrity Check Value (multiple of 32 bits)

Variable length check value. It may contain padding to align the field to an 8-octet boundary

for IPv6, or a 4-octet boundary for IPv4.

Explain in detail about the location of AH in both transport and tunnel mode in IPv4 and IPv6.

AH Location:

Either AH or ESP is employed in two ways: transport mode or tunnel mode. The transport

mode is applicable only to host implementations and provides protection for upper-layer protocols.

In the transport mode, AH is inserted after the IP header and before an upperlayer protocol (TCP,

UDP or ICMP), or before any other IPsec header that may have already been inserted. In the IPv4

context, AH is placed after the original IP header and before the upper-layer protocol TCP or UDP. In

the IPv6 context, AH should appear after hop-to-hop, routing and fragmentation extension headers.


VIGNESH.L.S AP/CSE

The destination options extension header(s) could appear either before or after AH, depending on

the semantics desired.

Tunnel mode AH can be employed in either hosts or security gateways. When AH is

implemented in a security gateway to protect transit traffic, tunnel mode must be used. In tunnel

mode, the inner IP header carries the ultimate source and destination addresses, while an outer IP

header may contain different IP addresses (i.e. addresses of firewalls or other security gateways). In

tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The

position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport

mode.

Explain in detail about ESP and the various fields in ESP packet.

IP ESP Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it

provides origin authenticity, integrity and confidentiality protection of packets. ESP also supports

encryption-only and authentication-only configurations, but using encryption without authentication

is strongly discouraged because it is insecure. Unlike Authentication Header (AH), ESP in transport

mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel

Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP

protection is afforded to the whole inner IP packet (including the inner header) while the outer


VIGNESH.L.S AP/CSE

header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP

operates directly on top of IP, using IP protocol number 50.

The following ESP packet diagram shows how an ESP packet is constructed and interpreted:

Security Parameters Index (32 bits)

Arbitrary value used (together with the destination IP address) to identify the security

association of the receiving party.

Sequence Number (32 bits)

A monotonically increasing sequence number (incremented by 1 for every packet sent) to

protect against replay attacks. There is a separate counter kept for every security association.

Payload data (variable)

The protected contents of the original IP packet, including any data used to protect the

contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was

protected is indicated by the Next Header field.

Padding (0-255 octets)

Padding for encryption, to extend the payload data to a size that fits the encryption's cipher

block size, and to align the next field.

Pad Length (8 bits)

Size of the padding (in octets).

Next Header (8 bits)

Type of the next header. The value is taken from the list of IP protocol numbers.

Integrity Check Value (multiple of 32 bits)

Variable length check value. It may contain padding to align the field to an 8-octet boundary

for IPv6, or a 4-octet boundary for IPv4.

Explain in detail about the location of ESP Header in both transport and tunnel mode in IPv4 and

IPv6.

ESP Header Location ESP is also employed in the two transport or tunnel modes. The transport mode is applicable

only to host implementations and provides protection for upper protocols, but not the IP header. In

the transport mode, ESP is inserted after the IP header and before an upper-layer protocol (TCP,

UDP or ICMP), or before any other IPsec headers that have already been inserted. In the IPv4

context, ESP is placed after the IP header, but before the upper-layer protocol. Note that an ICMP

message may be sent using either the transport mode or the tunnel mode. The ESP trailer

encompasses any padding, plus the pad length, and next header fields.


VIGNESH.L.S AP/CSE

In the IPv6 context, the ESP appears after hop-by-hop, routing and fragmentation extension

headers. The destination options extension header(s) could appear either before or after the ESP

header depending on the semantics desired. However, since ESP protects only fields after the ESP

header, it is generally desirable to place the destination options header(s) after the ESP header.

Tunnel mode ESP can be employed in either hosts or security gateways. When ESP is implemented in

a security gateway to protect subscriber transit traffic, tunnel mode must be used. In tunnel mode,

the inner IP header carries the ultimate source and destination addresses, while an outer IP header

may contain different IP addresses such as addresses of security gateways. In tunnel mode, ESP

protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel

mode, relative to the outer IP header, is the same as for ESP in transport mode.

What are the various algorithms used in the process of security in Network Layer? Encryption

ESP is designed for use with symmetric algorithms like a triple DES in CBC mode. For

encryption to be applied, the sender encapsulates the ESP payload field, adds any necessary

padding, and encrypts the result (i.e. payload data, padding, pad length and next header). The

sender encrypts the fields (payload data, padding, pad length and next header) using the key,

encryption algorithm, algorithm mode indicated by the SA and an IV (cryptographic synchronisation

data). If the algorithm to be encrypted requires an IV, then this data is carried explicitly in the

payload field. The payload data field is an integral number of bytes in length. Since ESP provides

padding for the plaintext, encryption algorithms employed by ESP exhibit either block or stream

mode characteristics.


VIGNESH.L.S AP/CSE

The 3DES–CBC mode requires an IV that is the same size as the block size. The IV is XORed

with the first plaintext block before it is encrypted. For successive blocks, the previous ciphertext

block is XORed with the current plaintext before it is encrypted. Triple DES, known as DES–EDE3,

processes each block three times, each time with a different key. Therefore, the triple DES algorithm

has 48 rounds. In DES–EDE3-CBC, an IV is XORed with the first 64-bit plaintext block (P1). Some

cipher algorithms allow for a variable-sized key (RC5), while others only allow a specific key size

(DES, IDEA).

Decryption

The receiver decrypts the ESP payload data, padding, pad length and next header using the

key, encryption algorithm, algorithm mode and IV data. If explicit IV data is indicated, it is taken from

the payload field and input to the decryption algorithm. If implicit IV data is indicated, a local version

of the IV is constructed and input to the decryption algorithm.

The exact steps for reconstructing the original datagram depend on the mode (transport or

tunnel) and are described in the Security Architecture document. The receiver processes any

padding as given in the encryption algorithm specification. For transport mode, the receiver

reconstructs the original IP datagram from the original IP header plus the original upper-layer

protocol information in the ESP payload field. For tunnel mode, the receiver reconstructs the tunnel

IP header plus the entire IP datagram in the ESP payload field.

Authentication

The authentication algorithm employed for the ICV computation is specified by the SA. For

communication between two points, suitable authentication algorithms include Keyed Message

Authentication Codes (MACs) based on symmetric encryption algorithms (i.e. DES) or on one-way

hash function (i.e. MD5 or SHA-1). For multicast communication, one-way hash algorithms combined

with asymmetric signature algorithms are appropriate.

Integrity Check Vector

Once the SA selects the authentication algorithm, the sender computes the ICV over the ESP

packet minus the authentication data. The ICV is an MAC or a truncated value of a code produced by

an MAC algorithm. As with AH, ESP supports the use of an MAC with a default length of 96 bits. The

current specification for use of the HMAC computation must support:

HMAC–MD5–96

HMAC–SHA-1–96


VIGNESH.L.S AP/CSE

What are the various Key Management Protocols used for IPSec?

OAKLEY Key Determination Protocol

ISAKMP

Discuss in detail about OAKLEY Key Determination Protocol.

The Diffie–Hellman key exchange algorithm provides a mechanism that allows two users to

agree on a shared secret key without requiring encryption. This shared key is immediately available

for use in encrypting subsequent data transmission. Oakley is not only a refinement of the Diffie–

Hellman key exchange algorithm, but a method to establish an authentication key exchange. The

Oakley protocol is truly used to establish a shared key with an assigned identifier and associated

authenticated identities for the two parties. Oakley can be used directly over the IP protocol or over

UDP protocol using a well-known port number assignment available.

It is worth to note that Oakley uses the cookies for two purposes: anti-clogging (denial of

service) and key naming. The anti-clogging tokens provide a form of source address identification for

both parties. The construction of the cookies prevents an attacker from obtain a cookie using a real

IP address and UDP port.

Creating the cookie is to produce the result of a one-way function applied to a secret value,

the IP source and destination addresses, and the UDP source and destination ports. Protection

against the anti-clogging always seems to be one of the most difficult to address. A cookie or anti-

clogging token is aimed for protecting the computing resources from attack without spending

excessive CPU resources to determine its authenticity. Absolute protection against anti-clogging is

impossible, but this anti-clogging token provides a technique for making it easier to handle.

Oakley employs nonces to ensure against replay attacks. Each nonce is a pseudorandom

number which is generated by the transmitting entity. The nonce payload contains this random data

used to guarantee liveness during a key exchange and protect against replay attacks. If nonces are

used by a particular key exchange, the use of the nonce payload will be dictated by the key

exchange. The nonces may be transmitted a part of the key exchange data.

All the Oakley message fields correspond to ISAKMP message payloads. The relevant payload

fields are the SA payload, the authentication payload, the certification payload, and the exchange

payload. Oakley is the actual instantiation of ISAKMP framework for IPsec key and SA generation.

The exact mapping of Oakley message fields to ISAKMP payloads is in progress at this time.

Draw the header format for ISAKMP protocol and explain the various fields present in it.

ISAKMP defines a framework for SA management and cryptographic key establishment for

the Internet. This framework consists of defined exchange, payloads and processing guidelines that

occur within a given DOI. ISAKMP defines procedures and packet formats to establish, negotiate,

modify and delete SAs. It also defines payloads for exchanging key generation and authentication

data. ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the

network stack. By centralising the management of the SAs, ISAKMP reduces the amount of

duplicated functionality within each security protocol.

ISAKMP Payloads

ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The

presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type

Field located in the ISAKMP Header.


VIGNESH.L.S AP/CSE

ISAKMP Header

The various fields present are:

Initiator Cookie (64 bits)

This field is the cookie of entity that initiated SA establishment, SA notification, or SA

deletion.

Responder Cookie (64 bits)

This field is the cookie of entity that is corresponded to an SA establishment request, SA

notification, or SA deletion.

Next Payload (8 bits)

This field indicates the type of the first payload in the message.

Major Version (4 bits)

This field indicates the Major version of the ISAKMP protocol in use. Set the Major version to

1 according to ISAKMP Internet-Draft.

Minor Version (4 bits)

This field indicates the Minor version of ISAKMP protocol in use. Set the Minor version to 0

according to implementations based on the ISAKMP Internet-Draft.

Exchange Type (8 bits)

This field indicates the type of exchange being used. This dictates the message and payload

orderings in the ISAKMP exchanges.

Flags (8 bits)

This field indicates specific options that are set for the ISAKMP exchange. The Flags are

specified in the Flags field beginning with the least significant bit: the encryption bit is bit 0 of the

Flags field, the commit bit is bit 1, and authentication only bit is bit 2 of the Flags field. The

remaining bits of the Flags field must be set to 0 prior to transmission.

Message ID (32 bits)

Message ID is used to identify protocol state during Phase 2 negotiations. This value is

randomly generated by the initiator of the phase 2 negotiation. During Phase 1 negotiation, this

value must be set to 0.

Length (32 bits)

Length of total message (header || payload) is 32 bits. Encryption can expand the size of an

ISAKMP message.


VIGNESH.L.S AP/CSE

List and explain the various payloads present in ISAKMP Protocol and the steps in processing each

payloads.

General Message Processing

Every ISAKMP message has basic processing applied to insure protocol reliability and to

minimize threats such as denial of services and replay attacks. All processing should include packet

length checks to insure the packet received is at least as long as the length given in the ISAKMP

Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP

Header are not the same, then ISAKMP message must be rejected.

ISAKMP Header Processing

When an ISAKMP message is created at the transmitting entity, the initiator (transmitter)

must create the respective cookie, determine the relevant security characteristics of the session,

construct an ISAKMP Header with fields, and transmit the message to the destination host

(responder).

When an ISAKMP is received at the receiving entity, the responder (receiver) must verify the

Initiator and Responder cookies, check the Next Payload field to confirm it is valid, check the Major

and Minor Version fields to confirm they are correct, check the Exchange Type field to confirm it is

valid, check the Flags field to ensure it contains correct values, and check the Message ID field to

ensure it contains correct values.

Generic Payload Header

Each ISAKMP payload begins with a generic header which provides a payload chaining

capability and clearly defines the boundaries of a payload.

The generic payload header fields in 32 bits are defined as follows:

Next Payload (8 bits)

This field is identifier for the payload type of the next payload in the message. If the current

payload is the last in the message, then this field will be 0. This field provides the chaining capability.

Reserved (8 bits)

This field is not used and set to 0.

Payload Length (16 bits)

This field indicates the length in bytes of the current payload, including the generic payload

header.

Generic Payload Header Processing: When any of the ISAKMP Payloads are created, a Generic Payload Header is placed at the

beginning of these payloads. When creating the Generic Payload Header, the transmitting entity

(initiator) must place the value of the Next Payload in the Next Payload field, place the value zero (0)

in the Reserved field, place the length (in octets) of the payload in the Payload Length field, and

construct the payloads.

When any of the ISAKMP Payloads are received, the receiving entity (responder) must check

the Next Payload field to confirm it is valid, verify the Reserved field contains the value zero (0), and

process the remaining payloads as defined by the Next Payload field.

Security Association Payload

The Security Association Payload is used to negotiate security attirutes and to identify the

Domain of Interpretation (DOI, 32 bits) under which negotiation is taking place. A DOI value of 0

during a Phase 1 exchange specifies a Generic ISAKMP which can be used for any protocol during the

Phase 2 exchange. A DOI value of 1 is assigned to the IPsec DOI.

The Security Association Payloads are defined as follows:

The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the

message. This field has a value of 0 if this is the last payload in the message.


VIGNESH.L.S AP/CSE

The Reserved field (8 bits) is unused, set to 0.

The Payload Length field (16 bits) indicates the length in octets of the entire Security

Association payload, including the SA payload, all Proposal payloads, and all Transform payloads

associated with the proposed SA.

The Situation field (variable length) is a DOI-specific field that identifies the situation under

which negotiation is taking a place. The Situation field defines policy decisions regarding the security

attributes being negotiated.

Security Association Payload Processing: When a Security Association Payload is created, the transmitting entity (initiator) must

determine the Domain of Interpretation (DOI) for which this negotiation is being preformed. When a

Security Association payload is received, the receiving entity (responder) must determine if the DOI

is supported, determine if the given situation can be protected, and process the remaining payloads

(Proposal, Transform) of the SA payload. If the SA Proposal is not accepted, then the Invalid Proposal

event may be logged in the appropriate system audit file. An Information Exchange with a

Notification payload containing the No-Proposal-Chosen message type may be sent to the

transmitting entity (initiator). This action is dictated by a system security policy.

Proposal Payload

The Proposal Payload is used to build ISAKMP message for the negotiation and

establishment of SAs. The Proposal Payload field contains information used during SA negotiation for

securing the communications channel. The payload type for the Proposal Payload is two (2).

The Proposal Payload fields are defined as follows:


message. This field must only contain the value 2 or 0. This field will be 2 for additional Proposal

Payloads in the message and 0 when the current Proposal Payload is the last within the SA proposal.

The Reserved field (8 bits) is set to 0 and is reserved it for the future use.

The Payload Length field (16 bits) is the length in octets of the entire Proposal payload,

including generic payload header, the Proposal Payload, and all Transform payloads associated with

this proposal.

The Proposal # field (8 bits) identifies the proposal number for the current payload.

The Protocol-id field (8 bits) specifies the protocol identifier for the current negotiation.

The SPI Size (8 bits) denotes the length in octets of the SPI. In the case of ISAKMP, the

Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI. The

SPI size may be from zero(0) to sixteen (16). If the SPI size is non-zero, the content of the SPI

field must be ignored. The DOI will dictate the SPI Size for other protocols.

# of Transform (8 bits) specifies the number of transforms for the proposal.

SPI field (variable) is the sending entity‘s SPI. In the event of the SPI size is not a multiple of 4

octets, there is no padding applied to the payload.

Proposal Payload Processing:

When a Proposal Payload is created, the transmitting entity (initiator) must determine the

Protocol for this proposal, determine the number of proposals to be offered for this proposal and

the number of transform for each proposal, generate a unique pseudo-random SPI, and construct a

Proposal payload.

When a Proposal payload is received, the receiving entity (responder) must determine if the

proposal is supported and if the Protocol-ID field is invalid, determine whether the SPI is valid or not,

ensure whether or not proposals are formed correctly, and then process the Proposal and Transform

payloads as defined by the Next Payload field.


VIGNESH.L.S AP/CSE

Transform Payload The Transform Payload contains information used during Security Association negotiation.

The Transform Payload consists of a specific security mechanism to be used to secure the

communications channel. The Transform Payload also contains the security association attributes

associated with the specific transform.

The Transform Payload fields are defined as follows:


message. This field must only contain the value 3 or 0. This field is 3 when there are additional

Transform payloads in the proposal. This field is 0 when the current Transform Payload is the last

within the proposal.

The Reserved field (8 bits) is for unused, set to 0.

The Transform # field (8 bits) identifies the Transform number for the current payload. If there is

more than one transform within the Proposal Payload, then each Transform Payload has a unique

Transform number.

The Transform-id field (8 bits) specifies the Transform identifier for the protocol within the current

proposal.

The Reserved 2 field (16 bits) is for unused, set to 0. The payload type for the Transform Payload is

three (3).

Transform Payload Processing:

When creating a Transform Payload, the transmitting entity (initiator) must determine the

Transform # for this transform, determine the number of transforms to be offered for this proposal,

and construct a Transform payload.

When a Transform payload is received, the receiving entity (responder) must do as follows:

Determine if the Transform is supported. If the Transform-ID field contains an unknown or

unsupported value, then that Transform payload must be ignored. Finally, process the subsequent

Transform and Proposal payloads as defined by the Next Payload field.

Key Exchange Payload

The Key Exchange Payload supports a variety of key exchange techniques. Example key

exchanges are Oakley, Diffie-Hellman, the enhanced D-H key exchange, and the RSA-based key

exchange used by PGP.

The Key Exchange Payload fields are defined as follows:


message. If the current payload is the last in the message, then this field will be 0.

The Reserved field (8 bits) is unused for the future use, set to 0.

The Payload Length field (16 bits) is the length in octets of the current payload, including the generic

payload header.

The Key Exchange Data field (variable length) is the data required to generate a session key.

Key Exchange Payload Processing:

When creating a Key Exchange payload, the transmitting entity (initiator) must determine

the Key Exchange to be used as defined by the DOI, determine the usage of Key Exchange Data field

as defined by the DOI, and construct a Key Exchange payload. When a Key Exchange payload is

received, the receiving entity (responder) must determine if the Key Exchange is supported.

If the Key Exchange determination fails, the message is discarded and the following actions

are taken:

The event of Invalid Key Information may be logged in the appropriate system audit file. An

Informational Exchange with a Notification payload containing the Invalid-Key- Information message

type may be sent to the transmitting entity. This action is dictated by a system security policy.


VIGNESH.L.S AP/CSE

Identification Payload The Identification Payload contains DOI-specific data used to exchange identification

information. This information is used for determining the identities of communication partners and

may be used for determining authenticity of information.

The Identification Payload fields are described as follows:

The Next Payload field (8 bits) is the identifier for the payload type of the Next Payload in the


The Reserved field (8 bits) is not used, but set to 0.


payload header.

The ID type field (8 bits) specifies the type of identification being used. This field is DOI-dependent.

The DOI specific ID Data field (24 bits) contains DOI specific identification data. If unused, then this

field must be set to 0.

The Identification Data field (variable length) contains identity information.

The payload type for the Identification Payload is five (5).

Identification Payload Processing:

When an Identification Payload is created, the transmitting entity (initiator) must determine

the Identification information to be used as defined by the DOI, determine the usage of the

Identification Data field as defined by the DOI, construct an Identification payload, and finally

transmit the message to the receiving entity.

When an Identification payload is received, the receiving entity (responder) must determine

if the Identification Type is supported. This may be based on the DOI and Situation. If the

Identification determination fails, the message is discarded. An Informational Exchange with a

Notification payload containing the Invalid-ID-Information message type is sent to the transmitting

entity (initiator).

Certificate Payload The Certificate Payload provides a mean to transport certificates via ISAKMP and can appear in any

ISAKMP message. Certificate payloads should be included in an exchange whenever an appropriate

directory service is not available to distribute certificates.

The Certificate Payload fields are defined as follows:

The Next Payload field (8 bits) is the identifier for the Payload type of the next payload in the


The Reserved field (8 bits) is unused, set to 0.


payload header.

The Certificate Encoding field (8 bits) indicates the type of certificate or certificate-related

information contained in the Certificate Data field.

The Certificate Data field (variable length) denotes actual encoding of certificate data.

The type of certificate is indicated by the Certificate Encoding field.

The Payload type for the Certificate payload is six (6).

Certificate Payload Processing:

When a Certificate Payload is created, the transmitting entity (initiator) must determine the

Certificate Encoding which is specified by the DOI, ensure the existence of a certificate formatted as

defined by the Certificate Encoding, construct a Certificate payload, and then transmit the message

to the receiving entity (responder).

When a Certificate payload is received, the receiving entity (responder) must determine if

the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is


VIGNESH.L.S AP/CSE

discarded. The responder then processes the Certificate Data field. If the Certificate Data is

improperly formatted, the payload is discarded.

Certificate Request Payload

The Certificate Request Payload provides a mean to request certificate via ISAKMP and can

appear in any message. Certificate Request Payloads should be included in an exchange whenever

an appropriate directory service is not available to distribute certificates.

The Certificate Request Payload fields are defined as follows:



The Reserved field (8 bits) is not used, set to 0.


payload header.

The Certificate Type field (8 bits) contains an encoding of the type of certificate requested.

Acceptable values are listed in the Certificate Payload fields.

The Certificate Authority field (variable length) contains an encoding of an acceptable certificate

authority for the type of certificate requested.

The payload type for the Certificate Request Payload is seven (7).

Certificate Request Payload Processing: When creating a Certificate Request Payload, the transmitting entity (initiator) must

determine the type of Certificate Encoding to be requested, determine the name of an acceptable

Certificate Authority, construct a Certificate Request payload, and then transmit the message to the

receiving entity (responder).

When a Certificate Request payload is received, the receiving entity (responder) must

determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload

is discarded. If the Certificate Authority is improperly formatted, the payload is discarded. Finally,

the responder must process the Certificate Request. If a requested Certificate Type with the

specified Certificate Authority is not available, then the payload is discarded.

Hash Payload

The Hash Payload contains data generated by the hash function over some part of the

message and/or ISAKMP state. This payload possibly be used to verify the integrity of the data in an

ISAKMP message or for authentication of the negotiating entities.

The Hash Payload fields are defined as follows:



The Reserved field (8 bits) is not used, set to 0.


payload header.

The Hash Data field (variable length) is the data that results from applying the hash routine to the

ISAKMP message and/or state.

The payload type for the Hash Payload is eight (8).

Hash Payload Processing: When creating a Hash Payload, the transmitting entity (initiator) must determine the Hash

function to be used as defined by the SA negotiation, determine the usage of the Hash Data field as

defined by the DOI, construct a Hash payload, and then transmit the message to the receiving entity

(responder).

When a Hash Payload is received, the receiving entity (responder) must determine if the

Hash is supported. If the Hash determination fails, the message is discarded. The responder also

performs the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the

Hash function fails, the message is discarded.


VIGNESH.L.S AP/CSE

Signature Payload The Signature Payload contains data generated by the digital signature function, over some

part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in

the ISAKMP message, and may be of use for non-repudiation services.

The Signature Payload fields are defined as follows:



The Reserved field (8 bits) is not used, but set to 0.


payload header.

The Signature Data field (variable length) is the data that results from applying the digital signature

function to the ISAKMP message and/or state.

The payload type for the Signature Payload is nine (9).

Signature Payload Processing: When a Signature Payload is created, the transmitting entity(initiator) must determine the

Signature function to be used as defined by the SA negotiation, determine the usage of the

Signature Data filed as defined by the DOI, construct a Signature payload, and finally transmit the

message to the receiving entity (responder).

When a Signature payload is received, the receiving entity must determine if the Signature is

supported. If the Signature determination fails, the message is discarded. The responder must

perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If

the Signature function fails, the message is discarded.

Nonce Payload

The Nonce Payload contains random data used to guarantee liveness during an exchange

and protect against replay attacks. If nonce are used by a particular key exchange, the use of the

Nonce Payload will be dictated by the key exchange.

The Nonce Payload fields are defined as follows:



The Reserved field (8 bits) is unused, but set to 0.


payload header.

The Nonce Data field (variable length) contains the random data generated by the transmitting

entity.

The Payload type for the Nonce Payload is ten (10).

Nonce Payload Processing: When creating a Nonce Payload, the transmitting entity (initiator) must create an unique

random values to be used as a nonce, construct a Nonce payload, and transmit the message to the

receiving entity.

When a Nonce Payload is received, the receiving entity (responder) must do as follows:

There are no specific procedures for handling Nonce payloads. The procedures are defined

by the exchange types and possibly the DOI and Key Exchange descriptions.

Notification Payload

The Notification Payload can contain both ISAKMP and DOI-specific data and is used to

transmit information data, such as error conditions to an ISAKMP peer. It is possible to send multiple

Notification Payloads in a single ISAKMP message.

The Notification Payload fields are defined as follows:


VIGNESH.L.S AP/CSE





payload header.

The Domain of Interpretation field (32 bits) identifies the DOI under which this notification is taking

place. For ISAKMP this value is zero (0) and for the IPsec DOI it is one (1).

The Protocol-id field (8 bits) specifies the protocol identifier for the current notification.

The SPI Size field (8 bits) is the length in octets of the SPI as defined by the protocol id.

The Notify Message Type field (16 bits) specifies the type of notification message. Additional text, if

specified by the DOI, is placed in the Notification Data field.

The Security Parameter Index (SPI) field has the variable length.

The Notification Data field (variable length) is informational or error data transmitted in addition to

the Notify Message Type. Values for this field are DOI-specific.

The payload type for the Notification Payload is eleven (11).

Notification Payload Processing: When a Notification Payload is created, the transmitting entity (initiator) must determine

the DOI for this Notification, determine the Protocol-ID for this Notification, determine the SPI size

based on the Protocol-ID field, determine the Notify Message Type based on the error or status

message desired, determine the SPI which is associated with this notification, determine if additional

Notification Data is to be included, construct a Notification Payload, and finally transmit the

messages to the receiving entity.

When a Notification payload is received, the receiving entity (responder) must determine if

the Informational Exchange has any protection applied to it by checking the Encryption Bit and

Authentication Only Bit in the ISAKMP Header, determine if the Domain of Interpretation (DOI) is

supported, determine if the protocol-ID is supported, determine if the SPI is valid, determine if the

Notify Message Type is valid, and then process the Notification payload, including additional

Notification Data, and take appropriate action according to local security policy.

Delete Payload

The Delete Payload contains a protocol-specific security association identifier that the

sender has removed from its SA database. Therefore, the sender is no longer valid. It is possible to

send multiple SPIs in a Delete Payload. But each SPI must be for the same protocol.

The Delete Payload fields are defined as follows:





payload header.

The Domain of Interpretation field (32 bits) identifies the DOI under which this deletion is taking

place. For ISAKMP this value is zero(0) and for the IPsec DOI it is one (1).

The Protocol-id field (8 bits) specifies that ISAKMP can establish SAs for various protocols, including

ISAKMP and IPsec.

The SPI Size field (8 bits) is the length in octets of the SPI as defined by the Protocol-id.

The # of SPIs field (16 bits) is the number of SPIs contained in the Delete Payload. The size of each

SPI is defined by the SPI Size field.

The Security Parameter Indexes field (variable length) identifies the specific security associations to

delete.

The Payload type for the Delete Payload is twelve (12).


VIGNESH.L.S AP/CSE

Delete Payload Processing: When a Delete Payload is created, the transmitting entity (initiator) must determine the DOI

for this Deletion, determine the Protocol-ID for this Deletion, determine the SPI size based on the

Protocol-id field, determine the # of SPIs to be deleted for this protocol, determine the SPI(s) which

is (are) associated with this deletion, construct a Delete payload, and then transmit the message to

the receiving entity.

When a Delete payload is received, the receiving entity (responder) must do as follows:

∑ Since the Information Exchange is protected by authentication for an Auth-Only SA and

encryption for other exchange, the message must have these security services applied using

the ISAKMP SA. Any errors that occur during the Security Service processing will be evident

when checking information in the Delete payload.

∑ Determine if the Domain of Interpretation (DOI) is supported.

∑ Delete if the Protocol-ID is supported.

∑ Determine if the SPI is valid for each SPI included in the Delete payload.

∑ Process the Delete payload and take appropriate action, according to local security policy.

Vendor ID Payload The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to

identify and recognize remote instances of their implementations.

The Vendor ID Payload fields are defined as follows:





payload header.

The Vendor ID field (variable length) contains the choice of hash and text to hash. Vendors could

generate their vendor-id by taking a keyless hash of a string containing the product name, and the

version of the product.

The Payload type for the Vendor ID Payload is thirteen (13).


VIGNESH.L.S AP/CSE

UNIT II E-MAIL SECURITY & FIREWALLS

PGP - S/MIME - Internet Firewalls for Trusted System: Roles of Firewalls – Firewall related

terminology- Types of Firewalls - Firewall designs - SET for E-Commerce Transactions.

What is PGP? Explain in detail confidentiality is achieved using PGP via encryption.

Pretty Good Privacy (PGP) was invented by Philip Zimmermann who released version 1.0 in 1991.

PGP uses a combination of symmetric secret-key and asymmetric public-key encryption to provide

security services for electronic mail and data files. It also provides data integrity services for messages

and data files by using digital signature, encryption, compression (zip) and radix-64 conversion

(ASCII Armor).

Confidentiality via Encryption

PGP provides confidentiality by encrypting messages to be transmitted or data files to be stored locally using a conventional encryption algorithm such as IDEA, 3DES or CAST- 128. In PGP,

each symmetric key, known as a session key, is used only once. A new session key is generated as a

random 128-bit number for each message and is bound to be transmitted only once. The sequence of

encryption is shown in the following figure:

∑ The sender creates a message.

∑ The sending PGP generates a random 128-bit number to be used as a session key for this

message only.

∑ The session key is encrypted with RSA, using the recipient‘s public key.

∑ The sending PGP encrypts the message, using CAST-128 or IDEA or 3DES, with the session

key. Note that the message is also usually compressed.

∑ The receiving PGP uses RSA with its private key to decrypt and recover the session key.

∑ The receiving PGP decrypts the message using the session key. If the message was

compressed, it will be decompressed. PGP should provide the user with a range of key size options from 768 to 3072 bits. Both digital signature and confidentiality services may be applied to the same message. First, a signature is


VIGNESH.L.S AP/CSE

generated from the message and attached to the message. Then the message plus signature are

encrypted using a symmetric session key. Finally, the session key is encrypted using public-key

encryption and prefixed to the encrypted block.

Explain the process of Authentication via Digital Signature in PGP.

The digital signature uses a hash code of the message digest algorithm, and a public-key

signature algorithm. The sequence is as follows:

∑ The sender creates a message.

∑ SHA-1 is used to generate a 160-bit hash code of the message.

∑ The hash code is encrypted with RSA using the sender‘s private key and a digital signature is

produced.

∑ The binary signature is attached to the message.

∑ The receiver uses RSA with the sender‘s public key to decrypt and recover the hash code.

∑ The receiver generates a new hash code for the received message and compares it with the

decrypted hash code. If the two match, the message is accepted as authentic.

The combination of SHA-1 and RSA provides an effective digital signature scheme. As an alternative,

signatures can be generated using DSS/SHA-1. The DSS uses an algorithm that is designed to provide

only the digital signature function. Although DSS is a public-key technique, it cannot be used for

encryption or key exchange.

Illustrate the process of Compression and Radix 64 conversions using PGP with suitable examples.

As a default, PGP compresses the message after applying the signature but before encryption.

This compression algorithm has the benefit of saving space both for e-mail transmission and for file

storage. In confidentiality via encryption, message encryption is applied after compression to

strengthen cryptographic security. In reality, cryptanalysis will be more difficult because the

compressed message has less redundancy than the original message. In case of Authentication,

signing an uncompressed original message is preferable because the uncompressed message together

with the signature is directly used for future verification. On the other hand, for a compressed

message, one may consider two cases, either to store a compressed message for later verification or to

recompress the message when verification is required.

PGP makes use of a compression package called ZIP which is functionally equivalent to

PKZIP developed by PKWARE, Inc. The zip algorithm is perhaps the most commonly used cross-

platform compression technique. Two main compression schemes, named after Abraham Lempel and

Jakob Ziv, were first proposed by them in 1977 and 1978, respectively. These two schemes for text

compression (generally referred to as lossless compression) are broadly used because they are easy to

implement and also fast. In 1982 James Storer and Thomas Szymanski presented their scheme, LZSS,

based on the work of Lempel and Ziv. In LZSS, the compressor maintains a window of size N bytes


VIGNESH.L.S AP/CSE

and a lookahead buffer. Sliding-window-based schemes can be simplified by numbering the input text characters mod N, in effect creating a circular buffer.

Recently an algorithm was developed which combines the idea behind LZ77 and LZ78 to

produce a hybrid called LZFG. LZFG uses the standard sliding window, but stores the data in a

modified tree data structure and produces as output the position of the text in the tree. Since LZFG

only inserts complete phrases into the dictionary, it should run faster than other LZ77-based

compressors. Huffman compression is a statistical data compression technique which reduces the

average code length used to represent the symbols of an alphabet. Decompression of LZ77-

compressed text is simple and fast. Whenever a (position, length) pair is encountered, one goes to that

position in that window and copies length bytes to the output.

Radix 64 Conversion:

When PGP is used, usually part of the block to be transmitted is encrypted. If only the signature service is used, then the message digest is encrypted (with the sender‘s private key). If the

confidentiality service is used, the message plus signature (if present) are encrypted (with a one-time

symmetric key). Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets.

Therefore, to transport PGP‘s raw binary octets through unreliable channels, a printable encoding of

these binary octets is needed. The scheme used for this purpose is radix-64 conversion. Each group of

three octets of binary data is mapped into four ASCII characters. This format also appends a CRC to

detect transmission errors. This radix-64 conversion is a wrapper around the binary PGP messages,

and is used to protect the binary messages during transmission over non-binary channels, such as

Internet e-mail.

The character set consists of the upper- and lower-case letters, the digits 0–9, and the characters ‗+‘

and ‗/‘. The ‗=‘ character is used as the padding character. The hyphen ‗-‘ character is not used. Thus,

a PGP text file resulting from ASCII characters will be immune to the modifications inflicted by mail

systems.

ASCII Armor Format

When PGP encodes data into ASCII Armor, it puts specific headers around the data, so PGP

can construct the data later. PGP informs the user about what kind of data is encoded in ASCII Armor

through the use of the headers. Concatenating the following data creates ASCII Armor: an Armor

head line, Armor headers, a blank line, ASCII-Armored data, Armor checksum and Armor tail.


VIGNESH.L.S AP/CSE

An Armor head line: This consists of the appropriate header line text surrounded by five dashes (‗-‘, 0x2D) on either side of the header line text. Armor headers: The Armor headers are a part of the armour, not a part of the message, and hence are

not protected by any signatures applied to the message. The format of an Armor header is that of a

(key, value) pair. A colon (‗:‘ 0x38) and a single space (0x20) separate the key and value. PGP should

consider improperly formatted Armor headers to be corruptions of ASCII Armor. Currently defined

Armor header keys include: Version, Comment, MessageID, Hash, Char Set.

A blank line: This indicates zero length or contains only white space. ASCII-Armoured data: An arbitrary file is converted to ASCII-Armoured data. Armor checksum: This is a 24-bit CRC converted to four characters of radix-64 encoding by the same MIME base 64 transformation, preceded by an equals sign (=). Armor tail : The Armor tail line is composed in the same manner as the Armor header line, except the string ‗BEGIN‘ is replaced by the string ‗END‘.

Encoding Binary in Radix-64

The encoding process represents three 8-bit input groups as output strings of four encoded characters. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single character in the radix-64 alphabet. Each 6-bit group is used as an index. The character referenced by the index is placed in the output string. There are three possibilities:

1. The last data group has 24 bits (three octets). No special processing is needed. 2. The last data group has 16 bits (two octets). The first two 6-bit groups are processed as above. The third (incomplete) data group has two zero-value bits added to it, and is processed as above. A pad character (=) is added to the output. 3. The last data group has 8 bits (one octet). The first 6-bit group is processed as above. The second (incomplete) data group has four zero-value bits added to it, and is processed as above. Two pad characters (=) are added to the output. The Radix 64 encoding is shown below:

Explain the PGP packet format and PGP packet headers with suitable diagrams.

A PGP message is constructed from a number of packets. A packet is a chunk of data which

has a tag specifying its meaning. Each packet consists of a packet header of variable length, followed

by the packet body. The first octet of the packet header is called the packet tag. The MSB is ‗bit 7‘

(the leftmost bit) whose mask is 0x80 (10000000) in hexadecimal. PGP 2.6.x only uses old format

packets.


VIGNESH.L.S AP/CSE

2–Signature packet, 3–Session key packet encrypted by symmetric key, 4–One-pass signature packet, 5–Secret-key packet, 6–Public-key packet, 7–Secret-subkey packet, 8–Compressed data packet, 9– Symmetrically encrypted data packet, 10–Marker packet, 11–Literal data packet, 12–Trust packet, 13–User ID packet, 14–Public subkey packet, 60 ∼ 63–Private or experimental values.

Old-Format Packet Lengths The meaning of the length type in old-format packets is: 0–The packet has a one-octet length. The header is two octets long. 1–The packet has a two-octet length. The header is three octets long. 2–The packet has a four-octet length. The header is five octets long. 3–The packet is of indeterminate length.

New-Format Packet Lengths New-format packets have four possible ways of encoding length: One-octet lengths: A one-octet body length header encodes packet lengths from 0 to 191 octets. bodyLen = 1st octet. Two-octet lengths: A two-octet body length header encodes a length from 192 to 8383 octets. It is recognised because its first octet is in the range 192 to 223. bodyLen = ((1st octet − 192) _ 8) + (2nd octet) + 192 • Five-octet lengths: A five-octet body length header encodes packet lengths of up to 4 294 967 295 (0xffffffff) octets in length. bodyLen = (2nd octet _ 24)|(3rd octet _ 16)|(4th octet _ 8)|5th octet Partial body lengths: A partial body length header is one octet long and encodes the length of only part of the data packet. This length is a power of 2, from 1 to 1 073 741 824 (2 to the 30th power). partialBodyLen = 1 _ (1st octet & 0x1f). Each partial body length header is followed by a portion of the packet body data. The header specifies this portion‘s length.

PGP Packet Structure

A PGP file consists of a message packet, a signature packet and a session key packet.

Message Packet This packet includes the actual data to be transmitted or stored as well as a header that includes control information generated by PGP such as a filename and a timestamp. The message component consists of a single literal data packet.

Signature Packet (Tag 2) This packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a user ID.

Two versions of signature packets are defined. PGP 2.6.x only accepts version 3 signature. Version 3

provides basic signature information, while version 4 provides an expandable format with subpackets

that can specify more information about the signature. The signature includes the following components: • Timestamp: This is the time at which the signature was created.


VIGNESH.L.S AP/CSE

• Message digest (or hash code): A hash code represents the 160-bit SHA-1 digest, encrypted with

sender a‘s private key. The hash code is calculated over the signature timestamp concatenated with

the data portion of the message component. The inclusion of the signature timestamp in the digest

protects against replay attacks. If the default option of compression is chosen, then the block consisting of the literal data packet and the signature packet is compressed to form a compressed data packet: • Leading two octets of hash code: These enable the recipient to determine if the correct public key was used to decrypt the hash code for authentication, by comparing the plaintext copy of the first two

octets with the first two octets of the decrypted digest. Two octets also serve as a 16-bit frame-check

sequence for the message. • Key ID of sender’s public key: This identifies the public key that should be used to decrypt the hash code and hence identifies the private key that was used to encrypt the hash code. Session Key Packets (Tag 1) This component includes the session key and the identifier of the receiver‘s public key that was used by the sender to encrypt the session key. A public-key-encrypted session key packet, EKPb (Ks), holds the session key used to encrypt a message. The symmetrically encrypted data packets are preceded by one public-key-encrypted session key packet for each PGP 5.x key to which the message

is encrypted. The message is encrypted with the session key, and the session key is itself encrypted

and stored in the encrypted session key packet. The recipient of the message finds a session key that is

encrypted to its public key, decrypts the session key, and then uses the session key to decrypt the

message.

The body of this session key component consists of: • A one-octet version number which is 3. • An eight-octet key ID of the public key that the session key is encrypted to. • A one-octet number giving the public key algorithm used. • A string of octets that is the encrypted session key. The PGP message format is shown below:

Key Material Packet

A key material packet contains all the information about a public or private key. There are

four variants of this packet type and two versions.


VIGNESH.L.S AP/CSE

Public-key packet (tag 6): This packet starts a series of packets that forms a PGP 5.x key. Public subkey packet (tag 14): This packet has exactly the same format as a publickey packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. The top-level key provides signature services, and the subkeys provide encryption services. Secret-key packet (tag 5): This packet contains all the information that is found in a public-key packet, including the public-key materials, but also includes the secret-key material after all the public-key fields. Secret-subkey packet (tag 7): A secret-subkey packet is the subkey analogous to the secret-key packet and has exactly the same format. Public-key Packet Formats There are two variants of version 3 packets and version 2 packets. Version 3 packets were originally generated by PGP 2.6. Version 2 packets are identical in format to version 3 packets, but are generated by PGP 2.5. PGP 5.0 introduced version 4 packets, with new fields and semantics. A v3 key packet contains: A one-octet version number (3). A four-octet number denoting the time that the key was created. A two-octet number denoting the time in days that this key is valid. A one-octet number denoting the public-key algorithm of this key. A series of multiprecision integers (MPIs) comprising the key material: an MPI of RSA public module n; an MPI of RSA public encryption exponent e. A key ID is an eight-octet scalar that

identifies a key. For a v3 key, the eight-octet key ID consists of the low 64 bits of the public modulus

of the RSA key.

Secret-key Packet Formats The secret-key and secret-subkey packets contain all the data of public-key and public subkey packets in encrypted form, with additional algorithm-specific key data appended. The secret-key packet contains: • A public-key or public-subkey packet, as described above. • One octet indicating string-to-key (S2K) usage conventions: 0 indicates that the secretkey data is not encrypted; 255 indicates that an S2K specifier is being given. Any other value specifies a symmetric- key encryption algorithm. • If the S2K usage octet was 255, a one-octet symmetric encryption algorithm (optional). • If the S2K usage octet was 255, an S2K specifier (optional). The length of the S2K specifier is implied by its type, as described above. • If secret data is encrypted, an eight-octet IV (optional). • Encrypted MPIs comprising the secret-key data. These algorithm-specific fields are as described below. • A two-octet checksum of the plaintext of the algorithm-specific portion. Besides simple S2K, there are two more S2K specifiers currently supported: Salted S2K : This includes a salt value in the simple S2K specifier that hashes the passphrase to help prevent dictionary attacks Iterated and salted S2K : This includes both a salt and octet count. The salt is combined with the passphrase and the resulting value is hashed repeatedly. Iterated–salted S2K hashes the passphrase and salt data multiple times. The total number of octets to be hashed is given in the encoded count in the S2K specifier.

What is S/MIME?

Secure/Multipurpose Internet Mail Extension (S/MIME) provides a consistent means to send

and receive secure MIME data. S/MIME, based on the Internet MIME standard, is a security

enhancement to cryptographic electronic messaging. Further, S/MIME not only is restricted to e-mail,

but can be used with any transport mechanism that carries MIME data, such as HTTP. S/MIME takes

advantage of allowing secure messages to be exchanged in mixed-transport systems.


VIGNESH.L.S AP/CSE

What is MIME? Explain the header format of MIME and various functions with suitable

diagram.

MIME was defined to allow transmission of non-ASCII data through e-mail. MIME allows

arbitrary data to be encoded in ASCII and then transmitted in a standard e-mail message. It is a

supplementary protocol that allows non-ASCII data to be sent through SMTP. MIME is not a mail

protocol and cannot replace SMTP; it is only an extension to SMTP. The MIME standard provides a

general structure for the content type of Internet messages and allows extensions for new content-type

applications. The MIME standard specifies that a content-type declaration must contain two

identifiers, a content type and a subtype, separated by a slash.

MIME Description

MIME transforms non-ASCII data at the sender‘s site to NVT ASCII data and delivers it to the client

SMTP to be sent through the Internet. The server SMTP at the receiver‘s site receives the NVT ASCII

data and delivers it to MIME to be transformed back to the original non-ASCII data.

MIME Header MIME defines five headers that can be added to the original SMTP header section:

MIME Version Content Type Content Transfer Encoding Content Id Content Description

MIME Version This header defines the version of MIME used. The current version is 1.0.

Content Type This header defines the type of data used in the message body. The content type and the content subtype are separated by a slash. MIME allows seven different types of data: Text, Multipart, Image, Message, Video, Audio and Application.

Content Transfer Encoding This header defines the method to encode the messages into ones and zeros for transport. There are the five types of encoding: 7 bit, 8 bit, binary, Base64 and Quoted-printable.


VIGNESH.L.S AP/CSE

Content Id This header uniquely identifies the whole message in a multiple message environment: Content Id: id = <content id>

Content Description This header defines whether the body is image, audio or video: Content Description: <description>

MIME Security Multiparts

An Internet e-mail message consists of two parts: the headers and the body. The headers form

a collection of field/value pairs, while the body is defined according to the MIMEformat. The basic

MIME by itself does not specify security protection. Accordingly, a MIME agent must provide

security services by employing a security protocol mechanism, by defining two security subtypes of

the MIME multipart content type: signed and encrypted. The type and contents of the control

information body parts are determined by the value of the protocol parameter of the enclosing

multipart/signed or multipart/encrypted content type. A MIME agent should be able to recognise a

security multipart body part and to identify its protected data and control information body part.

The multipart/signed content type specifies how to support authentication and integrity

services via digital signature. The multipart/singed content type contains exactly two body parts. The

first body part is the one over which the digital signature was created, including its MIME headers.

The second body part contains the control information necessary to verify the digital signature. The

multipart/encrypted content type specifies how to support confidentiality via encryption. The

multipart/encrypted content type contains exactly two body parts. The first body part contains the

control information necessary to decrypt the data in the second body part. The second body part

contains the data which was encrypted and is always labeled application/octet-stream.

MIME Security with OpenPGP

The integrating work on PGP with MIME suffered from a number of problems, the most

significant of which was the inability to recover signed message bodies without parsing data

structures specific to PGP. PGP can generate either ASCII Armor or a stream of arbitrary 8-bit octets

when encrypting data, generating a digital signature, or extracting public-key data. The ASCII Armor

output is the required method for data transfer. When the data is to be transmitted in many parts, the

MIME message/partial mechanism should be used rather than the multipart ASCII Armor OpenPGP

format.

The multipart/encrypted MIME body must consist of exactly two body parts, the first with

content type ‗application/pgp-encrypted‘. This body contains the control information. The second

MIME body part must contain the actual encrypted data. It must be labelled with a content type of ‗application/octet-stream‘. The multipart/signed body must consist of exactly two parts. The first part


VIGNESH.L.S AP/CSE

contains the signed data in MIME canonical format, including a set of appropriate content headers

describing the data. The second part must contain the OpenPGP digital signature. It must be labelled

with a content type of ‗application/pgpsignature‘.

This encrypted and signed data protocol allows for two ways of accomplishing this task:

The data is first signed as a multipart/signature body, and then encrypted to form the final multipart/encrypted body. This is most useful for standard MIME-compliant message forwarding. The OpenPGP packet format describes a method for signing and encrypting data in a single OpenPGP message. This method is allowed in order to reduce processing overheads and increase compatibility with non-MIME implementations of OpenPGP. The resulting data is formatted as a ‗multipart/encrypted‘ object. Messages which are encrypted and signed in this combined fashion are required to follow the same canonicalisation rules as multipart/singed object.

What is a Firewall? List down the roles of firewall.

-A firewall is hardware or software (or a combination of hardware and software) that monitors the

transmission of packets of digital information that attempt to pass through the perimeter of a

network.

-A firewall is simply a program or hardware device that filters the information coming through the

Internet connection into your private network or computer system. If an incoming packet of

information is flagged by the filters, it is not allowed through. Firewalls act as an intermediate server

in handling SMTP and HTTP connections in either direction. Firewalls also require the use of an

access negotiation and encapsulation protocol such as SOCKS to gain access to the Internet, the

intranet, or both.

Role of Firewalls

The firewall imposes restrictions on packets entering or leaving the private network. All

traffic from inside to outside, and vice versa, must pass through the firewall, but only authorised

traffic will be allowed to pass. The firewall itself must be immune to penetration. Firewalls create

checkpoints (or choke points) between an internal private network and an untrusted Internet. Once the

choke points have been clearly established, the device can monitor, filter and verify all inbound and

outbound traffic.

The firewall may filter on the basis of IP source and destination addresses and TCP port

number. The means by which access is controlled relate to using network layer or transport layer

criteria such as IP subnet or TCP port number, but there is no reason that this must always be so. A

growing number of firewalls control access at the application layer, using user identification as the

criterion. In addition, firewalls for ATM networks may control access based on the data link layer

criteria.

Firewalls may block TELNET or RLOGIN connections from the Internet to the intranet. They

also block SMTP and FTP connections to the Internet from internal systems not authorised to send e-

mail or to move files. The firewall provides protection from various kinds of IP spoofing and routing

attacks. It can also serve as the platform for IPsec. Using the tunnel mode capability, the firewall can

be used to implement Virtual Private Networks (VPNs). A VPN encapsulates all the encrypted data

within an IP packet.

The firewall certainly has some negative aspects: it cannot protect against internal threats

such as an employee who cooperates with an external attacker; it is also unable to protect against the

transfer of virus-infected programs or files because it is impossible for it to scan all incoming files, e-

mail and messages for viruses.

Explain the various firewall related terminologies in detail.

Firewall-Related Terminology

Bastion Host A bastion host is a publicly accessible device for the network‘s security, which has a direct


VIGNESH.L.S AP/CSE

connection to a public network such as the Internet. The bastion host serves as a platform for any one

of the three types of firewalls: packet filter, circuit-level gateway or application-level gateway. They

should be built with the least amount of hardware and software in order for a potential hacker to have

less opportunity to overcome the firewall. Bastion hosts are armed with logging and alarm features to

prevent attacks. The bastion host‘s role falls into the following three common types:

Single-homed bastion host: This is a device with only one network interface, normally used for an

application-level gateway. The external router is configured to send all incoming data to the bastion

host, and all internal clients are configured to send all outgoing data to the host.

Dual-homed bastion host: This is a firewall device with at least two network interfaces. Dual-homed

bastion hosts serve as application-level gateways, and as packet filters and circuit-level gateways as

well. The advantage of using such hosts is that they create a complete break between the external

network and the internal network. Multihomed bastion host: Single-purpose or internal bastion hosts can be classified as either single- homed or multihomed bastion hosts. The latter are used to allow the user to enforce strict security mechanisms. When the security policy requires all inbound and outbound traffic to be sent through a proxy server, a new proxy server should be created for the new streaming application. They provide an additional level of security in case the external firewall devices are compromised. All the internal network devices are configured to communicate only with the internal bastion host.

A tri-homed firewall connects three network segments with different network addresses. This firewall

may offer some security advantages over firewalls with two interfaces. An attacker on the unprotected

Internet may compromise hosts on the DMZ but still not reach any hosts on the protected internal

network.

Proxy Server

Proxy servers are used to communicate with external servers on behalf of internal clients. A proxy service is set up and torn down in response to a client request, rather than existing on a static basis. The term proxy server typically refers to an application-level gateway, although a circuit-level gateway is also a form of proxy server. Application proxies forward packets only when a connection has been established using some known protocol. When the connection closes, a firewall using application proxies rejects individual packets, even if they contain port numbers allowed by a rule set. In contrast, circuit proxies always forward packets containing a given port number if that port number is permitted by the rule set.

The audit log is an essential tool for detecting and terminating intruder attacks. Therefore,

each proxy maintains detailed audit information by logging all traffic, each connection and the

duration of each connection. Since a proxy module is a relatively small software package specifically

designed for network security, it is easier to check such modules for security flaws. Each proxy is

independent of other proxies on the bastion host. If there is a problem with the operation of any proxy,

or if future vulnerability is discovered, it is easy to replace the proxy without affecting the operation

of the proxy‘s applications. A proxy generally performs no disk access other than to read its initial

configuration file. This makes it difficult for an intruder to install Trojan horse sniffers or other

dangerous files on the bastion host.

SOCKS

The SOCKS protocol version 4 provides for unsecured firewall traversal for TCP-based client/server applications, including HTTP, TELNET and FTP. The new protocol extends the SOCKS version 4 model to include UDP, and allows the framework to include provision for generalised strong authentication schemes, and extends the addressing scheme to encompass domain name and IPv6 addresses. When a TCP-based client wishes to establish a connection to an object that is reachable only via a firewall, it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system.


VIGNESH.L.S AP/CSE

The SOCKS service is conventionally located at TCP port 1080. If the connection request

succeeds, the client enters negotiation for the authentication method to be used, authenticates with the

chosen method, and then sends a relay request. Since the Internet at large is considered a hostile

medium, encryption by using ESP is also assumed in this scenario. An ESP transform that provides

both authentication and encryption could be used, in which case the AH need not be included.

Choke Point

The most important aspect of firewall placement is to create choke points. A choke point is

the point at which a public internet can access the internal network. The most comprehensive and

extensive monitoring tools should be configured on the choke points. Proper implementation requires

that all traffic be funnelled through these choke points. Once these choke points have been clearly

established, the firewall devices can monitor, filter and verify all inbound and outbound traffic. Since a choke point is installed at the firewall, a prospective hacker will go through the choke point. If the most comprehensive logging devices are installed in the firewall itself, all hacker activities can be captured. Hence, this will detect exactly what a hacker is doing.

De-militarised Zone (DMZ)

The DMZ is an expression that originates from the Korean War. It meant a strip of land

forcibly kept clear of enemy soldiers. In terms of a firewall, the DMZ is a network that lies between

an internal private network and the external public network. DMZ networks are sometimes called

perimeter networks. A DMZ is used as an additional buffer to further separate the public network

from the internal network. Many firewalls support tri-homing, allowing use of a DMZ network. It is

possible for a firewall to accommodate more than three interfaces, each attached to a different

network segment.

Logging and Alarms

Logging is usually implemented at every device in the firewall, but these individual logs

combine to become the entire record of user activity. Packet filters normally do not enable logging by

default so as not to degrade performance. Packet filters as well as circuit-level gateways log only the

most basic information. The audit log is an essential tool for detecting and terminating intruder

attacks. Many firewalls allow the user to preconfigure responses to unacceptable activities. The

firewall should alert the user by several means. The two most common actions are for the firewall to

break the TCP/IP connection, or to have it automatically set off alarms.

VPN VPNs are appropriate for any organisation requiring secure external access to internal

resources. All VPNs are tunnelling protocols in the sense that their information packets or payloads

are encapsulated or tunnelled into the network packets. All data transmitted over a VPN is usually

encrypted because an opponent with access to the Internet could eavesdrop on the data as it travels

over the public network. Several methods exist to implement a VPN. Windows NT or later versions

support a standard RSA connection through a VPN. Specialised firewalls or routers can be configured

to establish a VPN over the Internet. New protocols such as IPsec are expected to standardise on a

specific VPN solution. Several VPN protocols exist, but the Point-to-Point Tunnelling Protocol

(PPTP) and IPsec are the most popular.

Explain the types of firewalls with suitable illustrations. Firewalls are classified into three common types: packet filters, circuit-level gateways and application-level gateways.

Packet Filters

Packet filters are one of several different types of firewalls that process network traffic on a packet-by-packet basis. A packet filter‘s main function is to filter traffic from a remote IP host, so a


VIGNESH.L.S AP/CSE

router is needed to connect the internal network to the Internet. A packet filter is a device which

inspects or filters each packet at a screening router for the content of IP packets. The screening router

is configured to filter packets from entering or leaving the internal network.

Packet filters typically set up a list of rules that are sequentially read line by line. Filtering

rules can be applied based on source and destination IP addresses or network addresses, and TCP or

UDP ports. Packet filters are read and then treated on a rule-by-rule basis. A packet filter will provide

two actions, forward or discard. A packet filter is a device that inspects each packet for predefined

content. Although it does not provide an error-correcting ability, it is almost always the first line of

defence. When packets are filtered at the external filter, it is usually called a screening router.

However, the significant weakness with packet filters is that they cannot discriminate between

good and bad packets. Even if a packet passes all the rules and is routed to the destination, packet

filters cannot tell whether the routed packet contains good or malicious data. Another weakness of

packet filters is their susceptibility to spoofing. In IP spoofing, an attacker sends packets with an

incorrect source address.

Packet-Filtering Rules

A packet filter applies a set of rules to each incoming IP packet and then forwards or discards

the packet. The packet filter typically sets up a list of rules which may match fields in the IP or TCP

header. If there is a match to one of the rules, that rule is able to determine whether to forward or

discard the packet. If there is no match to any rule, then two default actions (forward and discard) will

be taken.


VIGNESH.L.S AP/CSE

Proxies are classified into two basic forms:

w Circuit-level gateway

w Application-level gateway

Both circuit and application gateways create a complete break between the internal premises network

and external Internet. This break allows the firewall system to examine everything before passing it

into or out of the internal network.

Circuit-Level Gateways

The circuit-level gateway represents a proxy server that statically defines what traffic will be

forwarded. Circuit proxies always forward packets containing a given port number if that port number

is permitted by the rule set. A circuit-leval gateway operates at the network level of the OSI model.

This gateway acts as an IP address translator between the Internet and the internal system.

The main advantage of a proxy server is its ability to provide Network Address Translation

(NAT). NAT hides the internal IP address from the Internet. Circuit-level gateways are based on the

same principles as packet filter firewalls. When the internal system sends out a series of packets, these

packets appear at the circuit-level gateway where they are checked against the predetermined rules

set. If the packets do not violate any rules, the gateway sends out the same packets on behalf of the

internal system.

Application-Level Gateways

The application-level gateway represents a proxy server, performing at the TCP/IP

application level, that is set up and torn down in response to a client request, rather than existing on a

static basis. Application proxies forward packets only when a connection has been established using

some known protocol. When the connection closes, a firewall using application proxies rejects

individual packets, even if the packets contain port numbers allowed by a rule set. The application

gateway analyses the entire message instead of individual packets when sending or receiving data.


VIGNESH.L.S AP/CSE

The main advantage of a proxy server is its ability to provide NAT for shielding the internal

network from the Internet.

Explain the various designs of Firewall with suitable diagrams.

The primary step in designing a secure firewall is obviously to prevent the firewall devices

from being compromised by threats. To provide a certain level of security, the three basic firewall

designs are considered: a single-homed bastion host, a dual-homed bastion host and a screened subnet

firewall. The first two options are for creating a screened host firewall, and the third option contains

an additional packet-filtering router to achieve another level of security. A bastion host is a publicly

accessible device. When Internet users attempt to access resources on the Internet network, the first

device they encounter is a bastion host. Fewer running services on the bastion host will give a

potential hacker less opportunity to overcome the firewall.

Screened Host Firewall (Single-Homed Bastion Host)

Single-homed bastion hosts can be configured as either circuit-level or application-level

gateways. When using either of these two gateways, each of which is called a proxy server, the

bastion host can hide the configuration of the internal network. The screened host firewall is designed

such that all incoming and outgoing information is passed through the bastion host. The external

screening router is configured to route all incoming traffic directly to the bastion host.

The screening router is also configured to route outgoing traffic only if it originates from the

bastion host. This kind of configuration prevents internal clients from bypassing the bastion host.

Thus, the bastion host is configured to restrict unacceptable traffic and proxy acceptable traffic. A

single-homed implementation may allow a hacker to modify the router not to forward packets to the

bastion host.

Screened Host Firewall (Dual-Homed Bastion Host)


VIGNESH.L.S AP/CSE

The configuration of the screened host firewall using a dual-homed bastion host adds significant security, compared with a single-homed bastion host. A dual-homed bastion host has two


VIGNESH.L.S AP/CSE

network interfaces. This firewall implementation is secure due to the fact that it creates a complete

break between the internal network and the external Internet. As with the single-homed bastion, all

external traffic is forwarded directly to the bastion host for processing. However, a hacker may try to

subvert the bastion host and the router to bypass the firewall mechanisms. Nevertheless, a dual-homed

bastion host removes even this possibility. It is also possible to implement NAT for dual-homed

bastion hosts.

Screened Subnet Firewall

The third implementation of a firewall is the screened subnet, which is also known as a DMZ.

This firewall is the most secure one among the three implementations, simply because it uses a

bastion host to support both circuit- and application-level gateways. This DMZ then function as a

small isolated network positioned between the Internet and the internal network. The screened subnet

firewall contains external and internal screening routers. Each is configured such that its traffic flows

only to or from the bastion host. This arrangement prevents any traffic from directly traversing the

DMZ subnetwork.

This router also uses filters to prevent attacks such as IP spoofing and source routing. The

internal screening router also uses rules to prevent spoofing and source routing. The benefits of the

screened subnet firewall are based on the following facts. First, a hacker must subvert three separate

tri-homed interfaces when he or she wants to access the internal network. But it is almost infeasible.

Second, the internal network is effectively invisible to the Internet because all inbound/outbound

packets go directly through the DMZ. Third, internal users cannot access the Internet without going

through the bastion host because the routing information is contained within the network.


VIGNESH.L.S AP/CSE

Define SET.

The Secure Electronic Transaction (SET) is a protocol designed for protecting credit card

transactions over the Internet. It is an industry-backed standard that was formed by MasterCard and

Visa (acting as the governing body) in February 1996. SET relies on cryptography and X.509 v3

digital certificates to ensure message confidentiality and security. SET is the only Internet transaction

protocol to provide security through authentication.

What are the business requirements for SET?

Confidentiality of information (provide confidentiality of payment and order information): To meet

these needs, the SET protocol uses encryption. Confidentiality reduces the risk of fraud by either party

to the transaction or by malicious third parties. Conventional encryption by DES is used to provide

confidentiality.

Integrity of data (ensure the integrity of all transmitted data): SET combats the risk of transaction

information being altered in transit by keeping information securely encrypted at all times. That is, it

guarantees that no changes in message content occur during transmission. Digital signatures are used

to ensure integrity.

Cardholder account authentication (provide authentication that a cardholder is a legitimate customer

of a branded payment card account): Merchants need a way to verify that a cardholder is a legitimate

user of a valid account number. A mechanism that links the cardholder to a specific payment card

account number reduces the incidence of fraud and the overall cost of payment processing. SET uses

X.509 v3 digital certificates with RSA signatures for this purpose.

Merchant authentication (provide authentication that a merchant can accept credit card transactions

through its relationship with an acquiring financial institution): Merchants have no way of verifying

whether the cardholder is in possession of a valid payment card or has the authority to be using that

card. There must be a way for the cardholder to confirm that a merchant has a relationship with a

financial institution (acquirer) allowing it to accept the payment card. Cardholders also need to be

able to identify merchants with whom they can securely conduct electronic commerce. SET provides

for the use of digital signatures and merchant certificates to ensure authentication of the merchant.

Security techniques (ensure the use of the best security practices and system design techniques to

protect all legitimate parties in an electronic commerce transaction): SET utilises two asymmetric

key pairs for the encryption/decryption process and for the creation and verification of digital

signatures. Confidentiality is ensured by the message encryption. Integrity and authentication are

ensured by the use of digital signatures.

Creation of brand-new protocol (create a protocol that neither depends on transport security

mechanisms nor prevents their use): SET is an end-to-end protocol whereas SSL provides point-to-

point encryption. SET does not interfere with the use of other security mechanisms such as IPsec and

SSL/TLS.

Interoperability (facilitate and encourage interoperability among software and network providers):

SET uses specific protocols and message formats to provide interoperability. The specification must

be applicable on a variety of hardware and software platforms and must not include a preference for

one over another.

Who are the SET participants? Explain their role in detail.

The participants in the SET system interactions are:


VIGNESH.L.S AP/CSE

• Cardholder: A cardholder is an authorised holder of a payment card that has been issued by an

issuer. In the cardholder‘s interactions, SET ensures that the payment card account information

remains confidential.

• Issuer: An issuer is a financial institution (a bank) that establishes an account for a cardholder and issues the payment card. The issuer guarantees payment for authorised transactions using the payment card.

• Merchant: A merchant is a person or organisation that offers goods or services for sale to the

cardholder. Typically, these goods or services are offered via a Website or by e-mail. With SET, the

merchant can offer its cardholders secure electronic interactions. A merchant that accepts payment

cards must have a relationship with an acquirer (a financial institution).

• Acquirer: An acquirer is the financial institution that establishes an account with a merchant and

processes payment card authorisation and payments. The acquirer provides authentication to the

merchant that a given card account is active and that the proposed purchase does not exceed the credit

limit.

• Payment gateway: A payment gateway acts as the interface between a merchant and the acquirer. It

carries out payment authorisation services for many card brands and performs clearing services and

data capture The payment gateway functions as follows: it decrypts the encoded message,

authenticates all participants in a transaction, and reformats the SET message into a format compliant

with the merchant‘s point of sale system. Note that issuers and acquirers sometimes choose to assign

the processing of payment card transactions to third-party processors.

• Certification Authority: A CA is an entity that is trusted to issue X.509 v3 public key certificates for

cardholders, merchants and payment gateways. The success of SET will depend on the existence of a

CA infrastructure available for this purpose. The primary functions of the CA are to receive

registration requests, to process and approve/decline requests, and to issue certificates. A financial

institution may receive, process and approve certificate requests for its cardholders or merchants, and

forward the information to the appropriate payment card brand(s) to issue the certificates.


VIGNESH.L.S AP/CSE

In the SET environment, there exists a hierarchy of CAs. The SET protocol specifies a

method of trust chaining for entity authentication. This trust chain method entails the exchange of

digital certificates and verification of the public keys by validating the digital signatures of the issuing

CA.

How Authentication and Integrity is ensured in SET? Authentication and Message Integrity

When user A wishes to sign the plaintext information and send it in an encrypted message (ciphertext) to user B, the encryption/decryption processes for message integrity consist of the following steps:

1. Encryption process:

w User A sends the plaintext through a hash function to produce the message digest that is used

later to test the message integrity.

w A then encrypts the message digest with his or her private key to produce the digital signature.

w Next, A generates a random symmetric key and uses it to encrypt the plaintext, A‘s signature

and a copy of A‘s certificate, which contains A‘s public key. To decrypt the plaintext later, user B will require a secure copy of this temporary symmetric key.

w B‘s certificate contains a copy of his or her public key. To ensure secure transmission of the

symmetric key, A encrypts it using B‘s public key. The encrypted key, called the digital envelope, is sent to B along with the encrypted message itself.

w A sends a message to B consisting of the DES-encrypted plaintext, signature and A‘s public

key, and the RSA-encrypted digital envelope.

2. Decryption process:

w B receives the encrypted message from A and decrypts the digital envelope with his or her

private key to retrieve the symmetric key.

w B uses the symmetric key to decrypt the encrypted message, consisting of the plaintext, A‘s

signature and A‘s public key retrieved from A‘s certificate.

w B decrypts A‘s digital signature with A‘s public key that is acquired from A‘s certificate. This

recovers the original message digest of the plaintext.

w B runs the plaintext through the same hash function used by A and produces a new message

digest of the decrypted plaintext.

w Finally, B compares his or her message digest to the one obtained from A‘s digital signature. If

they are exactly the same, B confirms that the message content has not been altered during transmission and that it was signed using A‘s private key.

If they are not the same, then the message either originated somewhere else or was altered after it was signed. In that case, B discards the message.


VIGNESH.L.S AP/CSE

USffA A'spnvw "-'>

Messa:r commts

= Pti.niext + Si:mture + A's publJc Ley

Rmdom I)

lllllK.'tnc

lcy

B'spubbc

lcy

B's Cl'llDIClle

Usn- B

Symmelllc

IJ:y

A'spobl,c Ley

t _


VIGNESH.L.S AP/CSE

Transport & Tunnel Modes


VIGNESH.L.S AP/CSE


VIGNESH.L.S AP/CSE

Transport and Tunnel Modes

• Both AH and ESP have two modes

– Transport mode is used to encrypt & optionally authenticate IP data

– Tunnel mode encrypts entire IP packet


VIGNESH.L.S AP/CSE

HMAC

• HMAC stands for Hash-based MAC. It works by using an underlying hash function over a message and a key.

• Commonly used hash functions are MD5 and SHA-1.

• To compute HMAC over the message, the HMAC equation is

expressed as follows:

where,

• ipad = 00110110(0x36) repeated 64 times (512 bits)

• opad = 01011100(0x5c) repeated 64 times (512 bits)


VIGNESH.L.S AP/CSE

• ipad is inner padding opad is outer padding.


VIGNESH.L.S AP/CSE

'

•

K

padding

K' = 512 bits M

b = 512 bits b= 512 bits

M

b l"'b b

b 1ipad + n; II M In; :Mal Md " . L-i:

opad -+ O.; = K'EBipad - b b = 512 bits

IV---+i H

b=512bits 160 bits (SHA- I)

128 bits (M 05)

h = 160 bits (SHA-I)

128 bits (M 05)

Q0 = K'EBopad - b

Padding

b = 512 bits

L...----+i II :!+-----'


VIGNESH.L.S AP/CSE

160bits(SHA-l) rv H

128 bits (MD5)

' I,

HMAC(M)


VIGNESH.L.S AP/CSE

The following explains the HMAC equation:

1. Append zeros to the end of K to create a b-byte string (i.e. if K = 160 bits in length and b = 512 bits, then K will be appended with 352 zero bits or 44 zero bytes 0x00).

2. XOR (bitwise exclusive-OR) K with ipad to produce the b-bit block computed in step 1.

3. Append M to the b-byte string resulting from step 2.

4. Apply H to the stream generated in step 3.

5. XOR (bitwise exclusive-OR) K with opad to produce the b-byte

string computed in step 1.

6. Append the hash result H from step 4 to the b-byte string

resulting from step 5.


VIGNESH.L.S AP/CSE

7. Apply H to the stream generated in step 6 and output the

result.


VIGNESH.L.S AP/CSE

Identity Theft and Identity Fraud


VIGNESH.L.S AP/CSE

Identity Theft

Identity thieves can cause a lot of damage – and cost you time, money, and patience to repair.

Identity theft happens when someone steals your personal information and uses it without permission.


VIGNESH.L.S AP/CSE

Thieves can run up your credit accounts, get new credit cards, medical treatment or a job – all in your name.


VIGNESH.L.S AP/CSE

Identity Theft

Identity theft is here primarily defined as a subsidiary crime, where an ID is abused to commit another crime.

IdeŶtity theft, occurs when one person obtains data or documents belonging to another the victim and then passes himself off as the victim.

Identity Theft is a crime in which an impostor obtains key pieces of personal Identifying


VIGNESH.L.S AP/CSE

Information (PII) such as Social Security Numbers and driver s license numbers and uses them for their own personal gain.


VIGNESH.L.S AP/CSE

Warning Signs

How do you know if your identity was stolen?

• mistakes on accounts or your Explanation of Medical benefits

• regular bills go missing

• Đalls froŵ deďt ĐolleĐtors for deďts that areŶt yours

• notice from the IRS


VIGNESH.L.S AP/CSE

• Đalls or ŵail aďout aĐĐouŶts iŶ your ŵiŶor Đhilds Ŷaŵe


VIGNESH.L.S AP/CSE

How does identity theft happen?

Identity thieves will:

• steal information from trash or from a business

• trick you into revealing information

• take your wallet or purse


VIGNESH.L.S AP/CSE

• pretend to offer a job, loan, or apartment to get your information


VIGNESH.L.S AP/CSE

• Stolen wallet

-Driver license ID

-Credit cards

-Debit cards

-Bank accounts checks; last withdrawal banking

statement

-Health insurance

-Pilfered mail

• Computer virus

• Phishing and Social Engineering

-Links to fraudulent web

sites

-Email

-Phone call

• Social Networking account

• License plate

• Health records

• Financial Data


VIGNESH.L.S AP/CSE

Identity Related Crime

Identity Collision, e.g., when two people have the same name, or when a wrong email address is used; this usually occurs unintentionally;

Identity Change, when someone takes on another identity, usually intentionally;

Identity Deletion, e.g., revoking a digital signature certificate;


VIGNESH.L.S AP/CSE

Identity Restoration, i.e., restoring the link between identifier and person.


VIGNESH.L.S AP/CSE

Identity Fraud Related Crime

Identity Takeover, when someone takes over the identity of another person without that persoŶs consent;

Identity Delegation, when someone uses someone else s identity with that persoŶs consent;

Identity Exchange, when two or more people, with mutual consent, use each other s identity;


VIGNESH.L.S AP/CSE

Identity Creation, when someone creates the identity of a non-existing person.

Title of the Presentation | 3/4/2017 | 1

VIGNESH.L.S AP/CSE Page 1

Den

ial o

f Serv

ice

How to React to…?

Stolen Laptop

Theft of Proprietary Information

Fire!

System Failure



Incident Response vs. Business Continuity

Incident Response Planning (IRP)

Security-related threats to systems, networks & data

Data confidentiality

Non-repudiable transactions

Business Continuity Planning

Disaster Recovery Plan

Continuity of Business Operations

IRP is part of BCP and can be *the first step*

NIST SP 800-61 defiŶes aŶ iŶĐideŶt as a ǀiolatioŶ oƌ imminent threat of violation of computer security

policies, acceptable use policies, or standard security pƌaĐtiĐes.



Review: Business Continuity Recovery Terms

Interruption Window: Time duration organization can wait between point of failure and service resumption

Service Delivery Objective (SDO): Level of service in Alternate Mode

Maximum Tolerable Outage: Max time in Alternate Mode

Regular Service

SDO

Disaster

Recovery

Plan Implemented

Alternate Mode

Regular

Service

Time…

Interruption

(Acceptable)

Interruption

Window

Restoration

Plan Implemented

Maximum Tolerable Outage



Vocabulary

Attack vectors = source methods: Can include removable media, flash drive, email, ǁeď, iŵpƌopeƌ use, loss oƌ theft, physiĐal aďuse, soĐial eŶgiŶeeƌiŶg, …



Vocabulary

IMT: Incident Management Team Mgr leads, includes steering committee, IRT members

Develop strategies & design plan for Incident Response,

integrating business, IT, BCP, and risk management

Obtain funding, Review postmortems

Meet performance & reporting requirements

IRT: Incident Response Team Handles the specific incident. Has specific knowledge relating to:

Security, network protocols, operating systems, physical security

issues, malicious code, etc.

Permanent (Full Time) Members: IT security specialists,

incident handlers, investigator

Virtual (Part Time) Members: Business (middle mgmt), legal,

public relations, human resources, physical security, risk, IT



Stages in Incident Response

Preparation

Identification

Plan PRIOR to Incident

Determine what is/has happened

Containment

& Escalation

Analysis &

Eradication

Recovery

Lessons

Learned

Limit incident

[If data breach]

Determine and remove

root cause

Return operations

to normal

Process improvement:

Plan for the future

Notification

Ex-Post

Response

Notify any data

breach victims

Establish call center,

reparation activities



Why is incident response important?

$201: average cost per breached record

66% of incidents took > 1 month to years to discover

82% of incidents detected by outsiders

78% of initial intrusions rated as low difficulty



Stage 1: Preparation What shall we do if different types of incidents occur? (BIA – Business Impact Assessment helps)

When is the incident management team called?

How can governmental agencies or law enforcement help?

When do we involve law enforcement?

What equipment do we need to handle an incident?

What shall we do to prevent or discourage incidents from occurring? (e.g. banners, policies)

Where on-site & off-site shall we keep the IRP?



(1) Detection Technologies Organization must have sufficient detection & monitoring capabilities to detect incidents in a timely manner

Proactive Detection includes:

Network Intrusion Detection/Prevention System (NIDS/NIPS)

Host Intrusion Detection/Prevention System (HIDS/HIPS)

Antivirus, Endpoint Security Suite

Security Information and Event Management (Logs)

Vulnerability/audit testing

System Baselines, Sniffer

Centralized Incident Management System

• Input: Server, system logs

• Coordinates & co-relates logs from many systems

• Tracks status of incidents to closure



Reactive Detection: Reports of unusual or suspicious activity



Logs to Collect & Monitor

Security

Config

Authent.

Failures

Network

Irregularity

Log Issues Normal

Events

Software App

Changes to sec. config.

Changes to network device config.

Change in privileges

Unauthor-

ized acceses

New Users

Lockouts & expired

passwd accts

Unusual packets

Blocked packets

Transfer of sensitive

data

Deleted logs

Overflowing log files

Clear/

change log config

Logins, logoffs

Access to sensitive

data

Attacks: SQL injection,

invalid input, DDOS

Others, listed in prev. columns

Change to files: system code/data

Change in traffic

patterns

All actions by admin



IŶcideŶts ŵay iŶclude…

Employees Reports

IT Detects a device (firewall, router or server) issues serious alarm(s) change in configuration

an IDS/IPS recognizes an irregular pattern:

• unusually high traffic,

• inappropriate file transfer

• changes in protocol use

unexplained system crashes or

unexplained connection terminations

Malware Violations of policy

Data breach:

• stolen laptop, memory

• employee mistake

Social engineering/fraud:

• caller, e-mail, visitors

Unusual event:

• inappropriate login

• unusual system aborts

• server slow

• deleted files



• defaced website



(1) Management Participation

Management makes final decision

As always, senior management has to be convinced that this is worth the money.

Actual Costs: Ponemon Data Breach Study, 2014, Sponsored by Symantec

Expenses Following a Breach Average Cost

Detection and Escalation: forensic investigation, audit, crisis mgmt.,

board of directors involvement

Notification: legal expertise, contact database development, customer

$420,000

$510,000 communications

Post Breach Response: help desk and incoming communications, identity

$1,600,000

protection services, legal and regulatory expenses, special investigations



Lost Business: abnormal customer churn, customer procurement,

goodwill

$3,320,000



Workbook

Incident Types Incident Description Methods of Detection Procedural Response

Intruder Firewall, database, IDS, Daily log evaluations, IT/Security addresses incident withinaccesses internal network

or server log indicates a probable intrusion.

high priority email alerts 1 hour: Follow: Network Incident Procedure Section.

Break-in or theft

Social Engineering

Trojan Wireless LAN

Computers, laptops or memory is stolen or lost.

Suspicious social engineering attempt was recognized OR

information was divulged that was recognized after the fact as being inappropriate. A new WLAN masquerades as us.

Security alarm set for off-hours; or employee reports missing device.

Training of staff leads to

report from staff

Key confidential areas are inspected

daily for WLAN availability



Email/call Management & IT

immediately. Management calls police, if theft. Security

initiates tracing of laptops via

location

software, writes Incident Report, evaluates if breach

occurred.

Report to Management & Security. Warn employees of attempt as added training. Security evaluates if breach occurred, writes incident report.

Security or network

administrator is notified

immediately. Incident is acted

upon within 2 hours.



Stage 2: Identification

Triage: Categorize, prioritize and assign events and incidents

What type of incident just occurred?

What is the severity of the incident?

• Severity may increase if recovery is delayed

Who should be called?

Establish chain of custody for evidence



(2) Triage

Snapshot of the known status of all reported incident activity

• Sort, Categorize, Correlate, Prioritize & Assign

Categorize: DoS, Malicious code, Unauthorized access, Inappropriate usage, Multiple components

Prioritize: Limited resources requires prioritizing response to minimize impact

Assign: Who is free/on duty, competent in this area?



(2) Chain of Custody Evidence must follow Chain of Custody law to be admissible/acceptable in court

• Include: specially trained staff, 3rd party specialist, law enforcement, security response team

System administrator can:

Retrieve info to confirm an incident

Identify scope and size of affected environment (system/network)

Determine degree of loss/alteration/damage

Identify possible path of attack



Stage 3: Containment Activate Incident Response Team to contain threat

• IT/security, public relations, mgmt, business

Isolate the problem

• Disable server or network zone comm.

• Disable user access

• Change firewall configurations to halt connection

Obtain & preserve evidence



(3) Containment - Response

Technical

Collect data

Analyze log files

Obtain further technical assistance

Deploy patches & workarounds

Managerial

Business impacts result in mgmt intervention, notification, escalation, approval

Legal

Issues related to: investigation, prosecution, liability, privacy, laws & regulation, nondisclosure



Stage 4: Analysis & Eradication Determine how the attack occurred: who, when, how, and why?

• What is impact & threat? What damage occurred?

Remove root cause: initial vulnerability(s)

• Rebuild System

• Talk to ISP to get more information

• Perform vulnerability analysis

• Improve defenses with enhanced protection techniques

Discuss recovery with management, who must make decisions on handling affecting other areas of business



(4) Analysis

What happened?

Who was involved?

What was the reason for the attack?

Where did attack originate from?

When did the initial attack occur?

How did it happen?

What vulnerability enabled the attack?



(4) Remove root cause

If Admin or Root compromised, rebuild system

Implement recent patches & recent antivirus

Fortify defenses with enhanced security controls

Change all passwords

Retest with vulnerability analysis tools



Stage 5: Recovery

Restore operations to normal

Ensure that restore is fully tested and operational



Workbook

Incident Handling Response

Incident Type: Malware detected by Antivirus software Contact Name & Information: Computer Technology Services Desk:

www.univ.edu/CTS/help 262-252-3344(O) Emergency Triage Procedure: Disconnect computer from Internet/WLAN. Do not reconnect. Allow anti-virus to fix

problem, if possible. Report to IT first thing during next business day. Containment & Escalation Conditions and Steps: If laptop contained confidential information, investigate malware to determine if intruder

obtained entry. Determine if Breach Law applies. Analysis & Eradication Procedure: If confidential information was on the computer (even though encrypted), malware may have

sent sensitive data across the internet; A forensic investigation is required. Next, determine if virus=dangerous and user=admin: Type A: return computer. (A=Virus not dangerous and user not admin.) Type B: Rebuild computer. (B=Either virus was dangerous and/or user was admin) Password is changed for all users on the computer.

Other Notes (Prevention techniques): Note: Antivirus should record type of malware to log system.

http://www.univ.edu/CTS/help



Stage 6: Lessons Learned

Follow-up includes:

Writing an Incident Report

• What went right or wrong in the incident response?

• How can process improvement occur?

• How much did the incident cost (in loss & handling & time)

Present report to relevant stakeholders



Planning Processes Risk & Business Impact Assessment

Response & Recovery Strategy Definition

Document IRP and DRP

Train for response & recovery

Update IRP & DRP

Test response & recovery

Audit IRP & DRP



Training

Introductory Training: First day as IMT

Mentoring: Buddy system with longer-term member

Formal Training

On-the-job-training

Training due to changes in IRP/DRP



Types of Penetration Tests

External Testing: Tests from outside network perimeter

Internal Testing: Tests from within network

Blind Testing: Penetration tester knows nothing in advance and must do web research on company

Double Blind Testing: System and security administrators also are not aware of test

Targeted Testing: Have internal information about a target. May have access to an account.

Written permission must always be obtained first



Incident Management Metrics

# of Reported Incidents

# of Detected Incidents

Average time to respond to incident

Average time to resolve an incident

Total number of incidents successfully resolved

Proactive & Preventative measures taken

Total damage from reported or detected incidents

Total damage if incidents had not been contained in a timely manner



Challenges

Management buy-in: Management does not allocate time/staff to develop IRP

• Top reason for failure

Organization goals/structure mismatch: e.g., National scope for international organization

IMT Member Turnover

Communication problems: Too much or too little

Plan is to complex and wide



Question

The MAIN challenge in putting together an IRP is likely to be:

1. Getting management and department support

2. Understanding the requirements for chain of custody

3. Keeping the IRP up-to-date

4. Ensuring the IRP is correct



Question

The PRIMARY reason for Triage is:

1. To coordinate limited resources

2. To disinfect a compromised system

3. To determine the reasons for the incident

4. To detect an incident



Question

When a system has been compromised at the administrator level, the MOST IMPORTANT action is:

1. Ensure patches and anti-virus are up-to-date

2. Change admin password

3. Request law enforcement assistance to investigate incident

4. Rebuild system



Question

The BEST method of detecting an incident is:

1. Investigating reports of discrepancies

2. NIDS/HIDS technology

3. Regular vulnerability scans

4. Job rotation



Question

The person or group who develops strategies for incident response includes:

1. CISO

2. CRO

3. IRT

4. IMT



Question

The FIRST thing that should be done when you discover an intruder has hacked into your computer system is to:

1. Disconnect the computer facilities from the computer network to hopefully disconnect the attacker

2. Power down the server to prevent further loss of confidentiality and data integrity

3. Call the police

4. Follow the directions of the Incident Response Plan



Computer Forensics

The process of identifying preserving, analyzing and presenting digital evidence for a legal proceeding



The Investigation Avoid Infringing on the rights of the suspect

WaƌƌaŶt ƌeƋuiƌed uŶless…

• Organization/home gives permission; the crime is communicated to a third party; the evidence is in plain site or is in danger of being destroyed; evidence is found during a normal arrest process; or if police are in hot pursuit.

Computer searches generally require a warrant except:

• When a signed acceptable use policy authorizes permission

• If computer repair person notices illegal activities (e.g., child pornography) they can report the computer to law enforcement



Computer Crime Investigation

Call Police

Or Incident Response

Copy memory, processes

files, connections In progress

Power down

Analyze copied images

Take photos of surrounding area

Preserve

original system In locked storage

w. min. access

Evidence must be unaltered Chain of custody

professionally maintained

Four considerations: Identify evidence

Preserve evidence

Analyze copy of evidence

Present evidence

Copy disk



Initial Incident Investigation

A forensic jumpkit includes:

• a laptop preconfigured with protocol sniffers and forensic software

• network taps and cables

• Since the attacked computer may be contaminated, the jumpkit must be considered reliable

The investigator is likely to:

• Get a full memory image snapshot, to obtain network connections, open files, in progress processes

• Photograph computer: active screen, inside, outside computer for full configuration

• Take disk image snapshot to analyze disk contents.

The investigator must not taint the evidence.

• E.g., a cell phone left on to retain evidence must be kept in a Faraday bag to shield phone from connecting to networks



Computer Forensics

Did a crime occur?

If so, what occurred?

Evidence must pass tests for:

Authenticity: Evidence is a true unmodified original from the crime scene

• Computer Forensics does not destroy or alter the evidence

Continuity: ChaiŶ of Đustody assuƌes that the evidence is intact and history is known


10:53 AM

11:15

11:45 Attack System System

observed brought Powered Jan K Offline down

RFT PKB & RFT


Chain of Custody

11:04 Inc. Resp.

team arrives

11:05-11:44 System copied

PKB & RFT

11:47-1:05 Disk

Copied RFT & PKB

Time Line

1:15 System locked in

static-free bag in storage room

RFT & PKB

Who did what to evidence when? (Witness is required)



Chain of Custody A chain of custody document tracks: Case number DeǀiĐe’s model and serial number (if available)

When and where the evidence was held/stored

For each person who held or had access to the evidence (at every time)

• name, title, contact information and signature

• why they had access

It is useful to have a witness at each point

Evidence is stored in evidence bags, sealed with evidence tape



Creating a Forensic Copy

2) Accuracy Feature:

Tool is accepted as accurate by the scientific community:

Original

4) One-way Copy:

Cannot modify

original

Mirror

Image

5) Bit-by-Bit Copy:

Mirror image

1) & 6) Calculate Message Digest:

Before and after copy

3) Forensically Sterile:

Wipes existing data;

Records sterility

7) Calculate Message Digest

Validate correctness of copy



Forensic Tools

Normalizing data = converting disk data to easily readable form

Forensic tools analyze disk or media copy for:

• logs

• file timestamps

• file contents

• recycle bin contents

• unallocated disk memory contents (or file slack)

• specific keywords anywhere on disk

• application behavior. The investigator:

launches the application on a virtual machine

runs identical versions of OS and software packages.



Forensic Software Tools

EnCase: Interprets hard drives of various OS, tablets, smartphones and removable

media for use in court. (www.guidancesoftware.com)

Forensic Tool Kit (FTK): Supports Windows, Apple, UNIX/Linux OS including analysis of volatile (RAM and O.S. structures) and nonvolatile data for use in a court. (www.accessdata.com)

Cellebrite: Handles commercial mobile devices for use in a court. Mobile devices are

connected via appropriate cables to a workstation with the forensic tool installed, or via a travel kit. (www.cellebrite.com)

ProDiscover: Analyzes hard disks for Windows, Linux and Solaris OS. An Incident Response tool can remotely evaluate a live system. (www.techpathways.com)

X-ways: Specializes in Windows OS. X-ways can evaluate a system via a USB-stick

without installation, and requires less memory. (www.x-ways.net)

Sleuthkit: An open-source tool evaluates Windows, Unix, Linux and OS-X. It is

programmer-extendable. Sleuth Kit (TSK) = command-line tool; Autopsy = graphical interface. (www.sleuthkit.org)

http://www.guidancesoftware.com/

http://www.accessdata.com/

http://www.cellebrite.com/

http://www.techpathways.com/

http://www.x-ways.net/

http://www.sleuthkit.org/



Preparing for Court

When the case is brought to court, the tools & techniques used

will be qualified for court:

Disk copy tool and forensic analysis tools must be standard

IŶǀestigatoƌ’s ƋualifiĐatioŶs iŶĐlude education level, forensic training & certification:

• forensic software vendors (e.g., EnCase, FTK) OR

• independent organizations (e.g.: Certified Computer Forensics Examiner or Certified Forensic Computer Examiner).

Some states require a private detective license.



The Investigation Report

The Investigation Report describes the incident accurately. It:

Provides full details of all evidence, easily referenced

Describes forensic tools used in the investigation

Includes interview and communication info

Provides actual results data of forensic analysis

Describes how all conclusions are reached in an unambiguous

and understandable way

IŶĐludes the iŶǀestigatoƌ’s ĐoŶtaĐt iŶfoƌŵatioŶ aŶd dates of the investigation

Is signed by the investigator



A Judicial Procedure Civil Case Criminal Case

Plaintiff files Complaint

(or lawsuit)

Law enforcement arrests

defendant

Reads Miranda rights

Defendant sends Answer

within 20 days Prosecutor files an

Information with charges or

Grand Jury issues an

indictment

Discovery

Phase

Plaintiff & Defendant provide list

of evidence and witnesses to

other side

Plaintiff & Defendant request

testimony, files, documents

Responsive

documents

The Trial



E-Discovery

Electronic Responsive Documents = Electronically Stored Info (ESI) or E-Discovery

The U.S. Federal Rules of Civil Procedure define how ESI should be requested and

formatted

E-requests can be general or specific:

• specific document

• set of emails referencing a particular topic.

Discovery usually ends 1-2 months before trial, or when both sides agree

All court reports become public documents unless specifically sealed.



Discovery Stage

Depositions: interviews of the key parties, e.g., witnesses or consultants

• question-and-answer session

• all statements recorded by court reporter; possible video

• The deponent (person being questioned) may correct transcript before it is entered into court record.

Declarations: written documents

• Declarer states publicly their findings and conclusions

• Full references to public documents helps believability

• Includes name, title, employer, qualifications, often billing rate, role, signature

Affidavit: a declaration signed by a notary

• Both declarations and affidavits are limited to support motions



Witnesses

Witnesses must present their qualifications

Notes accessible during discovery?

• NO: Email correspondence with lawyers is given attorney-client privilege

• YES: Notes, reports, and chain of custody documents are discoverable.

Witnesses may include (least to most qualified):

Fact witnesses report on their participation in the case, generally in obtaining and analyzing evidence.

Expert consultants help lawyers understand technical details, but do not testify or give

depositions

Expert witnesses provide expert opinions within reports and/or testimony

• E.g., Computer forensic examiners

• Do not need first-hand knowledge of case; can interpret evidence

• Expert witness mistakes can ruin reputation



The Trial Stages of the Trial In U.S. and U.K.

Case law is determined by:Opening

Arguments

Plaintiff‘s

case

Defendant‘s

case

Closing

arguments

• Regulation AND/OR

• precedence: previous decisions hold

weight when regulation is not explicit and

must be interpreted

Burden of Proof:

• In U.S. & U.K. criminal case : beyond a

ƌeasoŶaďle douďt that the defeŶdaŶt committed the crime

• IŶ U.K. Điǀil Đase: the balance of pƌoďaďilities oƌ ŵoƌe suƌe thaŶ Ŷot



Authenticity requires:

Question

1. Chain of custody forms are completed

2. The original equipment is not touched during the investigation

3. Law enforcement assists in investigating evidence

4. The data is a true and faithful copy of the crime scene



Question

You are developing an Incident Response Plan. An executive

order is that the network shall remain up, and intruders are to be

puƌsued. Youƌ fiƌst step is to…

1. Use commands off the local disk to record what is in memory

2. Use commands off of a memory stick to record what is in

memory

3. Find a witness and log times of events

4. Call your manager and a lawyer in that order



Question

What is NOT TRUE about forensic disk copies?

1. The first step in a copy is to calculate the message digest

2. Forensic analysis for presentation in court should always

occur on the original disk

3. Normalization is a forensics stage which converts raw data to aŶ uŶdeƌstood foƌŵat ;e.g., ASCII, gƌaphs, …Ϳ

4. Forensic copies requires a bit-by-bit copy



Summary

Planning is necessary

• Without preparation, no incident will be detected

• Incident handlers should not decide what needs to be done.

Stages:

• Identification: Determine what has happened

• Containment & Escalation: Limit incident

• Analysis & Eradication: Analyze root cause, repair

• Restore: Test and return to normal

• Process Improvement

• (Possibly) Breach Notification

If case is to be prosecuted:

• Evidence must be carefully handled: Authenticity & Continuity

• Expert testimony must be qualified, accurate, bullet-proof


Case 1:

One person obtains data or documents

belonging to another – the victim – and then

passes himself off as the victim.

Case 2:

One person takes over a totally fictitious name

or adopts the name of another person with or without their consent.


Identity Theft and Identity Fraud


Identity Theft

Identity thieves can cause a lot of damage – and cost you time, money, and patience to repair.

Identity theft happens when someone steals your personal information and uses it without permission.

Thieves can run up your credit accounts, get new credit cards, medical treatment or a job – all in your name.


Identity Theft

Identity theft is here primarily defined as a subsidiary crime, where an ID is abused to commit another crime.

IdeŶtity theft, occurs when one person obtains data or documents belonging to another the victim and then passes himself off as the victim.

Identity Theft is a crime in which an impostor obtains key pieces of personal Identifying Information (PII) such as Social Security Numbers and driǀer s license numbers and uses them for their own personal gain.


Warning Signs

How do you know if your identity was stolen?

• Mistakes on accounts or your Explanation of Medical benefits

• Regular bills go missing

• Calls froŵ deďt ĐolleĐtors for deďts that areŶt yours

• Notice from the IRS

• Calls or ŵail aďout aĐĐouŶts iŶ your ŵiŶor Đhilds Ŷaŵe


How does identity theft happen?

Identity thieves will:

• Steal information from trash or from a business

• Trick you into revealing information

• Take your wallet or purse

• Pretend to offer a job, loan, or apartment to get your information


Identity Related Crime

Identity Collision, e.g., when two people have the same name, or when a wrong email address is used; this usually occurs unintentionally;

Identity Change, when someone takes on another identity, usually intentionally;

Identity Deletion, e.g., revoking a digital signature certificate;

Identity Restoration, i.e., restoring the link between identifier and person.


Identity Fraud Related Crime

Identity Takeover, when someone takes over the identity of another person without that persoŶs consent;

Identity Delegation, when someone uses someone else s identity with that persoŶs consent;

Identity Exchange, when two or more people, with mutual consent, use each other s identity;

Identity Creation, when someone creates the identity of a non-existing person.


Case Study

• Frank Abagnale

• Michelangelo


CoCmopmupteurteForrFeonrseicnssics


Definition

– Computer forensics involves the preservation, identification, extraction, documentation, and interpretation of computer media for evidentiary and/or root cause analysis.

– Evidence might be required for a wide range of computer crimes and misuses

– Multiple methods of

• Discovering data on computer system

• Recovering deleted, encrypted, or damaged file information

• Monitoring live activity

• Detecting violations of corporate policy

– Information collected assists in arrests, prosecution, termination of employment, and preventing future illegal activity


Definition (cont)

What Constitutes Digital Evidence?

– Any information being subject to human intervention or not, that can

be extracted from a computer.

– Must be in human-readable format or capable of being interpreted by a

person with expertise in the subject.

Computer Forensics Examples

– Recovering thousands of deleted emails

– Performing investigation post employment termination

– Recovering evidence post formatting hard drive

– Performing investigation after multiple users had taken over the system


Who Uses Computer Forensics?

• Criminal Prosecutors – Rely on evidence obtained from a computer to prosecute suspects and

use as evidence

• Civil Litigations – Personal and business data discovered on a computer can be used in

fraud, divorce, harassment, or discrimination cases

• Insurance Companies – Evidence discovered on computer can be used to mollify costs (fraud,

ǁorker s compensation, arson, etc)

• Private Corporations – Obtained evidence from employee computers can be used as evidence

in harassment, fraud, and embezzlement cases


Who Uses Computer Forensics? (cont)

• Law Enforcement Officials

– Rely on computer forensics to backup search warrants and post-

seizure handling

• Individual/Private Citizens

– Obtain the services of professional computer forensic specialists to

support claims of harassment, abuse, or wrongful termination from

employment


FBI Computer Forensic Services

• Content

• Comparison against known data

• Transaction sequencing

• Extraction of data

• Recovering deleted data files

• Format conversion

• Keyword searching

• Decrypting passwords

• Analyzing and comparing limited source code


Steps Of Computer Forensics

• Uncovering what REALLY occurred.

• According to many professionals, Computer Forensics is a four (4) step

process

– Acquisition

• Physically or remotely obtaining possession of the computer, all

network mappings from the system, and external physical storage

devices

– Identification

• This step involves identifying what data could be recovered and

electronically retrieving it by running various Computer Forensic

tools and software suites


Steps Of Computer Forensics (cont)

– Evaluation

• Evaluating the information/data recovered to determine if and

how it could be used against the suspect for employment

termination or prosecution in court

– Presentation

• This step involves the presentation of evidence discovered in a

manner which is understood by lawyers, non-technically

staff/management, and suitable as evidence as determined by


United States and internal laws

Evidence in Computer Forensics


• Circumstantial

– A hint, which (alone or together with some) allows

to conclude at certain facts.

• Evidence

– A hypothetical situation that is accepted as a fact

by judge / others.

– Fulfill the burden of proof.

Evidence in Computer Forensics


• Types of Evidences:

– Digital Evidence

• Stored or being transmitted in computers, E- mails,

WLAN etc.,

– Analogue Evidence

• Finger Prints, Fibres, Body fluids etc.,

Other Types of Evidence


• Who was it: Identifying Information

– IP Address, Login ID or Password.

• What did he do: Traces of actions

– Log Files, Event log, History of actions performed by

user.

• What did he add: Data itself

– Additional Program code, User Account.

• What did he remove: Data itself

– Deleted files, Encrypted Files.


Case 1:

User A uses the identity of User B to buy a

product pretending that he lives in the address of

B without the knowledge of User B.

Case 2:

User A uses the identity of User B to buy a

product pretending that he lives in the address of

B with the knowledge of User B.


Case 3:

User A and User B swap their identity with

mutually.

Case 4:

User A creates the identity of User B who does

not even exist.


Basic Rules of Computer Forensic Proof

• You state that something is true -> Prove it.

• Civil Procedures -> Proves what is advantageous for

them.

• Criminal Procedures -> Must have to prove everything.

• If court is convinced, burden switches to other party to

prove the opposite.

Properties of Computer Forensic Evidence


• Admissible -> Should be useful and accepted.

• Authentic

• Complete

• Reliable

• Believable

Properties of Computer Forensic Evidence


• No action should affect the integrity

• All activities should be logged (Documented

and Preserved)

• Investigations should be accurate and

impartial

Handling Information


• Information and data being sought after and collected in the

investigation must be properly handled

• Volatile Information

– Network Information

• Communication between system and the network

– Active Processes

• Programs and daemons currently active on the system

– Logged-on Users

• Users/employees currently using system

– Open Files

• Libraries in use; hidden files; Trojans (rootkit) loaded in system


Handling Information (cont)

• Non-Volatile Information

– This includes information, configuration settings, system

files and registry settings that are available after reboot

– Accessed through drive mappings from system

– This information should investigated and reviewed from a

backup copy


UNIT IV EVIDENCE COLLECTION AND FORENSICS TOOLS

Processing Crime and Incident Scenes – Working with Windows and DOS Systems. Current

Computer Forensics Tools: Software/ Hardware Tools.

Identifying Digital Evidence

Digital evidence can be any information stored or transmitted in digital form. Because you

can‘t see or touch digital data directly, it‘s difficult to explain and describe. Is digital evidence real or

virtual? U.S. courts accept digital evidence as physical evidence, which means digital data is treated

as a tangible object, such as a weapon, paper document, or visible injury, that‘s related to a criminal

or civil incident. However, each country has its own interpretation of what can or can‘t be presented

in court or accepted as evidence. Some countries used to require that all digital evidence be printed to

be presented in court.

Following are the general tasks investigators perform when working with digital evidence: • Identify digital information or artifacts that can be used as evidence. • Collect, preserve, and document evidence. • Analyze, identify, and organize evidence. • Rebuild evidence or repeat a situation to verify that the results can be reproduced reliably.

To minimize confusion, reduce the risk of losing evidence, and avoid damaging evidence,

only one team should collect and catalog digital evidence at a crime scene or lab, if practical. If

there‘s too much evidence or too many systems to make it practical for one team to perform these

tasks, all examiners must follow the same established operating procedures, and a lead or managing

examiner should control collecting and cataloging evidence. An important challenge investigators

face today is establishing recognized standards for digital evidence.

Understanding Rules of Evidence

Consistent practices help verify your work and enhance your credibility, so you must handle

all evidence consistently. Apply the same security and accountability controls for evidence in a civil

lawsuit. Also, the evidence admitted in a criminal case might also be used in a civil suit, and vice

versa. For example, suppose someone is charged with murder and acquitted at the criminal trial

because the jury isn‘t convinced beyond a reasonable doubt of the person‘s guilt. If enough evidence

shows that the accused‘s negligence contributed to a wrongful death, however, the victim‘s relatives

can use the evidence in a civil lawsuit to recover damages.

Another concern when dealing with digital records is the concept of hearsay, which is a

statement made while testifying at a hearing by someone other than an actual witness to the event. For

example, a rumor has been circulating around an office about an incident, or a friend mentioned it to

the person being questioned; both situations would be considered hearsay. The following are some

that apply to digital forensics investigations: • Business records, including those of a public agency • Certain public records and reports • Evidence of the absence of a business record or entry • Learned treatises used to question an expert witness • Statements of the absence of a public record or entry

In other common law countries, a distinction is made between ―real computer evidence‖ and

―hearsay computer evidence.‖ Generally, digital records are considered admissible if they qualify as a

business record. Another way of categorizing computer records is by dividing them into computer-

generated records and computer-stored records. Computer-generated records are data the system

maintains, such as system log files and proxy server logs. They are output generated from a computer

process or algorithm, not usually data a person creates. Computer-stored records, however, are


electronic data that a person creates and saves on a computer or digital device, such as a spreadsheet

or word processing document. Some records combine computergenerated and computer-stored

evidence, such as a spreadsheet containing mathematical operations (computer-generated records)

generated from a person‘s input (computer-stored records). Computer and digitally stored records

must also be shown to be authentic and trustworthy to be admitted into evidence. Computer-generated

records are considered authentic if the program that created the output is functioning correctly. These

records are usually considered exceptions to the hearsay rule.

Collecting evidence according to approved steps of evidence control helps ensure that the

computer evidence is authentic, as does using established forensics software tools. Courts have

consistently ruled that forensics investigators don‘t have to be subject matter experts on the tools they

use. The witness must have firsthand knowledge only of facts relevant to the case. If you have to

testify about your role in acquiring, preserving, and analyzing evidence, you don‘t have to know the

inner workings of the tools. When attorneys challenge digital evidence, often they raise the issue of

whether computer generated records were altered or damaged after they were created. Attorneys

might also question the authenticity of computer-generated records by challenging the program that

created them.

To establish authorship of digital evidence in these cases, attorneys can use circumstantial

evidence, which requires finding other clues associated with the suspect‘s computer or location. The

circumstantial evidence might be that the computer has a password consistent with the password the

suspect used on other systems, a witness saw the suspect at the computer at the time the offense

occurred, or additional trace evidence associates the suspect with the computer at the time of the

incident. Agents and prosecutors occasionally express concern that a printout of a computer-stored

electronic file might not qualify as an original document, according to the best evidence rule. In its

most fundamental form, the original file is a collection of 0s and 1s; in contrast, the printout is the

result of manipulating the file through a complicated series of electronic and mechanical processes.

The FRE allows duplicates instead of originals when the duplicate is ―produced by the same

impression as the original … by mechanical or electronic re-recording … or by other equivalent

techniques which accurately reproduce the original.‖ Therefore, as long as bit-stream copies of data

are created and maintained correctly, the copies can be admitted in court, although they aren‘t

considered best evidence. The copied evidence can be a reliable working copy, but it‘s not considered

the original.

Collecting Evidence in Private-Sector Incident Scenes

Private-sector organizations include small to medium businesses, large corporations, and non-

government organizations (NGOs), which might get funding from the government or other agencies.

State public disclosure laws define state public records as open and available for inspection. A special

category of private-sector businesses is ISPs and other communication companies. ISPs can

investigate computer abuse committed by their employees but not by customers. ISPs must preserve

customer privacy, especially when dealing with e-mail.

In the private sector, the incident scene is often a workplace, such as a contained office or

manufacturing area, where a policy violation is being investigated. Everything from the computers

used to violate a company policy to the surrounding facility is under a controlled authority—that is,

company management. Typically, businesses have inventory databases of computer hardware and

software. Having access to these databases and knowing what applications are on suspected

computers help identify the forensics tools needed to analyze a policy violation and the best way to

conduct the analysis. For example, companies might have a preferred Web browser, such as Microsoft

Internet Explorer, Mozilla Firefox, or Google Chrome. Knowing which browser a suspect used helps

you develop standard examination procedures to identify data downloaded to the suspect‘s

workstation.


To investigate employees suspected of improper use of company digital assets, a company

policy statement about misuse of digital assets allows corporate investigators to conduct covert

surveillance with little or no cause and access company computer systems and digital devices without

a warrant, which is an advantage for corporate investigators. Law enforcement investigators can‘t do

the same, however, without sufficient reason for a warrant. A well-defined corporate policy, therefore,

should state that an employer has the right to examine, inspect, or access any company-owned digital

assets. If a company issues a policy statement to all employees, the employer can investigate digital

assets at will without any privacy right restrictions. However, organizations must also have a well-

defined process describing when an investigation can be initiated. At a minimum, most company

policies require that employers have a ―reasonable suspicion‖ that a law or policy is being violated.

If a corporate investigator finds that an employee is committing or has committed a crime, the

employer can file a criminal complaint with the police. Some businesses, such as banks, have a

regulatory requirement to report crimes. Employers are usually interested in enforcing company

policy, not seeking out and prosecuting employees, so typically they approve digital investigations

only to identify employees who are misusing company assets. Corporate investigators are, therefore,

concerned mainly with protecting company assets, such as intellectual property.

If an evidence id discovered of a crime during a company policy investigation, first determine

whether the incident meets the elements of criminal law. One might have to consult with their

corporate attorney to determine whether the situation is a potential crime. Next, inform management

of the incident; they might have other concerns, such as protecting confidential business data that

might be included with the criminal evidence. If the information supplied is specific enough to meet

the criteria for a search warrant, the police are responsible for obtaining a warrant that requests any

new evidence. The police instructions must be followed to gather additional evidence without a search

warrant after one has reported the crime; one runs the risk of becoming an agent of law enforcement.

Processing Law Enforcement Crime Scenes

To process a crime scene correctly, the analyst must be familiar with criminal rules of search

and seizure. A law enforcement officer can search for and seize criminal evidence only with probable

cause. Probable cause refers to the standard specifying whether a police officer has the right to make

an arrest, conduct a personal or property search, or obtain a warrant for arrest. Although several court

cases have allowed latitude when searching and seizing digital evidence, making your warrant as

specific as possible to avoid challenges from defense attorneys is a good practice. Often a warrant is

written and issued in haste because of the nature of the investigation. Law enforcement officers might

not have the time to research the correct language for stating the nature of the complaint to meet

probable cause requirements.

Understanding Concepts and Terms Used in Warrants

The investigator should be familiar with warrant terminology that governs the type of

evidence that can be seized. Many digital investigations involve large amounts of data you must sort

through to find evidence. Unrelated information is often included with the evidence that is tried to

recover. It might be personal records of innocent people or confidential business information. The

warrant must list which items can be seized. When approaching or investigating a crime scene, one

might find evidence related to the crime but not in the location the warrant specifies. One might also

find evidence of another unrelated crime. In these situations, this evidence is subject to the plain view

doctrine. For the plain view doctrine to apply, three criteria must be met: • The officer is where he or she has a legal right to be. • Ordinary senses must not be enhanced by advanced technology in any way, such as with binoculars. • Any discovery must be by chance.


Preparing for a Search

Preparing for search and seizure of computers or digital devices is probably the most

important step in digital investigations. The better one prepares, the smoother investigation will be.

The following are the tasks to be done while preparing for a search:

Identifying the Nature of the Case

One has to start by identifying the nature of the case, including whether it involves the private or public sector. The nature of the case dictates how to proceed and what types of assets or resources need to use in the investigation.

Identifying the Type of OS or Digital Device

The next step is identifying the OS. One might not know what kinds of digital devices were

used to commit a crime or how or where they were used. In this case, one must draw on their skills,

creativity, and sources of knowledge. If one can identify the OS or device, estimate the size of the

storage device on suspect computers and determine how many digital devices one has to process at

the scene. Also, determine what hardware might be involved and whether the evidence is on a

Microsoft, Linux, Apple, or mainframe computer.

Determining Whether You Can Seize Computers and Digital Devices

Generally, the ideal situation for incident or crime scenes is seizing computers and digital

devices and taking them to lab for further processing. However, the type of case and location of the

evidence determine whether one can remove digital equipment from the scene. Law enforcement

investigators need a warrant to remove computers from a crime scene and transport them to a lab. If

they aren‘t allowed to take the computers and digital devices to lab, determine the resources need to

acquire digital evidence and which tools can speed data acquisition. With large drives, such as a

terabyte or more, acquisition times can increase to several hours.

Getting a Detailed Description of the Location

The more information one have about the location of a digital crime, the more efficiently one

can gather evidence from the crime scene. Environmental and safety issues are the main concerns

during this process. Before arriving at an incident or crime scene, identify potential hazards to safety

of all examiners. Ambiguous or incorrect instructions could destroy evidence. When dealing with

extreme conditions, such as biological or chemical hazardous contaminants, one might have to

sacrifice equipment, such as data and power cables, to perform a task.

Determining Who Is in Charge

A company needs an established line of authority to specify who can instigate or authorize an

investigation. Corporate investigations usually require only one person to respond to an incident or

crime scene. Processing evidence usually involves acquiring an image of a suspect‘s drive. In law

enforcement, however, many investigations need additional staff to collect all evidence quickly. For

large-scale investigations, a crime or incident scene leader should be designated.

Using Additional Technical Expertise

Once the evidence data is collected, the investigator must determine whether they need

specialized help to process the incident or crime scene. Other concerns are how to acquire data from

RAID drives and how much data one can acquire. RAID servers typically process several terabytes of

data, and standard imaging tools might not be able to handle such large data sets. Finding the right

person can be an even bigger challenge than conducting the investigation.


Determining the Tools You Need

Being over prepared is better than being underprepared, especially when you determine that

one can‘t transfer the computer to lab for processing. To manage the tools, consider creating an

initial-response field kit and an extensive response field kit. Using the right kit makes processing an

incident or crime scene much easier and minimizes how much one have to carry from the vehicle to

the scene. The initial-response field kit should be lightweight and easy to transport. An extensive-

response field kit should include all the tools one can afford to take to the field, on arriving at the

scene, one should extract only those items needed to acquire evidence.

Preparing the Investigation Team

The goal of scene processing is to collect and secure digital evidence successfully. The better

the team is prepared, the fewer problems they encounter when they carry out the plan to collect data.

The digital evidence is volatile and responding slowly might result in the loss of important evidence

for the case.

Securing a Computer Incident or Crime Scene

Investigators secure an incident or crime scene to preserve the evidence and to keep

information about the incident or crime confidential. Information made public could jeopardize the

investigation. Access to the scene should be restricted to only those people who have a specific reason

to be there. The reason for the standard practice of securing an incident or crime scene is to expand

the area of control beyond the scene‘s immediate location. For major crime scenes, digital

investigators aren‘t usually responsible for defining a scene‘s security perimeter. These cases involve

other specialists and detectives who are collecting physical evidence and recording the scene.

For incidents involving mostly computers, the computers can be a crime scene within a crime

scene or a secondary crime scene, containing evidence to be processed. The evidence is in the

computer, but the courts consider it physical evidence. Evidence is commonly lost or corrupted

because of professional curiosity, which involves the presence of police officers and other

professionals who aren‘t part of the crime scene–processing team that might contaminate the scene

directly or indirectly.

Seizing Digital Evidence at the Scene

With proper search warrants, law enforcement can seize all digital systems and peripherals. In

corporate investigations, one might have the authority only to make an image of the suspect‘s drive.

Depending on company policies, corporate investigators rarely have the authority to seize all

computers and peripherals.

Preparing to Acquire Digital Evidence

The evidence one acquires at the scene depends on the nature of the case and the alleged

crime or violation. Before one collects digital evidence, ask your supervisor or senior forensics examiner in the organization the following questions: • Do you need to take the entire computer and all peripherals and media in the immediate area? How are you going to protect the computer and media while transporting them to your lab? • Is the computer powered on when you arrive? • Is the suspect you‘re investigating in the immediate area of the computer? Is it possible the suspect damaged or destroyed the computer, peripherals, or media?


Processing an Incident or a Crime Scene

The following guidelines offer suggestions on how to process an incident or crime scene. As

you gain experience in performing searches and seizures, you can add to or modify these guidelines to

meet the needs of specific cases. Use your judgment to determine what steps to take when processing

a civil or criminal investigation. For any difficult issues, seek out legal counsel or other technical

experts.

Keep a journal to document your activities. Include the date and time you arrive on the scene,

the people you encounter, and notes on every important task you perform. Update the journal as you

process the scene. To secure the scene, use whatever is practical to make sure only authorized people

can access the area. Remove anyone who isn‘t investigating the scene unless you need his or her help

to process the scene.

Take video and still recordings of the area around the computer or digital device. Start by

recording the overall scene, and then record details with close-up shots, including the back of all

computers. Before recording the back of each computer, place numbered or lettered labels on each

cable to help identify which cable is connected to which plug, in case you need to reassemble

components at the lab. When you finish videotaping or photographing the scene, sketch the incident

or crime scene. This sketch is usually a rough draft with notes on objects‘ dimensions and distances

between fixed objects.

Digital data is volatile, check the state of each computer or device at the scene as soon as

possible. Determine whether the computer is powered on or off or in hibernation or sleep mode. If it‘s

off, leave it off. If it‘s on, use your professional judgment on what to do next. Standard digital

forensics practice has been to kill the computer‘s power to make sure data doesn‘t become corrupt

through covert means. As a general rule, don‘t cut electrical power to a running system unless it‘s an

older Windows or MS-DOS system. However, it‘s a judgment call because of recent trends in digital

crimes. More digital investigations now revolve around network- and Internet-related cases, which

rely heavily on log file data. Certain files, such as the Event log and Security log in Windows, might

lose essential network activity records if power is terminated without a proper shutdown.

If you‘re working on a network or Internet investigation and the computer is on, save data in

any current applications as safely as possible and record all active windows or shell sessions. Don‘t

examine folders or network connections or press any keys unless it‘s necessary. For systems that are

powered on and running, photograph the screens. If windows are open but minimized, expanding

them so that you can photograph them is safe. As a precaution, write down the contents of each

window. As you‘re copying data on a live suspect computer, make notes in your journal about

everything you do so that you can explain your actions in your formal report to prosecutors and other

attorneys. When you‘ve finished recording screen contents, save them to external media.

If you can‘t save an open application to external media, save the open application to the

suspect drive with a new filename. Changing the filename avoids overwriting an existing file that

might not have been updated already. This method isn‘t ideal and should be done only in extreme

emergency conditions. After you record the scene and shut down the system, bag and tag the

evidence, following these steps:

1. Assign one person, if possible, to collect and log all evidence. Minimize the number of people handling evidence to ensure its integrity. 2. Tag all the evidence you collect with the current date and time, serial numbers or unique features, make and model, and name of the person who collected it. 3. Maintain two separate logs of collected evidence to be reconciled for audit control purposes and to verify everything you have collected. 4. Maintain constant control of the collected evidence and the crime or incident scene.


During the data acquisition or immediately after collecting the evidence, look for information

related to the investigation, such as passwords, passphrases, personal identification numbers (PINs),

and bank account numbers (particularly offshore bank accounts, often used to hide evidence of

financial transactions). This information might be in plain view or out of sight in a drawer or trashcan.

To finish your analysis and processing of a scene, collect all documentation and media related to the

investigation, including the following material: • Hardware, including peripheral devices • Software, including OSs and applications • All media, such as USB drives, backup tapes, and disks • All documentation, manuals, printouts, and handwritten notes

Processing Data Centers with RAID Systems

Digital investigators sometimes perform forensics analysis on RAID systems or server farms,

which are rooms filled with extremely large disk systems and are typical of large business data

centers, such as banks, insurance companies, and ISPs. A drawback of sparse acquisition technique is

that it doesn‘t recover data in free or slack space. If you have a computer forensics tool that accesses

unallocated space on a RAID system, work with the tool on a test system first to make sure it doesn‘t

corrupt the RAID system.

Using a Technical Advisor

At large data centers, the technical advisor is the person guiding you about where to locate

data and helping you extract log records or other evidence from large RAID servers. In law

enforcement cases, the technical advisor can help create the search warrant by itemizing what you

need for the warrant. If you use a technical advisor for this purpose, you should list his or her name in

the warrant. At the scene, a technical advisor can help direct other investigators to collect evidence

correctly. Technical advisors have the following responsibilities: • Know all aspects of the system being seized and searched. • Direct investigators on how to handle sensitive media and systems to prevent damage.

• Help ensure security of the scene.

• Help document the planning strategy for the search and seizure. • Conduct ad hoc training for investigators on the technologies and components being seized and searched. • Document activities during the search and seizure. • Help conduct the search and seizure.

Documenting Evidence in the Lab

After you collect digital evidence at the scene, you transport it to a forensics lab, which

should be a controlled environment that ensures the security and integrity of digital evidence. In any

investigative work, be sure to record your activities and findings as you work. To do so, you can

maintain a journal to record the steps you take as you process evidence. If you get different results

when you repeat the steps, the credibility of your evidence becomes questionable. At best, the

evidence‘s value is compromised; at worst, the evidence will be disqualified. Besides verifying your

work, a journal serves as a reference that documents the methods you used to process digital evidence.

You and others can use it for training and guidance on other investigations.

Processing and Handling Digital Evidence

You must maintain the integrity of digital evidence in the lab as you do when collecting it in

the field. Your first task is to preserve the disk data. If you have a suspect computer that hasn‘t been

copied with an imaging tool, you must create a copy. When you do, be sure to make the suspect drive

read-only (typically by using a write-blocking device), and document this step. The following steps are used to create image files:


1. Copy all image files to a large drive. Most forensics labs have several machines set up with disk-

imaging software and multiple hard drives that can be exchanged as needed for your cases. You can

use these resources to copy image files to large drives. Some might be equipped with large network

storage devices for ongoing cases.

2. Start your forensics tool to access and open the image files. 3. Run an MD5 or SHA-1 hashing algorithm on the image files to get a digital hash. Later in ―Obtaining a Digital Hash,‖ you learn how to compare MD5 or SHA-1 hashes to make sure the evidence hasn‘t changed. 4. When you finish copying image files to a larger drive, secure the original media in an evidence locker. Don‘t work with the original media; it should be stored in a locker that has an evidence custody form. Be sure to fill out the form and date it.

Storing Digital Evidence

With digital evidence, you need to consider how and on what type of media to save it and what type of storage device is recommended to secure it. The media you use to store digital evidence

usually depends on how long you need to keep it. If you investigate criminal matters, store the

evidence as long as you can. The ideal media on which to store digital data are CDs, DVDs, DVD-Rs,

DVD1Rs, or DVD-RWs.

You can also use magnetic tape to preserve evidence data. The 4-mm DAT magnetic tapes

store between 40 to 72 GB or more of data, but like CD-Rs, they are slow at reading and writing data.

If a 30-year lifespan for data storage is acceptable for your digital evidence, older DLT magnetic tape

cartridge systems are a good choice. However, don‘t rely on one media storage method to preserve

your evidence—be sure to make two copies of every image to prevent data loss. Also, if practical, use

different tools to create the two images because every tool has strengths and weaknesses.

Documenting Evidence

To document evidence, create or use an evidence custody form because of constant changes

in technologies and methods for acquiring data, create an electronic evidence custody form that you

can modify as needed. An evidence custody form serves the following functions:

• Identifies the evidence • Identifies who has handled the evidence • Lists dates and times the evidence was handled

After you have established these pieces of information, you can add others to your form, such

as a section listing MD5 and SHA-1 hash values. Include any detailed information you might need to

reference. Evidence bags also include labels or evidence forms you can use to document your

evidence. Commercial companies offer a variety of sizes and styles of paper and plastic evidence

bags. Be sure to write on the bag when it‘s empty, not when it contains digital evidence, to make sure

writing is legible and to avoid damaging the evidence. You should use antistatic bags for electronic

components.

Understanding File Systems

To investigate digital evidence effectively, you must understand how the most commonly

used OSs work and how they store files. A file system gives an OS a road map to data on a disk. The

type of file system an OS uses determines how data is stored on the disk. When you need to access a

suspect‘s computer to acquire or inspect data related to your investigation, you should be familiar

with both the computer‘s OS and file system so that you can access and modify system settings when

necessary.


Understanding the Boot Sequence

To ensure that you don‘t contaminate or alter data on a suspect‘s system, you must know how

to access and modify Complementary Metal Oxide Semiconductor (CMOS), BIOS, Extensible

Firmware Interface (EFI), and Unified Extensible Firmware Interface (UEFI) settings. A computer

stores system configuration and date and time information in the CMOS when power to the system is

off. The system BIOS or EFI contains programs that perform input and output at the hardware level.

BIOS is designed for x86 computers and typically used on disk drives with Master Boot Records

(MBR). EFI is designed for x64 computers and uses GUID Partition Table (GPT)- formatted disks.

BIOS and EFI are designed for specific firmware.

Understanding Disk Drives

You should be familiar with disk drives and how data is organized on a disk so that you can

find data effectively. Disk drives are made up of one or more platters coated with magnetic material,

and data is stored on platters in a particular way. Following is a list of disk drive components:

• Geometry—Geometry refers to a disk‘s logical structure of platters, tracks, and sectors. • Head—The head is the device that reads and writes data to a drive. There are two heads per platter that read and write the top and bottom sides. • Tracks—Tracks are concentric circles on a disk platter where data is located. • Cylinders—A cylinder is a column of tracks on two or more disk platters. Typically, each platter has two surfaces: top and bottom. • Sectors—A sector is a section on a track, usually made up of 512 bytes.

To determine the total number of addressable bytes on a disk, multiply the number of

cylinders by the number of heads (actually tracks) and by the number of sectors (groups of 512 or

more bytes). Disk drive vendors refer to this formula as a cylinder, head, and sector (CHS)

calculation. Tracks also follow a numbering scheme starting from 0, which is the first value in

computing.


Other disk properties, such as zone bit recording (ZBR), track density, areal density, and head

and cylinder skew, are handled at the drive‘s hardware or firmware level. ZBR is how most

manufacturers deal with a platter‘s inner tracks having a smaller circumference (and, therefore, less

space to store data) than its outer tracks. Grouping tracks by zones ensures that all tracks hold the

same amount of data. Track density is the space between each track. As with old vinyl records, the

smaller the space between each track, the more tracks you can place on the platter. Areal density

refers to the number of bits in one square inch of a disk platter. This number includes the unused

space between tracks.

Solid-State Storage Devices

Flash memory storage devices used in USB drives, laptops, tablets, and cell phones can be a

challenge for digital forensics examiners because if deleted data isn‘t recovered immediately, it might

be lost forever. The reason is a feature all flash memory devices have: wear-leveling. When data is

deleted on a hard drive, only the references to it are removed, which leaves the original data in

unallocated disk space. With forensics recovery tools, recovering data from magnetic media is fairly

easy by copying the unallocated space. USB drives are different, in that memory cells shift data at the

physical level to other cells that have had fewer reads and writes continuously. The purpose of

shifting (or rotating) data from one memory cell to another is to make sure all memory cells on the

flash drive wear evenly. Memory cells are designed to perform only 10,000 to 100,000 reads/writes,

depending on the manufacturer‘s design. When they reach their defined limits, they can no longer

retain data.

In addition, when data is rotated to another memory cell, the old memory cell addresses are

listed in a firmware file called a ―garbage collector.‖ At some point, the flash drive‘s firmware erases

data in unallocated cells by overwriting the value of 1 in all cells listed in the garbage collector file.

When dealing with solid-state devices, making a full forensic copy as soon as possible is crucial in

case you need to recover data from unallocated disk space. Depending on your jurisdiction and

country‘s laws on search and seizure, there might be some limitations on when an acquisition can take

place in criminal cases. For criminal investigations, you should get guidance from your local

prosecutor‘s office on how to handle this type of evidence.

Exploring Microsoft File Structures

One need to understand clusters, File Allocation Table (FAT), and NT File System (NTFS).

The method an OS uses to store files determines where data can be hidden. When you examine a

computer for forensic evidence, you need to explore these hiding places to determine whether they

contain files or parts of files that might be evidence of a crime or policy violation. In Microsoft file

structures, sectors are grouped to form clusters, which are storage allocation units of one or more

sectors. Clusters range from 512 bytes up to 32,000 bytes each. Combining sectors minimizes the

overhead of writing or reading files to a disk. The OS groups one or more sectors into a cluster.

Clusters are numbered sequentially, starting at 0 in NTFS and 2 in FAT. The first sector of all

disks contains a system area, the boot record, and a file structure database. The OS assigns these

cluster numbers, which are referred to as logical addresses. These addresses point to relative cluster

positions; for example, cluster address 100 is 98 clusters from cluster address 2. Sector numbers,

however, are referred to as physical addresses because they reside at the hardware or firmware level

and go from address 0 (the first sector on the disk) to the last sector on the disk. Clusters and their

addresses are specific to a logical disk drive, which is a disk partition.

Disk Partitions

Many hard disks are partitioned, or divided, into two or more sections. A partition is a logical

drive. Windows OSs can have three primary partitions followed by an extended partition that can


contain one or more logical drives. Someone who wants to hide data on a hard disk can create hidden

partitions or voids—large unused gaps between partitions on a disk drive. The unused space between

partitions is called the partition gap. It‘s possible to create a partition, add data to it, and then remove

references to the partition so that it can be hidden in Windows. If data is hidden in this partition gap, a

disk editor utility could be used to access it. One way to examine a partition‘s physical level is to use

a disk editor, such as WinHex or Hex Workshop. These tools enable you to view file headers and

other critical parts of a file. Both tasks involve analyzing the key hexadecimal codes the OS uses to

identify and maintain the file system.

The Master Boot Record (MBR) is located at sector 0 of the disk drive. In a hexadecimal

editor, such as WinHex, you can find the first partition starting at offset 0x1BE. The second partition

starts at 0x1CE, the third partition starts at 0x1DE, and the fourth partition starts at 0x1EE. The file

system‘s hexadecimal code is offset 3 bytes from 0x1BE for the first partition. The sector address of

where this partition starts on the drive is offset 8 bytes from 0x1BE. The number of sectors assigned

to the partition are offset 12 bytes for position 0x1BE. For the extended part of the drive, all partitions

are logical partitions. In the first logical partition‘s boot sector, there‘s a partition table similar to the

MBR.

Examining FAT Disks

File Allocation Table (FAT) is the file structure database that Microsoft designed for floppy

disks. It‘s used to organize files on a disk so that the OS can find the files it needs. Since its

development, other OSs, such as Linux and Macintosh, can format, read, and write to FAT storage

devices such as USB drives and SD cards. The FAT database is typically written to a disk‘s outermost

track and contains filenames, directory names, date and time stamps, the starting cluster number, and

file attributes (archive, hidden, system, and read-only).

There are three current versions of FAT—FAT16, FAT32, and exFAT (used by Xbox game

systems)—and three older FAT formats, which are FATX, Virtual FAT (VFAT), and FAT12. The

FAT version in Microsoft DOS 6.22 had a limitation of eight characters for filenames and three

characters for extensions. The following list summarizes the evolution of FAT versions: • FAT12 — This version is used specifically for floppy disks, so it has a limited amount of storage space. It was originally designed for MS-DOS 1.0, the first Microsoft OS, used for floppy disk drives and drives up to 16 MB. • FAT16 — To handle larger disks, Microsoft developed FAT16, which is still used on older Microsoft OSs, such as MS-DOS 3.0 through 6.22, Windows 95 (first release), and Windows NT 3.5 and 4.0. FAT16 supports disk partitions with a maximum storage capacity of 4 GB. • FAT32 — When disk technology improved and disks larger than 2 GB were developed, Microsoft released FAT32, which can access larger drives. • exFAT — Developed for mobile personal storage devices, such as flash memory devices, secure

digital eXtended capacity (SDCX), and memory sticks. The exFAT file system can store very large

files, such as digital images, video, and audio files. • VFAT — Developed to handle files with more than eight-character filenames and three character extensions; introduced with Windows 95. VFAT is an extension of other FAT file systems. Cluster sizes vary according to the hard disk size and file system. Clusters can range from 1 sector consisting of 512 bytes to 128 sectors of 64 KB.

Microsoft OSs allocate disk space for files by clusters. This practice results in drive slack,

composed of the unused space in a cluster between the end of an active file‘s content and the end of

the cluster. Drive slack includes RAM slack (found mainly in older Microsoft OSs) and file slack. In

newer Windows OSs, when data is written to disk, the remaining RAM slack is zeroed out and

contains no RAM data. When the OS stores data in a FAT file system, it assigns a starting cluster

position to a file. Data for the file is written to the first sector of the first assigned cluster.


When this first assigned cluster is filled and runs out of room, FAT assigns the next available

cluster to the file. If the next available cluster isn‘t contiguous to the current cluster, the file becomes

fragmented. On rare occasions, such as a system failure or sabotage, these cluster chains can break. If

they do, data can be lost because it‘s no longer associated with the previous chained cluster. FAT

looks forward for the next cluster assignment but doesn‘t provide pointers to the previous cluster.

Rebuilding these broken chains can be difficult.

Deleting FAT Files When a file is deleted in Windows Explorer or with the MS-DOS delete

command, the OS inserts a HEX E5 (0xE5) in the filename‘s first letter position in the associated

directory entry. This value tells the OS that the file is no longer available and a new file can be written

to the same cluster location. In the FAT file system, when a file is deleted, the only modifications

made are that the directory entry is marked as a deleted file, with the HEX E5 character replacing the

first letter of the filename, and the FAT chain for that file is set to 0. The data in the file remains on

the disk drive. The area of the disk where the deleted file resides becomes unallocated disk space (also

called ―free disk space‖).

Examining NTFS Disks

NT File System (NTFS) was introduced when Microsoft created Windows NT and is still the

main file system in Windows 8. Each generation of Windows since NT has included minor changes in

NTFS configuration and features. The NTFS design was partially based on, and incorporated many

features from, Microsoft‘s project for IBM with the OS/2 operating system; in this OS, the file system

was High Performance File System (HPFS). When Microsoft created Windows NT, it provided

backward-compatibility so that NT could read OS/2 HPFS disk drives. Since the release of Windows

2000, this backward-compatibility is no longer available.

NTFS offers substantial improvements over FAT file systems. It provides more information

about a file, including security features, file ownership, and other file attributes. With NTFS, you also

have more control over files and folders (directories) than with FAT file systems. NTFS was

Microsoft‘s move toward a journaling file system. The system keeps track of transactions such as file

deleting or saving. This journaling feature is helpful because it records a transaction before the system

carries it out. That way, in a power failure or other interruption, the system can complete the

transaction or go back to the last good setting.

In NTFS, everything written to the disk is considered a file. On an NTFS disk, the first data

set is the Partition Boot Sector, which starts at sector [0] of the disk and can expand to 16 sectors.

Immediately after the Partition Boot Sector is the Master File Table (MFT). The MFT, similar to FAT

in earlier Microsoft OSs, is the first file on the disk. An MFT file is created at the same time a disk

partition is formatted as an NTFS volume and usually consumes about 12.5% of the disk when it‘s

created. As data is added, the MFT can expand to take up 50% of the disk. An important advantage of

NTFS over FAT is that it results in much less file slack space.

NTFS (and VFAT for long filenames) also uses Unicode, an international data format. Unlike

the American Standard Code for Information Interchange (ASCII) 8-bit configuration, Unicode uses

an 8-bit, a 16-bit, or a 32-bit configuration. These configurations are known as UTF-8 (Unicode

Transformation Format), UTF-16, and UTF-32. For Western-language alphabetic characters, UTF-8

is identical to ASCII.

NTFS System Files

Since everything on an NTFS disk is a file, the first file, the MFT, contains information about

all files on the disk, including the system files the OS uses. In the MFT, the first 15 records are

reserved for system files. Records in the MFT are referred to as metadata. In the NTFS MFT, all files

and folders are stored in separate records of 1024 bytes each. Each record contains file or folder


information. This information is divided into record fields containing metadata about the file or folder and the file‘s data or links to the file‘s data. A record field is referred to as an attribute ID.

File or folder information is typically stored in one of two ways in an MFT record: resident

and nonresident. For very small files, about 512 bytes or less, all file metadata and data are stored in

the MFT record. These types of records are called resident files because all their information is stored

in the MFT record. Files larger than 512 bytes are stored outside the MFT. The file or folder‘s MFT

record provides cluster addresses where the file is stored on the drive‘s partition. These cluster

addresses are called data runs. This type of MFT record is referred to as ―nonresident‖ because the

file‘s data is stored in its own separate file outside the MFT. Each MFT record starts with a header

identifying it as a resident or nonresident attribute. The first 4 bytes (characters) for all MFT records

are FILE. The header information contains additional data specifying where the first attribute ID

starts, which is typically at offset 0x14 from the beginning of the record.

NTFS Encrypting File System

When Microsoft introduced Windows 2000, it added optional built-in encryption to NTFS

called Encrypting File System (EFS). EFS uses public key and private key methods of encrypting

files, folders, or disk volumes (partitions). Only the owner or user who encrypted the data can access

encrypted files. The owner holds the private key, and the public key is held by a certification

authority, such as a global registry, network server, or company such as VeriSign.

When EFS is used in Windows 2000 and later, a recovery certificate is generated and sent to

the local Windows administrator account. The purpose of the recovery certificate is to provide a

mechanism for recovering files encrypted with EFS if there‘s a problem with the user‘s original

private key. The recovery key is stored in one of two places. When a network user initiates EFS, the

recovery key is sent to the local domain server‘s administrator account. On a stand-alone workstation,

the recovery key is sent to the local administrator account.

EFS Recovery Key Agent

The Recovery Key Agent implements the recovery certificate, which is in the Windows

administrator account. Windows administrators can recover a key in two ways: through Windows or

from an MS-DOS command prompt. These three commands are available from the MS-DOS

command prompt: • cipher • copy • efsrecvr (used to decrypt EFS files)

Deleting NTFS Files

Typically, you use Windows or File Explorer to delete files from a disk. When a file is

deleted in Windows NT and later, the OS renames it and moves it to the Recycle Bin. Another method

is using the del (delete) MS-DOS command. This method doesn‘t rename and move the file to the

Recycle Bin, but it eliminates the file from the MFT listing in the same way FAT does. When you

delete a file in Windows or File Explorer, you can restore it from the Recycle Bin.

The OS takes the following steps when you delete a file or a folder in Windows or File Explorer:

1. Windows changes the filename and moves the file to a subdirectory with a unique identity in the Recycle Bin. 2. Windows stores information about the original path and filename in the Info2 file, which is the control file for the Recycle Bin. It contains ASCII data, Unicode data, and the date and time of deletion for each file or folder. NTFS files deleted at an MS-DOS command prompt function much like FAT files. (The following steps also apply when a user empties the Recycle Bin.) The OS performs the following tasks:


1. The associated clusters are designated as free—that is, marked as available for new data. 2. The $Bitmap file attribute in the MFT is updated to reflect the file‘s deletion, showing that this space is available. 3. The file‘s record in the MFT is marked as being available. 4. VCN/LCN cluster locations linked to deleted nonresident files are then removed from the original MFT record. 5. A run list is maintained in the MFT of all cluster locations on the disk for non-resident files. When the list of links is deleted, any reference to the links is lost.

Resilient File System

With the release of Windows Server 2012, Microsoft created a new file system: Resilient File

System (ReFS). ReFS is designed to address very large data storage needs, such as the cloud. The

following features are incorporated into ReFS‘s design:

• Maximized data availability • Improved data integrity • Designed for scalability

ReFS is an outgrowth of NTFS designed to provide a large-scale data storage access

capability. It‘s intended only for data storage, so as of this writing, it can‘t be used as a boot drive.

Windows 8/8.1 and Windows Server 2012 are the only Windows OSs that can access ReFS disk

drives. ReFS uses disk structures similar to the MFT in NTFS. Its storage engine uses a B1-tree sort

method for fast access to large data sets.

Understanding Whole Disk Encryption

Loss of personal identity information (PII) and trade secrets caused by computer theft has

become more of a concern. Company PII might consist of employees‘ full names, home addresses,

and Social Security numbers. With this information, criminals could easily apply for credit card

accounts in these employees‘ names. This feature creates new challenges in examining and recovering

data from drives. Whole disk encryption tools offer the following features that forensics examiners

should be aware of: • Preboot authentication, such as a single sign-on password, fingerprint scan, or token (USB device) • Full or partial disk encryption with secure hibernation, such as activating a password protected screen saver • Advanced encryption algorithms, such as Advanced Encryption Standard (AES) and International Data Encryption Algorithm (IDEA) • Key management function that uses a challenge-and-response method to reset passwords or passphrases

WDE tools encrypt each sector of a drive separately. Many of these tools encrypt the drive‘s

boot sector to prevent any efforts to bypass the secured drive‘s partition. To examine an encrypted

drive, you must decrypt it first. The biggest drawback to decrypting a drive is the several hours

required to read, decrypt, and write each sector. The larger the drive, the longer decryption takes.

After you‘ve decrypted the drive, however, you can use standard acquisition methods to retrieve data.

Digital Forensics Tool

Forensics tools are constantly being developed, updated, patched, revised, and discontinued.

Therefore, checking vendors‘ Web sites routinely to look for new features and improvements is important. These improvements might address a difficult problem you‘re having in an investigation.

Types of Digital Forensics Tools

Digital forensics tools are divided into two major categories: hardware and software.


Hardware Forensics Tools

Hardware forensics tools range from simple, singlepurpose components to complete computer

systems and servers. For example, the Tableau T35es-R2 SATA/IDE eSATA bridge is a single-

purpose component that makes it possible to access a SATA or an IDE drive with one device. Some

examples of complete systems are Digital Intelligence F.R.E.D. systems, DIBS Advanced Forensic

Workstations, Forensic Computers‘ Forensic Examination Stations and portable units and H-11 Digital Forensics systems.

Software Forensics Tools

Software forensics tools are grouped into command-line applications and GUI applications.

Some tools are specialized to perform one task. For example, SafeBack was designed as a command-

line disk acquisition tool from New Technologies, Inc. (NTI). Other tools are designed to perform

many different tasks. For example, PassMark Software OSForensics, Technology Pathways

ProDiscover, X-Ways Forensics, Guidance Software EnCase, and AccessData FTK are GUI tools

designed to perform most forensics acquisition and analysis functions. Software forensics tools are

commonly used to copy data from a suspect‘s drive to an image file. Many GUI acquisition tools can

read all structures in an image file as though the image were the original drive and have the capability

to analyze image files.

Tasks Performed by Digital Forensics Tools

All digital forensics tools, both hardware and software, perform specific functions. When

you‘re testing new tools, you might find it helpful to follow guidelines set up by NIST‘s Computer

Forensics Tool Testing (CFTT) program. The following categories of functions are meant as

guidelines for evaluating digital forensics tools, with subfunctions for refining data analysis and

recovery and ensuring data quality:

• Acquisition

• Validation and verification

• Extraction • Reconstruction • Reporting

NIST‘s CFTT and other groups include additonal functions, such as data acquistion, data

extraction from mobile devices, file reconstruction, and string searching, that aren‘t included in these

guidelines.

Acquisition

Acquisition, the first task in digital forensics investigations, is making a copy of the original

drive, this procedure preserves the original drive to make sure it doesn‘t become corrupt and damage

the digital evidence.

Sub-functions in the acquisition category include the following: • Physical data copy • Logical data copy • Data acquisition format • Command-line acquisition • GUI acquisition • Remote, live, and memory acquisitions

Some digital forensics software suites, such as AccessData FTK, have separate tools for

acquiring an image. However, some investigators opt to use hardware devices, such as Tableau TD2,

Logicube Talon, VOOM HardCopy 3P, or Image MASSter Solo-4 Forensic unit from Intelligent

Computer Solutions, Inc., for acquiring an image. These hardware devices have built-in software for


data acquisition. No other device or program is needed to make a duplicate drive; however, you still

need forensics software to analyze the data. Two types of data-copying methods are used in software

acquisitions: physical copying of the entire drive and logical copying of a disk partition. Most

software acquisition tools include the option of imaging an entire physical drive or just a logical

partition. Usually, the situation dictates whether you make a physical or logical acquisition. One

reason to choose a logical acquisition is drive encryption.

Disk acquisition formats vary from raw data to vendor-specific proprietary. The raw data

format, typically created with the UNIX/Linux dd command, is a simple bit-for-bit copy of a data file,

a disk partition, or an entire drive. A raw imaging tool can copy data from one drive to another disk or

to segmented files. Because it‘s a true unaltered copy, you can view a raw image file‘s contents with

any hexadecimal editor, such as Hex Workshop or WinHex. Remote acquisition of files is common in

larger organizations. Enterprise-level companies are geographically diverse, so investigators might

not be able to get physical access to systems without traveling long distances. Popular tools, such as

AccessData and EnCase, can do remote acquisitions of forensics.

Validation and Verification

Validation and verification functions work hand in hand. Validation is a way to confirm that a

tool is functioning as intended, and verification proves that two sets of data are identical by

calculating hash values or using another similar method. Another related process is filtering, which

involves sorting and searching through investigation findings to separate good data and suspicious

data. Validating tools and verifying data are what allow filtering. All forensics acquisition tools have a

method for verification of the data-copying process that compares the original drive with the image.

For example, EnCase prompts you to obtain the MD5 hash value of acquired data, and FTK validates

MD5 and SHA-1 hash sets during data acquisition.

Hardware acquisition tools, such as Image MASSter Solo-4, can perform simultaneous MD5

and CRC-32 hashing during data acquisition. Whether you choose a software or hardware solution for

acquisition, make sure the tool has a hashing function for verification purposes. How data hashing is

used depends on the investigation, but using a hashing algorithm on the entire suspect drive and all its

files is a standard practice. When performing filtering, you separate good data from suspicious data.

Good data consists of known files, such as OS files, common programs (Microsoft Word, for

example), and standard files used in a company‘s day-to-day business.

Extraction

The extraction function is the recovery task in a digital investigation and is the most

challenging of all tasks to master. Recovering data is the first step in analyzing an investigation‘s data.

The following sub-functions of extraction are used in investigations: • Data viewing • Keyword searching • Decompressing or uncompressing • Carving • Decrypting • Bookmarking or tagging

Many digital forensics tools include a data-viewing mechanism for digital evidence and offer

several ways to view data, including logical drive structures, such as folders and files. These tools also

display allocated file data and unallocated disk areas with special file and disk viewers. Being able to

view this data in its normal form makes analyzing and collecting clues for the investigation easier.

Forensics tools have functions for searching for keywords of interest to the investigation. Using a

keyword search speeds up the analysis process, if used correctly; however, a poor selection of

keywords generates too much information. Another way to narrow down a search is by using word

lists created for a specific case.


DataLifter includes a feature that enables you to add other header values. There are many

compression or zip utilities, such as WinZip, 7Zip, and pzip. When a forensics tool encounters a

compressed file or a zip archive as part of a forensic image, it applies the correct algorithm for

uncompressing the files. For example, uncompressing Windows files is done with the Lempel-Ziv

algorithm, Lz32.dll. Other OSs and compression utilities use other algorithms.

A major challenge in digital investigations is analyzing, recovering, and decrypting data from

encrypted files or systems. Encryption can be used on a drive, disk partition, or file. Many e-mail services, such as Microsoft Outlook, provide encryption protection for .pst folders and messages. Encryption can be platform specific, such as Windows Encrypting File System (EFS) and BitLocker, or done with third-party tools, such as Pretty Good Privacy (PGP) and GnuPG.

After locating the evidence, the next task is to bookmark or tag it so that you can refer to it

later when needed. Many forensics tools use bookmarks to insert digital evidence into a report

generator, which produces a technical report in HTML or RTF format of the examination‘s findings.

When the report generator is started, bookmarks are loaded into the report.

Reconstruction

The purpose of having a reconstruction function in a forensics tool is to re-create a suspect

drive to show what happened during a crime or an incident. Another reason for duplicating a suspect

drive is to create a copy for other digital investigators, who might need a fully functional copy of the

drive so that they can perform their own acquisition, test, and analysis of the evidence. Reconstruction

is also done if a drive has been compromised by malware or a suspect‘s actions. The following are methods of reconstruction: • Disk-to-disk copy • Partition-to-partition copy • Image-to-disk copy • Image-to-partition copy

• Disk-to-image copy

• Rebuilding files from data runs and carving

There are several ways to re-create an image of a suspect drive. The ideal method was using

the same make and model disk as the suspect disk, but disk-to-disk copies are rarely used now. (A

partition-to-partition copy is very similar, but you use partitions instead of disks.) Typically, you copy

an image to another location, such as a partition, a physical disk. The simplest method of duplicating a

drive is using a tool that makes a direct disk-to-image copy from the suspect disk to the target

location. Many tools can perform this task. One free tool is the Linux dd command, but it has a major

disadvantage: It produces a flat, uncompressed file that‘s the same size as the source drive. Some

tools have proprietary formats that can be restored only by the same application that created them.

Reporting

To perform a forensics disk analysis and examination, you need to create a report. Before

Windows forensics tools were available, this process required copying data from a suspect drive and

extracting the digital evidence manually. The investigator then copied the evidence to a separate

program, such as a word processor, to create a report. File data that couldn‘t be read in a word

processor—databases, spreadsheets, and graphics, for example—made it difficult to insert

nonprintable characters, such as binary data, into a report. Typically, these reports weren‘t stored

electronically because investigators had to collect printouts from several different applications to

consolidate everything into one large paper report.


Newer forensics tools can produce electronic reports in a variety of formats, such as word-

processing documents, HTML Web pages, and Acrobat PDF files. The following are sub-functions of

the reporting function: • Bookmarking or tagging • Log reports • Report generator

Many forensics tools can produce a log report that records an investigator‘s activities and

incorporates evidence that was bookmarked or tagged during extraction. Then a built-in report

generator is used to create a report in a variety of formats. Reports generated by forensics tools are no

substitute for an investigator‘s report. Investigators need to be able to explain their decisions and the

output in more detail than a tool-generated report can produce.

Other Considerations for Tools

As part of the business planning for your lab, you should determine which tools offer the most

flexibility, reliability, and future expandability. The software tools you select should be compatible

with the next generation of OSs; for example, Windows 7 and later added features for compatibility

with mobile devices. As an investigator, it‘s your responsibility to find information on changes in new

hardware or software releases and changes planned for the next release. Another consideration when

maintaining a forensics lab is creating a software library containing older versions of forensics

utilities, OSs, and other programs. When purchasing newer and more versatile tools, you should also

ensure that your lab maintains older versions of software and OSs, such as Windows and Linux. If a

new software version fixes one bug but introduces another, you can use the previous version to

overcome problems caused by the new bug.

Digital Forensics Software Tools

The first tools that analyzed and extracted data from floppy disks and hard disks were MS-

DOS tools for IBM PC file systems. One of the first MS-DOS tools used for digital investigations was

Norton DiskEdit. This tool used manual processes that required investigators to spend considerable

time on a typical 500 MB drive. Eventually, programs designed for digital forensics were developed

for DOS, Windows, Apple, NetWare, and UNIX systems. One advantage of using command-line

tools for an investigation is that they require few system resources because they‘re designed to run in

minimal configurations. In fact, most tools fit on bootable media (USB drives, CDs, and DVDs).

Conducting an initial inquiry or a complete investigation with bootable media can save time and

effort. Most tools also produce a text report that fits on a USB drive or other removable media.

Some command-line forensics tools are created specifically for Windows command-line

interface (CLI) platforms; others are created for Macintosh and UNIX/Linux. For Windows platforms,

a number of companies, such as NTI, Digital Intelligence, Maresware, DataLifter, and ByteBack, are

recognized for their work in command-line forensics tools.

Linux Forensics Tools

SMART

SMART is designed to be installed on numerous Linux versions, including Gentoo, Fedora,

SUSE, Debian, Knoppix, Ubuntu, Slackware, and more. You can analyze a variety of file systems

with SMART. SMART includes several plug-in utilities. This modular approach makes it possible to

upgrade SMART components easily and quickly. SMART can also take advantage of multithreading

capabilities in OSs and hardware, a feature lacking in other forensics utilities. This tool is one of the

few that can mount different file systems, such as journaling file systems, in a read-only format.


Helix 3

One of the easiest suites to use is Helix because of its user interface. What‘s unique about

Helix is that you can load it on a live Windows system, and it loads as a bootable Linux OS from a

cold boot. Its Windows component is used for live acquisitions. Be aware, however, that some

international courts haven‘t accepted live acquisitions as a valid forensics practice. During corporate

investigations, often you need to retrieve RAM and other data, such as the suspect‘s user profile, from

a workstation or server that can‘t be seized or turned off. This data is extracted while the system is

running and captured in its state at the time of extraction. Make sure to keep a journal to record what

you‘re doing, however. To do a live acquisition, insert the Helix CD/DVD into the suspect‘s machine.

Kali Linux, Autopsy and Sleuth Kit

Kali Linux, formerly known as BackTrack, is another Linux Live CD used by many security

professionals and forensics investigators. It includes a variety of tools and has an easy-to-use KDE

interface. Sleuth Kit is a Linux forensics tool, and Autopsy is the GUI browser interface for accessing

Sleuth Kit‘s tools.

Other GUI Forensics Tools

Most GUI tools are put together as suites of tools. For example, the largest GUI tool

vendors—AccessData and Guidance Software—offer tools that perform most of the tasks. As with all

software, each suite has its strengths and weaknesses. GUI tools have several advantages, such as ease


of use, the capability to perform multiple tasks, and no requirement to learn older OSs. Their

disadvantages range from excessive resource requirements (needing large amounts of RAM, for

example) and producing inconsistent results because of the type of OS used. Another concern with

using GUI tools is that they create investigators‘ dependence on using only one tool.

Digital Forensics Hardware Tools

This section discusses computer hardware used for forensics investigations. Technology

changes rapidly, and hardware manufacturers have designed most computer components to last about 18 months between failures. Hardware is hardware; whether it‘s a rack-mounted server or a forensic workstation, eventually it fails. For this reason, you should schedule equipment replacements periodically—ideally, every 18 months if you use the hardware fulltime.

Forensic Workstations

Many hardware vendors offer a wide range of forensic workstations that you can tailor to

meet your investigation needs. The more diverse your investigation environment, the more options

you need. In general, forensic workstations can be divided into the following categories: • Stationary workstation — A tower with several bays and many peripheral devices • Portable workstation — A laptop computer with almost as many bays and peripherals as a stationary workstation • Lightweight workstation — Usually a laptop computer built into a carrying case with a small selection of peripheral options When considering options to add to a basic workstation, keep in mind that PCs have limitations on how many peripherals they can handle. The more peripherals you add, the more potential problems you might have, especially if you‘re using an older version of Windows.

Building Your Own Workstation

Building a forensic workstation isn‘t as difficult as it sounds but can quickly become

expensive if you aren‘t careful. If you have the time and skill to build your own forensic workstation,

you can customize it to your needs and save money, although you might have trouble finding support

for problems that develop. If you decide that building a forensic workstation is beyond your skills,

some vendors still offer workstations designed for digital forensics, such as the F.R.E.D. unit from

Digital Intelligence or hardware mounts from ForensicPC that convert a standard server or PC into a

forensic workstation. Having a vendor-supplied workstation has its advantages. If you aren‘t skilled in

hardware maintenance and repair, having vendor support can save you time and frustration when you

have problems. Of course, you can always mix and match components to get the capabilities you need

for your forensic workstation.

Using a Write-Blocker

The first item you should consider for a forensic workstation is a write-blocker. Write-

blockers protect evidence disks by preventing data from being written to them. Software and hardware

write-blockers perform the same function but in a different fashion. Software write-blockers, such as

PDBlock from Digital Intelligence, typically run in a shell mode. If you attempt to write data to the

blocked drive, an alarm sounds, advising that no writes have occurred. PDBlock can run only in a true

DOS mode, however, not in a Windows CLI. Many vendors have developed write-blocking devices

that connect to a computer through FireWire, USB 2.0 and 3.0, SATA, PATA, and SCSI controllers.

Most of these write-blockers enable you to remove and reconnect drives without having to shut down

your workstation, which saves time in processing the evidence drive.

Validating and Testing Forensics Software


Now that you have selected some tools to use, you need to make sure the evidence you recover and analyze can be admitted in court. To do this, you must test and validate your software.

Using National Institute of Standards and Technology Tools

The National Institute of Standards and Technology (NIST) publishes articles, provides tools,

and creates procedures for testing and validating computer forensics software. Software should be

verified to improve evidence admissibility in judicial proceedings. NIST sponsors the CFTT project to

manage research on forensics tools. Your lab must meet the following criteria and keep accurate

records so that when new software and hardware become available, testing standards are in place for

your lab: • Establish categories for digital forensics tools — Group digital forensics software according to categories, such as forensics tools designed to retrieve and trace e-mail. • Identify forensics category requirements — For each category, describe the technical features or functions a forensics tool must have. • Develop test assertions — Based on the requirements, create tests that prove or disprove the tool‘s capability to meet the requirements. • Identify test cases — Find or create types of cases to investigate with the forensics tool, and identify information to retrieve from a sample drive or other media. • Establish a test method — Considering the tool‘s purpose and design, specify how to test it. • Report test results — Describe the test results in a report that complies with ISO 17025, which requires accurate, clear, unambiguous, and objective test reports. You can also use the RDS to locate and identify known bad files, such as illegal images and computer viruses, on a suspect drive.

Using Validation Protocols

After retrieving and examining evidence data with one tool, you should verify your results by

performing the same tasks with other similar forensics tools. Although this step might seem

unnecessary, you might be asked on the witness stand ―How did you verify your results?‖ To satisfy

the need for verification, you need at least two tools to validate software or hardware upgrades. The

tool you use to validate the results should be well tested and documented. Investigators must be

confident in a tool‘s capability to produce consistent and accurate findings during analysis.

Understanding how the tool works is equally important, as you might not have vendor support in a

courtroom.

Digital Forensics Examination Protocol

1. First, conduct your investigation of the digital evidence with one GUI tool. 2. Then perform the same investigation with a disk editor to verify that the GUI tool is seeing the same digital evidence in the same places on the test or suspect drive‘s image. 3. If a file is recovered, obtain the hash value with the GUI tool and the disk editor, and then compare the results to verify whether the file has the same value in both tools.

Digital Forensics Tool Upgrade Protocol

In addition to verifying your results by using two disk-analysis tools, you should test all new

releases and OS patches and upgrades to make sure they‘re reliable and don‘t corrupt evidence data.

New releases and OS upgrades and patches can affect the way your forensics tools perform. If you

determine that a patch or upgrade isn‘t reliable, don‘t use it on your forensic workstation until the

problem has been fixed. One of the best ways to test patches and upgrades is to build a test hard disk

to store data in unused space allocated for a file, also known as file slack. You can then use a

forensics tool to retrieve it. If you can retrieve the data with that tool and verify your findings with a

second tool, you know the tool is reliable.


UNIT V ANALYSIS AND VALIDATION

Validating Forensics Data – Data Hiding Techniques – Performing Remote Acquisition –

Network Forensics – Email Investigations – Cell Phone and Mobile Devices Forensics.

Validation vs Verification Validation is the confirmation by examination and the provision of objective evidence that a tool,

technique or procedure functions correctly and as intended. Verification is the confirmation of a

validation with laboratories tools, techniques and procedures.

Demands of EE tools validation and verification The process of using automated software has served law enforcement and the courts very well, and

experienced detectives and investigators have been able to use their welldeveloped policing skills, in

conjunction with the automated software, so as to provide sound evidence. However, the growth in

the field has created a demand for new software (or increased functionality to existing software) and

a means to verify that this software is truly forensic, i.e. capable of meeting the requirements of the

‗trier of fact‘. Another factor demanding EE tools validation and verification is for the EE discipline to

move inline with other established forensic disciplines.

Trustworthiness of digital evidence The validity and credibility (i.e. the ‗‗trustworthiness‘‘) of electronic evidence are of paramount

importance given the forensic (for court) context of the discipline. Nowadays, the collection,

preservation and analysis of electronic evidence in the EE process mainly rely on EE tools (hardware

or software). If the EE tools or their application procedures are incorrect or not as intended, their

results, i.e. digital evidence, will be questioned or may be inadmissible for court. In other words, the

trustworthiness of digital evidence relies on the scientific application of the process, the analysis and

the correct utilization and functioning of computer forensic tools. However, the EE community is

now facing a complex and dynamic environment with regard to EE tools.

On one hand, the technology field has become very dynamic and the types of digital devices, such as

notebook computers, iPods, cameras and mobile phones, have changed incredibly rapidly. And thus

the digital evidence acquired from those devices has also changed. On the other hand, in such a

dynamic technological environment, there is no individual tool that is able to meet all the needs of a

particular investigation. Therefore, the world has been witnessing an explosive boom in EE tools in

the last decade.

Although these EE tools are currently being used by law enforcement agencies and EE investigators,

we must be aware that while some of them (e.g. EnCase, FTK) were originally developed for the

forensic purpose, others were designed to meet the needs of particular interest groups (e.g.

JkDefrag (Kessels) is a disk defragmenter and optimizer for Windows 2000/2003/XP/Vista/

2008/X64). Hence, to guarantee that the digital evidence is forensically sound, EE investigators must

validate and verify the EE tools that they are using to collect, preserve and analyze digital evidence.

Tool orientated VV approach:


The validation and verification work of EE tools conducted by the vendors (e.g. Encase from

Guidance Software and FTK from Access data) falls into this category. Traditionally, in the digital

forensic domain, the EE software tool, as an unseparated entity, is treated as the target of validation

and verification. Usually, axiomatic proofs and/or reproducible experiments (testing) are required

to perform the VV. To validate the target, the test cases need to be defined, the tests need to be run

and the measured results need to be verified.

Functionality orientated VV approach:

NIST/CFTT and DFTT perform the validation and verification of EE tools from another angle:

functionality driven. Instead of targeting the EE software tool, they start the validation by looking at

the EE discipline itself. They identify various activities required in forensic investigation procedures

and separate them into functionalities or categories, such as write protection, disk imaging, string

searching, etc. Then, they specify requirements that need to be fulfilled for each function category.

Based on the requirements specification, testing cases are then designed to test functions of

candidate EE tools. The difference between the functionality orientated VV approach and the tool

orientated VV approach is that the former does not treat a EE tool as a single entity.

Digital forensics is very much an emerging discipline and has developed in an ad-hoc fashion

(Beckett and Slay, 2007) without much of the scientific rigour of other scientific disciplines, such as

DNA, ballistics, and fingerprints. Although the scientific foundations of EE field and the functions

which together make up the EE process exist, they have never been formally or systematically

mapped and specified (scientific foundations), or stated and characterized (functions). Though there

have been recent efforts to formalize a definitive theory of digital forensics and research

dissertations that focus on the process model have started to appear (Brian, 2006), there is still no

adequate description of any depth of the specific functions of the discipline.

PACKET SNIFFERS: A sniffer is software that collects traffic flowing into and out of a computer attached to a network.

Network engineers, system administrators and security professionals use sniffers to monitor and

collect information about different communications occurring over a network. Sniffers are used as

the main source for data collection in Intrusion Detection Systems (IDS) to match packets against a

rule-set designed to notify anything malicious or strange. Law enforcement agencies use sniffers to

gather specific traffic in a network and use the data for investigative analysis.

Ethereal Ethereal is an open source software and widely used as a network packet analyzer. It captures

packets live from the network. It displays the information in the headers of all the protocols used in

the transmission of the packets captured. It filters the packets depending on user needs. Ethereal

allows search for packets with some specifications. It gives better representation to understand the

results easily by using a colorized display of packets belonging to different protocols.

WinPcap and AirPcap WinPcap is the packet capture tool used to capture the packets intercepted at the network interface

of a system running the Windows Operating System. WinPcap is the tool used for link-layer network


access in Windows. WinPcap includes a network statistics engine and provides support for kernel-

level packet filtering and remote packet capture.

AirPcap is the packet capture tool for the IEEE 802.11b/g Wireless LAN interfaces. This tool is

currently available only for Windows systems. AirPcap can be used to capture the control frames

(ACK, RTS, CTS), management frames (Beacon, Probe Requests and Responses, Authentication) and

data frames of the 802.11 traffic. The AirPcap adapter captures the per-packet power information,

which can be used to detect weak signal areas and measure the transmission efficiency of the

wireless devices.

IP TRACEBACK TECHNIQUES Masquerade attacks can be produced by spoofing at the link-layer (e.g., using a different MAC

address than the original), at the Internet layer (e.g., using a different source IP address than the

original), at the transport layer (e.g., using a different TCP/IP port than the original one), at the

application layer (e.g., using a different email address than the original). Reconstruction of the attack

path back to the originating attacker h1 may not be a straightforward process because of possible

spoofing at different layers of the TCP/IP protocol stack and also the intermediate hosts becoming

compromised hosts, called stepping-stone, and acting as a conduit for the attacker‘s communication.

The security functions practiced in existing networks may also preclude the capability to follow the

reverse path.

Input Debugging After recognizing that it is being attacked, the victim develops an attack signature that describes a

common feature contained in all the attack packets. The victim communicates this attack signature

to the upstream router that sends it the attack packets. Based on this signature, the upstream router

employs filters that prevent the attack packets from being forwarded through an egress port and

determines which ingress port they arrived on. The process is then repeated recursively on the

upstream routers, until the originating site is reached or the trace leaves the boundary of the

network provider or the Internet Service Provider (ISP).

Controlled Flooding The victim uses a pre-generated map of the Internet topology to iteratively select hosts that could

be coerced to flood each of the incoming links of the upstream router. Since the router buffer is

shared by packets coming across all incoming links, it is possible that the attack packets have a

higher probability of being dropped due to this flooding. By observing changes in the rate of packets

received from the attacker, the victim infers the link through which the attack packet would have

come to the upstream router.

EMAIL FORENSICS: Email is one of the most common ways people communicate, ranging from internal meeting

requests, to distribution of documents and general conversation. Emails are now being used for all

sorts of communication including providing confidentiality, authentication, non-repudiation and data

integrity. As email usage increases, attackers and hackers began to use emails for malicious

activities. Spam emails are a major source of concern within the Internet community. Emails are


more vulnerable to be intercepted and might be used by hackers to learn of secret communication.

Email forensics refers to studying the source and content of electronic mail as evidence, identifying

the actual sender and recipient of a message, date/time it was sent and etc.

Emails frequently contain malicious viruses, threats and scams that can result in the loss of data,

confidential information and even identity theft. The tools described in this section provide an easy-

to-use browser format, automated reporting and easy tool bar access features. The tools help to

identify the point of origin of the message, trace the path traversed by the message (used to identify

the spammers) and also to identify the phishing emails that try to obtain confidential information

from the receiver.

WEB FORENSICS: The predominant web browsers in use today are Microsoft‘s Internet Explorer (IE) and the Firefox/

Mozilla/ Netscape family. Each of these browsers saves, in their own unique formats, the web

browsing activity (also known as web browsing history) of the different users who have accounts on

a machine. IE stores the browsing history of a user in the index.dat file and the Firefox/ Mozilla/

Netscape family browsers save the web activity in a file named history.dat. These two files are

hidden files. So, in order to view them, the browser should be setup to show both hidden files and

system files. One cannot easily delete these two files in any regular way.

There is also no proof that deleting these files has sped up the browsing experience of the users.

Web forensics deals with gathering critical information related to a crime by exploring the browsing

history of a person, the number of times a website has been visited, the duration of each visit, the

files that have been uploaded and downloaded from the visited website, the cookies setup as part of

the visit and other critical information.

Mobile Forensics Mobile phone proliferation is on the increase with the worldwide cellular subscriber base reaching 4

billion by the year end of 2008. While mobile phones outsell personal computers three to one,

mobile phone forensics still lags behind computer forensics. Even when comparing sales figures of

smart mobile phone devices which have some Personal Digital Assistant (PDA) capabilities, to the

sale figures of the actual PDA devices, smart mobile phones sales continued to grow while the PDA

figures continue to decline. Data acquired from mobile phones continues to be used as evidence in

criminal, civil and even high profile cases. However, validated frameworks and techniques to acquire

mobile phone data are virtually non-existent.

The need for mobile phone handset forensics • Use of mobile phones to store and transmit personal and corporate information

• Use of mobile phones in online transactions

• Law enforcement, criminals and mobile phone devices

Use of mobile phones to store and transmit personal and corporate information


Mobile phones applications are being developed in a rapid pace. Word processors, spreadsheets,

and database-based applications have already been ported to mobile phone devices. The mobile

phone‘s ability to store, view and print electronic documents transformed these devices into mobile

offices.

The ability to send and receive Short Message Service (SMS) messages also transformed mobiles into

a message centre. In India alone, nearly 1.5 billion (1,492,400,769) text messages (SMS) were sent

per week between January and May, 2008, the Mobile Data Association (MDA) said. SMS was

further upgraded to Enhanced Messaging Service (EMS) and saw some added features while the

latest upgrade to Multimedia Messaging Service (MMS) added support for multimedia objects and

seamless integration with email gateways that enabled users to send content rich emails using the

MMS service. In India, more than 10 million (10,734,555) pictures and video messaging (MMS) were

sent per week — a year on year growth of 30 percent.

Law enforcement, criminals and mobile phone devices The gap between law enforcement and organised crime is still considerable when it comes to the

utilisation of mobile phone technologies. Mobile phones and pagers were used in the early 1980s by

criminal organisations as a tool to evade capture as well as a means to facilitate everyday

operations. Ironically, while it took decades to convince legitimate businesses that mobile

connectivity can improve their operations, just about every person involved at any level of crime

already knew in the early 1980s that mobile phones can provide a substantial return on investment.

On the other hand, law enforcement and digital forensics still lag behind when it comes to dealing

with digital evidence obtained from mobile devices.

Forensic Tools and Toolkits Available Early mobile phones did not have the capacity to store large amounts of information so law

enforcement officers did not need to access mobile phone handsets to get information on a suspect.

The focus was more on phone records from the telecommunications companies. Nowadays, mobile

phones have large storage capacity and a wide array of applications and connectivity options besides

connectivity with the telecommunications provider. Mobile phone forensic tools and toolkits are still

immature in dealing with these advances in mobile phone technology. Mobile forensic toolkits are

developed by third party companies and the toolkits are not independently verified or tested for

forensic soundness.

The developers of the toolkits admit to using both, manufacturer supplied and self developed

commands and access methods to gain data access to memory on mobile devices. The tools often

limit themselves to one or more phone manufacturer handsets with a limited number of devices

supported. Some of the tools are also limited when it comes to connectivity options when it comes

to acquisition of data from the handset. For example, some tools are limited to wired connections as

opposed to Infrared (IrDA) and Bluetooth access to data on mobile devices. Moreover, while some

toolkits provide acquisition capabilities, they do not provide examination or reporting facilities.

Processor Components and Speed Intel has already demonstrated a 1GHz processor for mobile devices. In addition to this high

processing speed, smart mobile phone devices are showing the trend of using System on Chip (SoC)


technology. This technology allows the processor to incorporate a set of distinct functionalities in

the same package which reduces the number of chips required by it as well as incorporating a

considerable amount of built-in memory. This change in processor architecture may have an

undesirable impact on mobile forensics.

Mobile Phone Evidence Guides There are a number of guides that briefly mention potential evidence on mobile phone devices. In

this section, some of these guides will be highlighted and their shortcomings explained. The Best

Practices for Seizing Electronic Evidence published by the United States Secret Service (USSS)

referred to mobile phones as ―Wireless Telephones‖ under the ―Other Electronic Storage Devices‖

heading (USSS, 2006). The National Institute of Justice (NIJ), which is under the United States

Department of Justice lists mobile phones under the heading of ―Telephones‖ in their ―Electronic

Crime Scene Investigation: A guide for First Responders‖ publication.