Transport level security: UNIT 4: PART 2

Sockets Layer (SSL) and the follow-on Internet standard known as Transport Layer Security (TLS).

Transport layer security- architecture

SSL Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol
but rather two layers of protocols.
The SSL Record Protocol provides basic security services to various higher layer protocols.

Two important SSL concepts are the SSL session and the SSL connection.
• SSL Connection: A connection is a transport that provides a suitable type of service. For SSL, such connections
are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.

• SSL Session: An SSL session is an association between a client and a server. Sessions are created by the
Handshake Protocol. Sessions define a set of cryptographic security parameters which can be shared among
multiple connections.

A session state is defined by the following parameters.

• Session identifier: An arbitrary byte sequence chosen by the server to identify a session state.
• Peer certificate: An X509.v3 certificate of the peer.
• Compression method: The algorithm used to compress data prior to encryption.
• Cipher spec: To calculate message authentication code DES or SHA used.
• Master secret: 48-byte secret shared between the client and the server.
• Is resumable: A flag indicating whether the session can be used to initiate new connections.
A connection state is defined by the following parameters.
• Server and client random: Byte sequences that are chosen by the server and client for each connection.
• Server write MAC secret: The secret key used in MAC operations on data sent by the server.
• Client write MAC secret: The secret key used in MAC operations on data sent by the client.
• Server write key: The secret encryption key for data encrypted by the server and decrypted by the client.
• Client write key: The symmetric encryption key for data encrypted by the client and decrypted by the server.
SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
• Confidentiality: The Handshake Protocol defines a shared secret key for SSL payloads.
• Message Integrity: The Handshake Protocol also defines a shared secret key that is used to form a message
authentication code (MAC).

Step 1 is fragmentation. Each upper-layer message is fragmented into blocks of 214 bytes.
Step 2 Compression must be lossless.
Step 3 and Step 4 is to compute a message authentication code over the compressed data. For this purpose, a
shared secret key is used. The calculation is defined as

Step 5 is to prepare a header consisting of the following fields:

• Content Type (8 bits): The higher-layer protocol used to process the enclosed fragment.
• Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
• Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
• Compressed Length (16 bits): The length in bytes of the plaintext fragment.

Change cipher spec protocol

This protocol consists of a single message, which consists of a single byte with the value 1. The sole purpose of
this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be
used on this connection.
Alert protocol

Each message in this protocol consists of two bytes.

The first byte takes the value warning (1) or fatal (2) to convey the severity of the message.
 If the level is fatal, SSL immediately terminates the connection.
The second byte contains a code that indicates the specific alert.

FATAL ALERTS

unexpected_message: An inappropriate message was received.

• bad_record_mac: An incorrect MAC was received.
• decompression_failure: The decompression function received improper input (e.g., unable to decompress or
decompress to greater than maximum allowable length).
• handshake_failure: Sender was unable to negotiate an acceptable set of security parameters given the options
available.
• illegal_parameter: A field in a handshake message was out of range or inconsistent with other fields.

WARNING ALERTS.
• close_notify: Notifies the recipient that the sender will not send any more messages on this connection. Each
party is required to send a close_notify alert before closing the write side of a connection.
• no_certificate: May be sent in response to a certificate request if no appropriate certificate is available.
bad_certificate: A received certificate was corrupt (e.g., contained a signature that did not verify).
• unsupported_certificate: The type of the received certificate is not supported.
• certificate_revoked: A certificate has been revoked by its signer.
• certificate_expired: A certificate has expired.
• certificate_unknown: Some other unspecified issue arose in processing the certificate.

Handshake protocol

This protocol allows the server and client to authenticate each other and to negotiate an encryption and
MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record.
• Type (1 byte): Indicates one of ten messages.
• Length (3 bytes): The length of the message in bytes.
• Content : The parameters associated with this message.
Phase 1 This phase is used to initiate a logical connection and to establish the security capabilities that will
Establish be associated with it.
Security The exchange is initiated by the client, which sends a client_hello message with the following
Capabilities parameters:
• Version: The highest SSL version understood by the client.
• Random: A client-generated random structure consisting of a 32-bit timestamp and 28 bytes
generated by a secure random number generator. These values serve as nounces.
• Session ID: A variable-length session identifier.
• CipherSuite: This is a list that contains the combinations of cryptographic algorithms
supported by the client, in decreasing order of preference.
• Compression Method: This is a list of the compression methods the client supports.
Phase 2 The server begins this phase by sending its certificate if it needs to be authenticated; the message
Server contains one or a chain of X.509 certificates. The certificate message is required for any agreed-on
Authentication key exchange method except anonymous Diffie-Hellman. Note : if fixed Diffie-Hellman is used, this
and Key
certificate message functions as the server’s key exchange message because it contains the server’s
public Diffie-Hellman parameters.
Exchange
Next, a server_key_exchange message may be sent if it is required. It is not required in two
instances: (1) The server has sent a certificate with fixed Diffie-Hellman parameters
(2) a RSA key exchange is to be used.
 Phase 3 Upon receipt of the server_done message, the client should verify that the server provided a
Client valid certificate and check that the server_hello parameters are acceptable. If all is
Authentication satisfactory, the client sends one or more messages back to the server.
and Key If the server has requested a certificate, the client begins this phase by sending a certificate
Exchange message.
Next is the client_key_exchange message, which must be sent in this phase.
Phase 4 The client sends a change_cipher_spec message and copies the pending CipherSpec into
This phase the current CipherSpec.
completes The client then immediately sends the finished message under the new algorithms, keys, and
the setting secrets. The finished message verifies that the key exchange and authentication processes were
up of a successful. The content of the finished message is the concatenation of two hash values:
secure
connection

where Sender is a code that identifies that the sender is the client and handshake_messages
is all of the data from all handshake messages up to but not including this message.
In response to these two messages, the server sends its own change_cipher_spec message,
transfers the pending to the current CipherSpec, and sends its finished message. At this point, the
handshake is complete and the client and server may begin to exchange application-layer data

Heartbeat protocol : (RFC 6250)

The main advantage of this extension is to keep the secure

connection alive even if no data is exchanged
• Runs on top of the TLS Record Protocol

• Consists of two message types • heartbeat_request • heartbeat_response

• The use of the Heartbeat protocol is established during Phase 1 of the Handshake protocol

• The heartbeat serves two purposes

1. It assures the sender that the recipient is still alive

2. The heartbeat generates activity across the connection during idle periods, which avoids
closure by a firewall that does not tolerate idle connections

• The requirement for the exchange of a payload was designed into the Heartbeat protocol to
support its use in a connectionless version of TLS known as Datagram Transport Layer Security
(DTLS)

A heartbeat is a periodic signal generated by hardware / software to indicate/notify normal

operation or to synchronize other parts of a system.

SSL/TLS attacks

The attacks can be grouped into four general categories:

• Attacks on the handshake protocol

• Attacks on the record and application data protocols

• Attacks on the PKI (public key infrastructure)

• Other attacks
HTTPS : Refers to the combination of HTTP and SSL to implement secure communication between a
Web browser and a Web server • The HTTPS capability is built into all modern Web browsers

HTTPS – connection initiation

For HTTPS, the agent acting as the HTTP client also acts as the TLS client. The client initiates a connection to
the server on the appropriate port and then sends the TLS Client_Hello to begin the TLS handshake. When the
TLS handshake has finished, the client may then initiate the first HTTP request. All HTTP data is to be sent as
TLS application data.
There are three levels of awareness of a connection in HTTPS.
1>At the HTTP level, an HTTP client requests a connection to an HTTP server by sending a connection request
to the next lowest layer.
2>The next lowest layer is TCP, but it also may be TLS/SSL.
3>At the level of TLS, a session is established between a TLS client and a TLS server. This session can support
one or more connections at any time.
Note:TLS request to establish a connection begins with the establishment of a TCP connection between the
TCP entity on the client side and the TCP entity on the server side.

HTTP Connection closure

An HTTP client or server can indicate the closing of a connection by including the following line in an HTTP
record: Connection: close. This indicates that the connection will be closed after this record is delivered.
 The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on
the remote side, which will involve closing the underlying TCP connection.
At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol to send a
close_notify alert. TLS implementations must initiate an exchange of closure alerts before closing a
connection.

HTTP clients also must be able to cope with a situation in which the underlying TCP connection is terminated
without a prior close_notify alert and without a Connection: close indicator. Such a situation could
be due to a programming error on the server or a communication error that causes the TCP connection to drop.
However, the unannounced TCP closure could be evidence of some sort of attack. So the HTTPS client should
issue some sort of security warning when this occurs.
Unit-V

Digital signatures:

Digital signatures – properties

Message authentication protects two parties who exchange messages from any third party.

1. Mary may forge a different message and claim that it came from John. Mary would simply have to create a
message and append an authentication code using the key that John and Mary share.
2. John can deny sending the message. Because it is possible for Mary to forge a message, there is no way to prove
that John did in fact send the message
First scenario example: An electronic funds transfer takes place, and the receiver increases the amount of funds
transferred and claims that the larger amount had arrived from the sender.
Second scenario example: Email contains instructions to a stockbroker for a transaction that subsequently turns
out badly. The sender pretends that the message was never sent.

The digital signature must have the following properties:

• It must verify the author and the date and time of the signature.
• It must authenticate the contents at the time of the signature.
• It must be verifiable by third parties, to resolve disputes.
Attacks and forgeries
A denotes the user whose signature method is being attacked, and C denotes the attacker.
• Key-only attack: C only knows A’s public key.
• Known message attack: C is given access to a set of messages and their signatures.
• Generic chosen message attack: C chooses a list of messages before attempting to breaks A’s signature scheme,
independent of A’s public key. C then obtains from A valid signatures for the chosen messages. The attack is
generic, because it does not depend on A’s public key; the same attack is used against everyone.
• Directed chosen message attack: Similar to the generic attack, except that the list of messages to be signed is
chosen after C knows A’s public key but before any signatures are seen.
• Adaptive chosen message attack: C is allowed to use A as an “oracle.” This means that C may request from A
signatures of messages that depend on previously obtained message-signature pairs.

C can do any of the following with a non-negligible probability:

• Total break: C determines A’s private key.
• Universal forgery: C finds an efficient signing algorithm that provides an equivalent way of constructing
signatures on arbitrary messages.
• Selective forgery: C forges a signature for a particular message chosen by C.
• Existential forgery: C forges a signature for at least one message. C has no control over the message.
Consequently, this forgery may only be a minor nuisance to A.

Digital signature requirements:

• The signature must be a bit pattern that depends on the message being signed.
• The signature must use some information unique to the sender to prevent both forgery and denial.
• It must be relatively easy to produce the digital signature.
• It must be relatively easy to recognize and verify the digital signature.
• It must be computationally infeasible to forge a digital signature, either by constructing a new message for an
existing digital signature or by constructing a fraudulent digital signature for a given message.
• It must be practical to retain a copy of the digital signature in storage.

Direct digital signature

The term direct digital signature refers to a digital signature scheme that involves only the communicating parties
(source, destination).
 It is assumed that the destination knows the public key of the source.
 Confidentiality can be provided by encrypting the entire message plus signature with a shared secret key
(symmetric encryption).
Note: First we should do signature function and then an outer confidentiality function.

If the signature is the inner operation, then the recipient can store the plaintext message and its signature
for later use in dispute resolution.

???  The sender can claim that the private key was lost or stolen and that someone else forged his or her
signature.
Therefore we require every signed message to include a timestamp (date and time) and to require prompt
reporting of compromised keys to a central authority.

SCHNORR digital signature scheme

The Schnorr scheme minimizes the message-dependent amount of computation required to generate a
signature.
The message-dependent part of the signature generation requires multiplying a 2n-bit integer with an n-bit
integer.
p is a 1024-bit number, and q is a 160-bit number.
The first part of this scheme is the generation of a private/public key pair, which consists of the following steps.
NIST digital signature algorithm: we should write only DSA
The National Institute of Standards and Technology (NIST) has published Digital Signature Algorithm (DSA).

The DSA Approach

The DSA uses an algorithm that is designed to provide only the digital signature unction. Unlike RSA, it cannot
be used for encryption or key exchange. It is a public-key technique.

In the RSA approach, the message to be signed is input to a hash function that produces a secure hash code of
fixed length. This hash code is then encrypted using the sender’s private key to form the signature. Both the
message and the signature are then transmitted. The recipient takes the message and produces a hash code. The
recipient also decrypts the signature using the sender’s public key. If the calculated hash code matches the
decrypted signature, the signature is accepted as valid. Because only the sender knows the private key, only the
sender could have produced a valid signature.
In DSA approach here note the difference??--> The hash code is provided as input to a signature function along
with a random number k generated and a global public key (PUG).
Therefore these two extra details receiver should know i.e k and (PUG).
 lt is a signature consisting of two components, labeled s and r.
 r part is message independent.
At the receiving end, the hash code of the incoming message is generated. This plus the signature is input to a
verification function. The verification function also depends on the global public key as well as the sender’s public
key (PUa), which is paired with the sender’s private key. The output of the verification function is a value that is
equal to the signature component r if the signature is valid. The signature function is such that only the sender,
with knowledge of the private key, could have produced the valid signature.

The Digital Signature Algorithm in detail

To create a signature, a user calculates two quantities, r and s. (Signing process)

Note: k, H(M) and (PUG) will be used.

The receiver generates a quantity v that is a function of the public key components, the sender’s public key, and
the hash code of the incoming message (verifying process). If this quantity matches the r component of the
signature, then the signature is validated.
Note that the test at the end is on the value r, which does not depend on the message at all. Instead, r is a function
of k and the three global public-key components. The multiplicative inverse of k (mod q) is passed to a function
that also has as inputs the message hash code and the user’s private key. The structure of this function is such that
the receiver can recover r using the incoming message and signature, the public key of the user, and the global
public key.
1> Given the difficulty of taking discrete logarithms, it is infeasible for an opponent to recover k from r or
to recover x from s.
2> only computationally demanding task in signature generation is the exponential calculation gk mod p.
Because this value does not depend on the message to be signed, it can be computed ahead of time.
3> Indeed, a user could pre-calculate a number of values of r to be used to sign documents as needed. The
only other somewhat demanding task is the determination of a multiplicative inverse, k-1. Again, a
number of these values can be pre-calculated.
IP Security:

Applications of IPsec
• Secure branch office connectivity over the Internet: A company can build a secure virtual private network
over the Internet or over a public WAN. This enables a business to rely heavily on the Internet and reduce its need
for private networks, saving costs and network management overhead.
• Secure remote access over the Internet: An end user whose system is equipped with IP security protocols can
make a local call to an Internet Service Provider (ISP) and gain secure access to a company network. This reduces
the cost of toll charges for traveling employees and telecommuters.
• Establishing extranet and intranet connectivity with partners: IPsec can be used to secure communication
with other organizations, ensuring authentication and confidentiality and providing a key exchange mechanism.
• Enhancing electronic commerce security: Even though some Web and electronic commerce applications have
built-in security protocols, the use of IPsec enhances that security.

Benefits of IPsec
• When IPsec is implemented in a firewall or router, it provides strong security.
• IPsec in a firewall is resistant to bypass if all traffic from the outside must use IP.
• IPsec is below the transport layer (TCP, UDP) and so is transparent to applications.
There is no need to change software on a user or server system when IPsec is implemented in the firewall or
router.
• IPsec can be transparent to end users.
• IPsec can provide security for individual users if needed. This is useful for offsite workers and for setting up a
secure virtual subnetwork within an organization for sensitive applications.
Routing applications of IPsec
• A router advertisement (a new router advertises its presence) comes from an authorized router.
• A neighbor advertisement (a router seeks to establish or maintain a neighbour relationship with a router in
another routing domain) comes from an authorized router.
• A redirect message comes from the router to which the initial IP packet was sent.
• A routing update is not forged.

IPsec documents
• Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining IPsec
technology. The current specification is RFC 4301, Security Architecture for the Internet Protocol.
• Authentication Header (AH): AH is an extension header to provide message authentication. The current
specification is RFC 4302, IP Authentication Header.
• Encapsulating Security Payload (ESP): ESP consists of an encapsulating header and trailer used to provide
encryption or combined encryption/authentication. The current specification is RFC 4303, IP Encapsulating
Security Payload (ESP).
• Internet Key Exchange (IKE): This is a collection of documents describing the key management schemes for
use with IPsec. The main specification is RFC 5996.
 IPsec Services
• Access control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets (a form of partial sequence integrity)
• Confidentiality (encryption)
• Limited traffic flow confidentiality

IP security policy
Fundamental to the operation of IPsec is the concept of a security policy applied to each IP packet that transits
from a source to a destination.
IPsec policy is determined primarily by the interaction of two databases, the security association database
(SAD) and the security policy database (SPD). This section provides an overview of these two databases and
then summarizes their use during IPsec operation.

Security Associations (SA)

An association is a one-way logical connection between a sender and a receiver that affords security services to
the traffic carried on it. If a peer relationship is needed for two-way secure exchange, then two security
associations are required.

A security association is uniquely identified by three parameters.

• Security Parameters Index (SPI): A 32-bit unsigned integer assigned to this SA and having local significance
only.
• IP Destination Address: This is the address of the destination endpoint of the SA, which may be an end-user
system or a network system such as a firewall or router.
• Security Protocol Identifier: This field from the outer IP header indicates whether the association is an ESP
security association.

Security Association Database

Security Association Database defines the parameters associated with each SA. A security association is
normally defined by the following parameters in an SAD entry.
• Security Parameter Index: A 32-bit value selected by the receiving end of an SA to uniquely identify the SA.
In an SAD entry for an outbound SA, the SPI is used to construct the packet’s ESP header. In an SAD entry for
an inbound SA, the SPI is used to map traffic to the appropriate SA.
• Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in ESP headers
• Sequence Counter Overflow: A flag indicating whether overflow of the Sequence Number Counter should
generate an auditable event and prevent further transmission of packets on this SA.
• Anti-Replay Window: Used to determine whether an inbound ESP packet is a replay
• AH Information: Authentication algorithm, keys, key lifetimes.
• ESP Information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and
related parameters being used with ESP.
• Lifetime of this Security Association: A time interval or byte count after which an SA must be replaced with
a new SA (and new SPI) or terminated.
• IPsec Protocol Mode: Tunnel, transport, or wildcard.
• Path MTU: Any observed path maximum transmission unit

Security policy database

The means by which IP traffic is related to specific SAs is the nominal Security Policy Database (SPD). In
its simplest form, an SPD contains entries, each of which defines a subset of IP traffic and points to an SA for that
traffic. In more complex environments, there may be multiple entries that potentially relate to a single SA or
multiple SAs associated with a single SPD entry.
Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors. In effect, these
selectors are used to filter outgoing traffic in order to map it into a particular SA.

Outbound processing obeys the following general sequence for each IP packet.
1. Compare the values of the appropriate fields in the packet (the selector fields) against the SPD to find a matching
SPD entry, which will point to zero or more SAs.
2. Determine the SA if any for this packet and its associated SPI.
3. Do the required IPsec processing (ESP processing).

The following selectors determine an SPD entry:

• Remote IP Address: IP address
• Local IP Address: IP address
• Next Layer Protocol: The IP protocol header includes a field that designates the protocol operating over IP.
• Name: A user identifier from the operating system. This is not a field in the IP or upper-layer headers but is
available if IPsec is running on the same operating system as the user.
• Local and Remote Ports: These may be individual TCP or UDP port values.

IP Traffic processing
IPsec is executed on a packet-by-packet basis. When IPsec is implemented, each outbound IP packet is processed
by the IPsec logic before transmission, and each inbound packet is processed by the IPsec logic after reception
and before passing the packet contents on to the next higher layer (e.g., TCP or UDP).
Outbound Packets . A block of data from a higher layer, such as TCP, is passed down to the IP layer and an
IP packet is formed, consisting of an IP header and an IP body. Then the following steps occur:
1. IPsec searches the SPD for a match to this packet.
2. If no match is found, then the packet is discarded and an error message is generated.
3. If a match is found, further processing is determined by the first matching entry in the SPD. If the policy for
this packet is DISCARD, then the packet is discarded. If the policy is BYPASS, then there is no further IPsec
processing; the packet is forwarded to the network for transmission.
4. If the policy is PROTECT, then a search is made of the SAD for a matching entry. If no entry is found, then
IKE is invoked to create an SA with the appropriate keys and an entry is made in the SA.
5. The matching entry in the SAD determines the processing for this packet. Either encryption, authentication,
or both can be performed, and either transport or tunnel mode can be used. The packet is then forwarded to the
network for transmission.

Inbound Packets. An incoming IP packet triggers the IPsec processing.

The following steps occur:
1. IPsec determines whether this is an unsecured IP packet.
2. If the packet is unsecured, IPsec searches the SPD for a match to this packet. If the first matching entry has a
policy of BYPASS, the IP header is processed and stripped off and the packet body is delivered to the next
higher layer, such as TCP. If the first matching entry has a policy of PROTECT or DISCARD, or if there is no
matching entry, the packet is discarded.
3. For a secured packet, IPsec searches the SAD. If no match is found, the packet is discarded. Otherwise, IPsec
applies the appropriate ESP or AH processing. Then, the IP header is processed and stripped off and the packet
body is delivered to the next higher layer, such as TCP.
20.3 E Payload
ESP Format

Top-level format of an ESP packet. It contains the following fields.

• Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value.
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is
protected by encryption.
• Padding (0–255 bytes):
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits): Identifies the type of data contained in the payload data field.
• Integrity Check Value (variable): A variable-length field (must be an integral number of 32-bit words) that
contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.

Two additional fields may be present in the payload. An initialization value (IV), or nonce, is present if this is
required by the encryption or authenticated encryption algorithm used for ESP. If tunnel mode is being used,
then the IPsec implementation may add traffic flow confidentiality (TFC) padding after the Payload Data
 Encryption and Aunthentication Algorithms
The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service. If the algorithm
used to encrypt the payload requires cryptographic synchronization data, such as an initialization vector (IV), then
these data may be carried explicitly at the beginning of the Payload Data field.

The ICV is computed after the encryption is performed. This order of processing facilitates rapid detection and
rejection of replayed or bogus packets by the receiver prior to decrypting the packet, hence potentially reducing
the impact of denial of service (DoS) attacks. It also allows for the possibility of parallel processing of packets at
the receiver that is decryption can take place in parallel with integrity checking.