0% found this document useful (0 votes)
27 views31 pages

CNS UNIT 4 - Compressed

Uploaded by

Dinesh BE CSE
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
27 views31 pages

CNS UNIT 4 - Compressed

Uploaded by

Dinesh BE CSE
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

Authentication Applications: Kerberos – X.

509 Authentication Service – Electronic Mail


Security: Pretty good privacy, S/MIME – IP Security – Web Security: Web security
considerations, Secure socket layer and Transport layer Security – Authentication Header
– Encapsulating Security Payload – Combining Security Associations – Key Management.

KERBEROS

Kerberos provides a centralised authentication server whose function is to authenticate users to


servers and servers to users. Kerberos relies exclusively on conventional encryption, making no
use of public-key encryption.

The following are the requirements for Kerberos:

Secure: A network eavesdropper should not be able to obtain the necessary information to
impersonate a user. More generally, Kerberos should be strong enough that a potential opponent
does not find it to be the weak link.

Reliable: For all services that rely on Kerberos for access control, lack of availability of the
Kerberos service means lack of availability of the supported services. Hence, Kerberos should be
highly reliable and should employ a distributed server architecture, with one system able to
back up another.

Transparent: Ideally, the user should not be aware that authentication is taking place, beyond
the requirement to enter a password.

Scalable: The system should be capable of supporting large numbers of clients and servers.
This suggests a modular, distributed architecture.

To support these requirements, the overall scheme of Kerberos is that of a trusted third-party
authentication service that uses a protocol based on that proposed by Needham and Schroeder
[NEED78] It is trusted in the sense that clients and servers trust Kerberos to mediate their
mutual authentication. Assuming the Kerberos protocol is well designed, then the authentication
service is secure if the Kerberos server itself is secure.

A Simple Authentication Dialogue

In an unprotected network environment, any client can apply to any server for service.

The obvious security risk is that of impersonation. To counter this threat, servers must be able
to confirm the identities of clients who request service. But in an open environment, this places
a substantial burden on each server. An alternative is to use an authentication server (AS) that
knows the passwords of all users and stores these in a centralised database. In addition, the AS
shares a unique secret key with each server.

The simple authentication dialogue is as follows:

C >> AS: IDc||Pc||IDv

AS >> C: Ticket

C >> V: IDc||Ticket Ticket=

EKv(IDc||ADc||IDv)

C: Client,

AS: Authentication Server, V: Server,

IDv : ID of the server, IDc : ID of the client,

Pc:Password of the client, ADc: Address of client,

Kv: secret key shared by AS and V, ||: concatenation.

2. A More Secure Authentication Dialogue

There are two major problems associated with the previous approach:

Plaintext transmission of the password.

Each time a user has to enter the password.

To solve these problems, we introduce a scheme for avoiding plaintext passwords, and a new
server, known as ticket granting server (TGS). The hypothetical scenario is as follows:

Once per user logon session:

C >> AS: IDc||IDtgs

AS >> C: Ekc (Tickettgs)

Once per type of service:

C >> TGS: IDc||IDv||Tickettgs

TGS >> C: ticketv

Once per service session:

5. C >> V: IDc||ticketv
Tickettgs= Ektgs(IDc||ADc||IDtgs||TS1||Lifetime1) Ticketv=

Ekv(IDc||ADc||IDv||TS2||Lifetime2)

C: Client, AS: Authentication Server, V: Server, IDc : ID of the client, Pc:Password of the client,
ADc: Address of client, IDv : ID of the server, Kv: secret key shared by AS and V, ||: concatenation,
IDtgs: ID of the TGS server, TS1, TS2: time stamps, lifetime: lifetime of the ticket.

The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the user
first requests a ticket-granting ticket (Tickettgs) from the AS. The client module in the user work
station saves this ticket. Each time the user requires access to a new service, the client applies to
the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the particular
service. The client saves each service-granting ticket and uses it to authenticate its user to a
server each time a particular service is requested. Let us look at the details of this scheme:

The client requests a ticket-granting ticket on behalf of the user by sending its user's ID and
password to the AS, together with the TGS ID, indicating a request to use the TGS service.The AS
responds with a ticket that is encrypted with a key that is derived from the user's password.
When this response arrives at the client, the client prompts the user for his or her password,
generates the key, and attempts to decrypt the incoming message.

If the correct password is supplied, the ticket is successfully recovered.

Because only the correct user should know the password, only the correct user can recover the
ticket. Thus, we have used the password to obtain credentials from Kerberos without having to
transmit the password in plaintext.

Now that the client has a ticket-granting ticket, access to any server can be obtained with steps 3
and 4:

The client requests a service-granting ticket on behalf of the user. For this purpose, the client
transmits a message to the TGS containing the user's ID, the ID of the desired service, and the
ticket-granting ticket.

The TGS decrypts the incoming ticket and verifies the success of the decryption by the presence
of its ID. It checks to make sure that the lifetime has not expired. Then it compares the user ID
and network address with the incoming information to authenticate the user. If the user is
permitted access to the server V, the TGS issues a ticket to grant access to the requested service.

The service-granting ticket has the same structure as the ticket-granting ticket. Indeed, because
the TGS is a server, we would expect that the same elements are needed to authenticate a client
to the TGS and to authenticate a client to an application server. Again, the ticket contains a
timestamp and lifetime. If the user wants access to the same service at a later time, the client can
simply use the previously acquired service-granting ticket and need not bother the user for a
password. Note that the ticket is encrypted with a secret key (Kv) known only to the TGS and the
server, preventing alteration.

Finally, with a particular service-granting ticket, the client can gain access to the corresponding
service with step 5:

The client requests access to a service on behalf of the user. For this purpose, the client
transmits a message to the server containing the user's ID and the service-granting ticket. The
server authenticates by using the contents of the ticket.

This new scenario satisfies the two requirements of only one password query per user session
and protection of the user password.

X.509 Authentication Service

X.509 is a digital certificate that is built on top of a widely trusted standard known as ITU or
International Telecommunication Union X.509 standard, in which the format of PKI certificates
is defined. X.509 digital certificate is a certificate-based authentication security framework that
can be used for providing secure transaction processing and private information. These are
primarily used for handling the security and identity in computer networking and
internet-based communications.

Working of X.509 Authentication Service Certificate:

The core of the X.509 authentication service is the public key certificate connected to each user.
These user certificates are assumed to be produced by some trusted certification authority and
positioned in the directory by the user or the certified authority. These directory servers are
only used for providing an effortless reachable location for all users so that they can acquire
certificates. X.509 standard is built on an IDL known as ASN.1. With the help of Abstract Syntax
Notation, the X.509 certificate format uses an associated public and private key pair for
encrypting and decrypting a message.

Once an X.509 certificate is provided to a user by the certified authority, that certificate is
attached to it like an identity card. The chances of someone stealing it or losing it are less, unlike
other unsecured passwords. With the help of this analogy, it is easier to imagine how this
authentication works: the certificate is basically presented like an identity at the resource that
requires authentication.
Public Key certificate use

Format of X.509 Authentication Service Certificate:

Generally, the certificate includes the elements given below:


● Version number: It defines the X.509 version that concerns the certificate.
● Serial number: It is the unique number that the certified authority issues.
● Signature Algorithm Identifier: This is the algorithm that is used for signing the
certificate.
● Issuer name: Tells about the X.500 name of the certified authority which signed and
created the certificate.
● Period of Validity: It defines the period for which the certificate is valid.
● Subject Name: Tells about the name of the user to whom this certificate has been
issued.
● Subject’s public key information: It defines the subject’s public key along with an
identifier of the algorithm for which this key is supposed to be used.
● Extension block: This field contains additional standard information.
● Signature: This field contains the hash code of all other fields which is encrypted by
the certified authority private key.

Applications of X.509 Authentication Service Certificate:

Many protocols depend on X.509 and it has many applications, some of them are given below:

● Document signing and Digital signature


● Web server security with the help of Transport Layer Security (TLS)/Secure Sockets
Layer (SSL) certificates
● Email certificates
● Code signing
● Secure Shell Protocol (SSH) keys
● Digital Identities

Electronic Mail Security: Pretty good privacy, S/MIME

Email (short for electronic mail) is a digital method by using it we exchange messages between
people over the internet or other computer networks. With the help of this, we can send and
receive text-based messages, often an attachment such as documents, images, or videos, from
one person or organization to another. In this article, we will understand the concept of email
security, how we can protect our email, email security policies, and email security best practices,
and one of the features of email is an email that we can use to protect the email from
unauthorized access.
The security protocols PGP and S/MIME are created to secure the electronic mail facility. The
primary distinction between these protocols is the type of algorithms utilized in their security
mechanisms. PGP builds confidence between users by using either key rings or digital
certificates. On the other hand, S/MIME makes use of digital signatures, message digests,
encryption, etc.

In this article, you will learn about the difference between a PGP and S/MIME. But before
discussing the differences, you must know about PGP and S/MIME with their advantages and
disadvantages.

What is PGP?

PGP is an abbreviation for "Pretty Good Privacy". It is an open-source software program that is
mainly designed for email security, and it was designed and developed by Phil Zimmerman. It
offers the fundamental needs of cryptography. To secure the email, it employs many steps,
including authentication, confidentiality, compression, email compatibility, segmentation, and
reassembly. PGP includes a public key trust model and public key certificate management tools
to implement and develop it.

PGP takes some steps to secure the email, and these steps are as follows:

1. Digital Signature

The message digest of the email message is generated using the SHA-1 algorithm, and the
message digest is encrypted utilizing the sender's private key.

2. Compression

The email message and the digital signature are compressed together to decrease the final
transit message size. The ZIP program is the best example of compression based on the
Lempel-Ziv algorithm.

3. Encryption

It uses a symmetric key to encrypt the compressed form of the message obtained from the
compression.

4. Digital Enveloping
The receiver's public key is utilized to encrypt the symmetric key utilized in the encryption step.
A digital envelope is created by combining steps 3 and 4.

5. Base-64 Encoding

Step 4's output is Base-64 encoded, where a lot of arbitrary binary inputs are converted into
printable characters.

Advantages and Disadvantages of PGP

There are various advantages and disadvantages of a PGP. Some main advantages and
disadvantages of a PGP are as follows:

Advantages

1. There is no possibility of spoofing because the sender's identity is verified via the trust
mechanism.

2. Everyone easily downloads it because it is publicly accessible online.

3. Its data is encrypted, so the data cannot be changed while it is being transferred.

4. There isn't a compatibility problem.

Disadvantages

1. Public and private keys must be carefully kept so that they may be recovered if lost.

2. PGP employs a complicated structure for encryption.

3. Both the sender and the receiver use the same PGP version.

What is S/MIME?

S/MIME is an abbreviation for "Secure/Multipurpose Internet Mail Extension". It is a secure


enhanced variant of the MIME internet email format based on RSA Data security technology.
Public key cryptography is utilized in this case to sign, encrypt, or decode the email digitally. The
user obtains a public-private key pair from a trusted authority and then uses those keys
appropriately with email programs. MIME replaced the SMTP protocol since it was limited to
text and could only carry text messages. The user obtains a public-private key pair from a
trusted authority and then uses those keys appropriately with email programs. MIME replaced
the SMTP protocol since it was restricted to text, where only text messages were permitted to
transmit. The restricted protocol SMTP was unable to communicate multimedia files and
documents in many arbitrary forms because it employs a 7-bit ASCII representation of
characters in an email message, which cannot represent special characters with values more
than 127.

Structure of S/MIME

A MIME email message comprises a text message, some specific headers, and formatted text
parts. Each segment may include an ASCII-encoded portion of data and the technique for
decoding the data at the receiver's end. MIME headers provide the following information: MIME
version, Content-ID, Content-Type, Content-Transfer-Encoding, and Content-Description.

Advantages and Disadvantages of S/MIME

There are various advantages and disadvantages of S/MIME. Some main advantages and
disadvantages of S/MIME are as follows:

Advantages

1. It is available in various modern mail agents like Netscape, MS Outlook, etc.

2. It is utilized in commercial or industrial settings.

3. It ensures the message's validity and security.

4. The digital signature protects the email by using email spoofing.

Disadvantages

1. All users are unable to benefit from S/MIME due to the enforced certificate need because
some users simply desire encryption.

2. All email clients do not support S/MIME signatures.

Key differences between PGP and S/MIME

1. PGP is made to process emails in plain text. In contrast, the S/MIME permits emails that
also contain multimedia assets.
2. PGP is a general-purpose program that is mainly utilized for email security and file
protection. On the other hand, the S/MIME is utilized for email security.

3. PGP is a computer program that encrypts and decrypts data and provides cryptographic
privacy and authentication for internet data transfer. In contrast, the S/MIME offers data
security features like message integrity, authentication, and non-repudiation of origin for
electronic data transmission applications.

4. PGP is a less effective encryption method than S/MIME. In contrast, S/MIME is more
effective than PGP.

5. There are 4096 public keys in PGP. In contrast, the S/MIME only has 1024 public keys.

6. PGP products are more expensive than S/MIME. In contrast, S/MIME products are less
expensive than PGP.

7. PGP utilizes Diffie hellman's digital signature. In contrast, the S/MIME utilizes Elgamal's
digital signature.

8. S/MIME is suitable for usage in the industry. On the other hand, PGP is useful for both
personal and organizational purposes.

9. PGP is based on the exchange of user keys. On the other hand, the S/MIME depends on a
hierarchically valid certificate for key exchange.

10. PGP is the standard for secure encryption. On the other hand, the S/MIME is a robust
encryption standard with some limitations.

Head-to-head comparison between PGP and S/MIME

Here, you will learn the head-to-head comparisons between PGP and S/MIME. The main
differences between PGP and S/MIME are as follows:

Features PGP S/MIME

Full form PGP is an abbreviation for S/MIME is an abbreviation for


Pretty Good Privacy. Secure/Multipurpose Internet Mail
Extension.
Effectively It is made to process emails in It permits emails that also contain
process plain text. multimedia assets.

Cost It is less costly than S/MIME. It is more expensive than PGP.

Dependenc It relies on the user key It relies on a hierarchically valid certificate


y exchange. for key exchange.

Usage It is useful for both personal It is suitable for usage in the industry.
and organizational purposes.

Efficient It is less efficient. It is more efficient.

Convenient It is less convenient. It is more convenient because all


applications are securely transformed.

Public Keys It has 4096 public keys. It has only 1024 public keys.

Encryption It is the standard for secure It is a robust encryption standard with


encryption. some limitations.

Digital It utilizes Diffie hellman's digital It utilizes Elgamal's digital signature.


Signature signature.

VPN It may be utilized in VPNs. It is utilized with email services, not VPNs.
Web Security Considerations:

The World Wide Web is fundamentally a client/server application running over the Internet
and TCP/IP intranets. As such, the security tools and approaches discussed so far in this book
are relevant to the issue of Web security. But the Web presents new challenges not generally
appreciated in the context of computer and network security.

· The Internet is two-way. The Web is vulnerable to attacks on the Web servers over
the Internet.
· The Web is increasingly serving as a highly visible outlet for corporate and product
information and as the platform for business transactions. Reputations can be damaged
and money can be lost if the Web servers are subverted.
· Although Web browsers are very easy to use, Web servers are relatively easy to
configure and manage, and Web content is increasingly easy to develop, the underlying
software is extraordinarily complex.
· Once the Web server is subverted, an attacker may be able to gain access to data and
systems not part of the Web itself but connected to the server at the local site.
· Casual and untrained (in security matters) users are common clients for Web-based
services. Such users are not necessarily aware of the security risks that exist and do not
have the tools or knowledge to take effective countermeasures.

Web Traffic Security Approaches

A number of approaches to providing Web security are possible. The various approaches that
have been considered are similar in the services they provide and, to some extent, in the
mechanisms that they use, but they differ with respect to their scope of applicability and their
relative location within the TCP/IP protocol stack. Stallings
Figure 16.1 illustrates this difference.
One way to provide Web security is to use IP Security (Figure 16.1a). The advantage of using
IPSec is that it is transparent to end users and applications and provides a general-purpose
solution. Further, IPSec includes a filtering capability so only selected traffic need incur the IPSec
processing overhead.

Another relatively general-purpose solution is to implement security just above TCP (Figure
16.1b). The foremost example of this approach is the Secure Sockets Layer (SSL) and the
follow-on Internet standard known as Transport Layer Security (TLS). At this level, there are
two implementation choices. For full generality, SSL (or TLS) could be provided as part of the
underlying protocol suite and therefore be transparent to applications. Alternatively, SSL can be
embedded in specific packages, e.g. both the Netscape and Microsoft Explorer browsers come
with SSL, & most Web servers have implemented it.

Application-specific security services are embedded within the particular application. Figure
16.1c shows examples of this architecture. The advantage of this approach is that the service can
be tailored to the specific needs of a given application.

SSL (Secure Socket Layer)

SSL probably most widely used Web security mechanism, and it is implemented at the Transport
layer. SSL is designed to make use of TCP to provide a reliable end-to-end secure service. N
etscape originated SSL. Version 3 of the protocol was designed with public review and input
from industry and was published as an Internet draft document. Subsequently, when a
consensus was reached to submit the protocol for Internet standardization, the TLS working
group was formed within IETF to develop a common standard. This first published version of
TLS can be viewed as essentially an SSLv3.1 and is very close to and backward compatible with
SSLv3. SSL is not a single protocol but rather two layers of protocol, as shown next.

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, as illustrated in Figure 16.2.

The SSL Record Protocol provides basic security services to various higher-layer protocols. In
particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web
client/server interaction, can operate on top of SSL.
Three higher-layer protocols are also defined as part of SSL: the Handshake Protocol, Change
Cipher Spec Protocol, and Alert Protocol. These SSL-specific protocols are used in the
management of SSL exchanges.

Two important SSL concepts are the SSL connection and the SSL session:

• Connection: A connection is a network transport that provides a suitable type of service,


such connections are transient, peer-to-peer relationships, associated with one session
• Session: An SSL session is an association between a client and a server, created by the
Handshake Protocol. Sessions define a set of cryptographic security parameters, which can be
shared among multiple connections. Sessions are used to avoid the expensive negotiation of
new security parameters for each connection.

Between any pair of parties (applications such as HTTP on client and server), there may be
multiple secure connections. In theory, there may also be multiple simultaneous sessions
between parties, but this feature is not used in practice.

Once a session is established, there is a current operating state for both read and write (i.e.,
receive and send). In addition, during the Handshake Protocol, pending read and write states are
created. Upon successful conclusion of the Handshake Protocol, the pending states become the
current states. A session state and a connection state are defined by sets of parameters, see
textbook for details.

SSL Record Protocol Services

SSL Record Protocol defines two services for SSL connections:


• Confidentiality: The Handshake Protocol defines a shared secret key that is used for
conventional encryption of SSL payloads. The message is compressed before being
concatenated with the MAC and encrypted, with a range of ciphers being supported as shown.

• Message Integrity: The Handshake Protocol also defines a shared secret key that is used to
form a message authentication code (MAC), which is similar to HMAC

Fig: 17.3 SSL Record protocol Operation.

Figure 17.3 shows the overall operation of the SSL Record Protocol. The Record Protocol takes
an application message to be transmitted, fragments the data into manageable blocks, optionally
compresses the data, computes and appends a MAC (using a hash very similar to HMAC),
encrypts (using one of the symmetric algorithms listed on the previous slide), adds a header
(with details of the SSL content type, major/minor version, and compressed length), and
transmits the resulting unit in a TCP segment. Received data are decrypted, verified,
decompressed, and reassembled and then delivered to higher-layer applications.

The first step is fragmentation. Each upper-layer message is fragmented into blocks of 214 bytes
(16384 bytes) or less. Next, compression is optionally applied.

Compression must be lossless and may not increase the content length by more than 1024 bytes.

The next step in processing 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
Next, the compressed message plus the MAC are encrypted using symmetric encryption. For
stream encryption, the compressed message plus the MAC are encrypted. Note that the MAC is
computed before encryption takes place and that the MAC is then encrypted along with the
plaintext or compressed plaintext.

For block encryption, padding may be added after the MAC prior to encryption. The padding is
in the form of a number of padding bytes followed by a one-byte indication of the length of the
padding.

The final step of SSL Record Protocol processing 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 (or compressed
fragment if compression is used).The maximum value is 214 +2048.
Change Cipher Spec Protocol:

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use the SSL
Record Protocol, and it is the simplest, consisting of a single message (shown in Stallings Figure
16.5a), 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.
SS ALERT PROTOCOL

The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with other
applications that use SSL, alert messages are compressed and encrypted, as specified by the
current state.

Each message in this protocol consists of two bytes (as shown in Stallings Figure 16.5b), the
first takes the value warning(1) or fatal(2) to convey the severity of the message. The second
byte contains a code that indicates the specific alert.

Ø Fatal errors: unexpected message, bad record MAC, decompression failure, handshake failure,
illegal parameter

Ø warning: close notify, no certificate, bad certificate, unsupported certificate, certificate


revoked, certificate expired, certificate unknown
SSL Handshake Protocol:

The most complex part of SSL is the 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. The Handshake Protocol is
used before any application data is transmitted. The Handshake Protocol consists of a series of
messages exchanged by client and server, which have the format shown in Stallings Figure
16.5c, and which can be viewed in 4 phases:
Phase 1. Establish Security Capabilities:

This phase is used by the client to initiate a logical connection and to establish the security
capabilities that will be associated with it.

The exchange is initiated by the client, which sends a client_hello message with the
following 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
nonces and are used during key exchange to prevent replay attacks
● Session ID: A variable-length session identifier. A nonzero value indicates that the
client wishes to update the parameters of an existing connection or to create a new
connection on this session. A zero value indicates that the client wishes to establish
a new connection on a new session.
● CipherSuite: This is a list that contains the combinations of cryptographic
algorithms supported by the client, in decreasing order of preference. Each element
of the list (each cipher suite) defines both a key exchange algorithm and a
CipherSpec; these are discussed subsequently.
● Compression Method: This is a list of the compression methods the client supports.

After sending the

client_hello message, the client waits for the server_hello

message, which contains the same parameters as the client_hello message.

The first element of the CipherSuite parameter is the key exchange method (i.e., the means by
which the cryptographic keys for conventional encryption and MAC are exchanged).The
following key exchange methods is supported.

RSA: The secret key is encrypted with the receiver’s RSA public key.

Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange in which the server’s certificate
contains the Diffie-Hellman public parameters signed by the certificate authority (CA). That is,
the public-key certificate contains the Diffie-Hellman public-key parameters.

Ephemeral Diffie-Hellman: This technique is used to create ephemeral (temporary, one-time)


secret keys. In this case, the Diffie-Hellman public keys are exchanged, signed using the sender’s
private RSA or DSS key. The receiver can use the corresponding public key to verify the
signature.
Anonymous Diffie-Hellman: The base Diffie-Hellman algorithm is used with no
authentication. That is, each side sends its public Diffie-Hellman parameters to the other
with no authentication.

Phase 2. Server Authentication and Key Exchange:

The server begins this phase by sending its certificate if it needs to be authenticated.

Next, a server_key_exchange message may be sent if it is required.

Next, a non anonymous server (server not using anonymous Diffie-Hellman) can request
a certificate from the client. The certificate_request message includes two parameters:
certificate_type and certificate_authorities.
The final message in phase 2, and one that is always required, is the server_done
message, which is sent by the server to indicate the end of the server hello and
associated messages. After sending this message, the server will wait for a client
response.

Phase 3. Client Authentication and Key Exchange:

The client should verify that the server provided a valid certificate if required and check that
the server_hello parameters are acceptable.

● If the server has requested a certificate, the client begins this phase by sending
a certificate message. If no suitable certificate is available, the client sends a
no_certificate alert instead.
● Next is the client_key_exchange message, which must be sent in this phase.
● Finally, in this phase, the client may send a certificate_verify message to provide
explicit verification of a client certificate. This message is only sent following
any client certificate that has signing capability (i.e., all certificates except those
containing fixed Diffie-Hellman parameters).

Phase 4. Finish

● This phase completes the setting up of a secure connection.


● The client sends a change_cipher_spec message and copies the pending CipherSpec into
the current CipherSpec.
● The client then immediately sends the finished message under the new algorithms, keys,
and secrets.
● The finished message verifies that the key exchange and authentication processes were
successful.
● At this point the handshake is complete and the client and server may begin to exchange
application layer data.
Transport Layer Securities (TLS) are designed to provide security at the transport layer. TLS
was derived from a security protocol called Secure Socket Layer (SSL). TLS ensures that no third
party may eavesdrop or tampers with any message.

There are several benefits of TLS:

● Encryption:
TLS/SSL can help to secure transmitted data using encryption.
● Interoperability:
TLS/SSL works with most web browsers, including Microsoft Internet Explorer and
on most operating systems and web servers.
● Algorithm flexibility:
TLS/SSL provides operations for authentication mechanism, encryption algorithms
and hashing algorithm that are used during the secure session.
● Ease of Deployment:
Many applications TLS/SSL temporarily on a windows server 2003 operating
systems.
● Ease of Use:
Because we implement TLS/SSL beneath the application layer, most of its operations
are completely invisible to client.

Working of TLS:
The client connect to server (using TCP), the client will be something. The client sends number
of specification:

1. Version of SSL/TLS.
2. which cipher suites, compression method it wants to use.

The server checks what the highest SSL/TLS version is that is supported by them both, picks a
cipher suite from one of the clients option (if it supports one) and optionally picks a
compression method. After this the basic setup is done, the server provides its certificate. This
certificate must be trusted either by the client itself or a party that the client trusts. Having
verified the certificate and being certain this server really is who he claims to be (and not a man
in the middle), a key is exchanged. This can be a public key, “PreMasterSecret” or simply nothing
depending upon cipher suite.

Both the server and client can now compute the key for symmetric encryption. The handshake is
finished and the two hosts can communicate securely. To close a connection by finishing. TCP
connection both sides will know the connection was improperly terminated. The connection
cannot be compromised by this through, merely interrupted.

Transport Layer Security (TLS) continues to play a critical role in securing data transmission
over networks, especially on the internet. Let’s delve deeper into its workings and significance:

Enhanced Security Features:

TLS employs a variety of cryptographic algorithms to provide a secure communication channel.


This includes symmetric encryption algorithms like AES (Advanced Encryption Standard) and
asymmetric algorithms like RSA and Diffie-Hellman key exchange. Additionally, TLS supports
various hash functions for message integrity, such as SHA-256, ensuring that data remains
confidential and unaltered during transit.

Certificate-Based Authentication:

One of the key components of TLS is its certificate-based authentication mechanism. When a
client connects to a server, the server presents its digital certificate, which includes its public key
and other identifying information. The client verifies the authenticity of the certificate using
trusted root certificates stored locally or provided by a trusted authority, thereby establishing
the server’s identity.

Forward Secrecy:

TLS supports forward secrecy, a crucial security feature that ensures that even if an attacker
compromises the server’s private key in the future, they cannot decrypt past communications.
This is achieved by generating ephemeral session keys for each session, which are not stored
and thus cannot be compromised retroactively.

TLS Handshake Protocol:

The TLS handshake protocol is a crucial phase in establishing a secure connection between the
client and the server. It involves multiple steps, including negotiating the TLS version, cipher
suite, and exchanging cryptographic parameters. The handshake concludes with the exchange of
key material used to derive session keys for encrypting and decrypting data.

Perfect Forward Secrecy (PFS):

Perfect Forward Secrecy is an advanced feature supported by TLS that ensures the
confidentiality of past sessions even if the long-term secret keys are compromised. With PFS,
each session key is derived independently, providing an additional layer of security against
potential key compromise.

TLS Deployment Best Practices:

To ensure the effectiveness of TLS, it’s essential to follow best practices in its deployment. This
includes regularly updating TLS configurations to support the latest cryptographic standards
and protocols, disabling deprecated algorithms and cipher suites, and keeping certificates
up-to-date with strong key lengths.

Continual Evolution:
TLS standards continue to evolve to address emerging security threats and vulnerabilities.
Ongoing efforts by standards bodies, such as the Internet Engineering Task Force (IETF), ensure
that TLS remains robust and resilient against evolving attack vectors.

Authentication Header
The Authentication Header (AH) is a security protocol used within the IPsec suite. Its primary
function is to ensure that the message remains unmodified during transmission from the source
and it confirms that the data originates from the expected source. Authentication Header
achieves this by adding a header to IP packets, containing a checksum and a digital signature. Its
main functions are:

● Message Integrity – It means, the message is not modified while coming from the
source.
● Source Authentication – It means, the source is exactly the source from whom we
were expecting data.

When a packet is sent from source A to Destination B, it consists of data that we need to send
and a header that consists of packet information. The Authentication Header verifies the origin
of data and also the payload to confirm if there has been modification done in between, during
transmission between source and destination. However, in transit, values of some IP header
fields might change (like- Hop count, options, extension headers). So, the values of such fields
cannot be protected from Authentication header. Authentication header cannot protect every
field of IP header. It provides protection to fields which are essential to be protected.

Authentication Header Format


● Next Header – Next Header is 8-bit field that identifies type of header present after
Authentication Header. In case of TCP, UDP or destination header or some other
extension header it will store correspondence IP protocol number . Like, number 4 in
this field will indicate IPv4, number 41 will indicate IPv6 and number 6 will indicate
TCP.
● Payload Length – Payload length is length of Authentication header and here we use
scaling factor of 4. Whatever be size of header, divide it by 4 and then subtract by 2.
We are subtracting by 2 because we’re not counting first 8 bytes of Authentication
header, which is first two row of picture given above. It means we are not including
Next Header, Payload length, Reserved and Security Parameter index in calculating
payload length. Like, say if payload length is given to be X. Then (X+2)*4 will be
original Authentication header length.
● Reserved – This is 16-bit field which is set to “zero” by sender as this field is
reserved for future use.
● Security Parameter Index (SPI) – It is arbitrary 32-bit field. It is very important
field which identifies all packets which belongs to present connection. If we’re
sending data from Source A to Destination B. Both A and B will already know
algorithm and key they are going to use. So for Authentication, hashing function and
key will be required which only source and destination will know about. Secret key
between A and B is exchanged by method of Diffie Hellman algorithm. So Hashing
algorithm and secret key for Security parameter index of connection will be fixed.
Before data transfer starts security association needs to be established. In Security
Association, both parties needs to communicate prior to data exchange. Security
association tells what is security parameter index, hashing algorithm and secret key
that are being used.
● Sequence Number – This unsigned 32-bit field contains counter value that
increases by one for each packet sent. Every packet will need sequence number. It
will start from 0 and will go till

232 2 32 – 1 and there will be no wrap around. Say, if all sequence numbers are over
and none of it is left but we cannot wrap around as it is not allowed. So, we will end
connection and re-establish connection again to resume transfer of remaining data from
sequence number 0. Basically sequence numbers are used to stop replay attack. In
Replay attack, if same message is sent twice or more, receiver won’t be able to know if
both messages are sent from a single source or not. Say, I am requesting 100$ from
receiver and Intruder in between asked for another 100$. Receiver won’t be able to
know that there is intruder in between.
● Authentication Data (Integrity Check Value) – Authentication data is variable
length field that contains Integrity Check Value (ICV) for packet. Using hashing
algorithm and secret key, sender will create message digest which will be sent to
receiver. Receiver on other hand will use same hashing algorithm and secret key. If
both message digest matches then receiver will accept data. Otherwise, receiver will
discard it by saying that message has been modified in between. So basically,
authentication data is used to verify integrity of transmission. Also length of
Authentication data depends upon hashing algorithm you choose.

How Does Authentication Header Work?


When a packet is sent from source A to destination B, it includes both data and a header. The
Authentication Header verifies the origin of the data and checks if any modifications occurred
during transmission. Note that some IP header fields (such as hop count, options, and extension
headers) may change in transit and are not protected by Authentication Header. Authentication
Header focuses on protecting essential fields within the IP header.

Modes of Operations in Authentication Header


● Authentication Header Transport Mode: In the authentication header transport
mode, it is lies between the original IP Header and IP Packets original TCP header.
● Authentication Header Tunnel Mode: In this authentication header tunnel mode,
the original IP packet is authenticated entire and the authentication header is
inserted between the original IP header and new outer IP header. Here, the inner
IP header contains the ultimate source IP address and destination IP address. whereas
the outer IP header contains different IP address that is IP address of the firewalls
or other security gateways.

How does the Header Deals with Replay Attack?


● In a replay attack, the attacker a copy of an authenticated packet and then send to
the intended destination. As the same packet received twice, the destination user can
face some problems. To reduce this problem, the authentication header use a
sequence number field.
● At this initial stage, the value of this field is set to 0. whenever the sender sends the
packets to the same receiver over the same SA, it increments the fields value by 1. If
the number of packets over the same increase this number, then communication
with the receiver sender must establishing a new SA with the receiver.
● At the receiver side, the receiver maintains a sliding window size to W. The default
value of W is 64. This window right edge represents the highest sequence number N
received so far for a valid packet. When the receiver gets a packet from the sender, it
perform some action. The appropriate action depends on the sequence number of
the packet.

Encapsulating Security Payload


Encapsulating security payload, also abbreviated as ESP plays a very important role in network
security. ESP or Encapsulating security payload is an individual protocol in IPSec. ESP is
responsible for the CIA triad of security (Confidentiality, Integrity, Availability), which is
considered significant only when encryption is carried along with them. Securing all payload/
packets/ content in IPv4 and IPv6 is the responsibility of ESP.

Working of ESP:

1. Encapsulating Security Payload supports both main Network layer protocols: IPv4
and IPv6 protocols.
2. It performs the functioning of encryption in headers of Internet Protocol or in
general say, it resides and performs functions in IP Header.
3. One important thing to note here is that the insertion of ESP is between Internet
Protocol and other protocols such as UDP/ TCP/ ICMP.

Modes in ESP:

Encapsulating Security Payload supports two modes, i.e. Transport mode, and tunnel mode.

Tunnel mode:

1. Mandatory in Gateway, tunnel mode holds utmost importance.


2. Here, a new IP Header is created which is used as the outer IP Header followed by
ESP.

Transport mode:

1. Here, IP Header is not protected via encryption or authentication, making it


vulnerable to threats
2. Less processing is seen in this mode, so the inclusion of ESP is preferred

Advantages:

Below listed are the advantages of Encapsulating Security Payload:

1. Encrypting data to provide security


2. Maintaining a secure gateway for data/ message transmission
3. Properly authenticating the origin of data
4. Providing needed data integrity
5. Maintaining data confidentiality
6. Helping with anti replay service using authentication header

Disadvantages:

Below listed are the disadvantages of Encapsulating Security Payload:

1. There is a restriction on the encryption method to be used


2. For global use and implementation, weaker encryptions are mandatory to use

Components of ESP:

An important point to note is that authentication and security are not provided for the entire IP
packet in transport mode. On the other hand for the tunnel mode, the entire IP packet along with
the new packet header is encapsulated.

ESP structure is composed of the following parts as shown below :

ESP Structure

The diagrammatic representation of ESP has the below-mentioned components :

1. Security Parameter :

● Security parameters are assigned a size of 32 bits for use


● Security Parameter is mandatory to security parameter in ESP for security links and
associations
2. Sequence Number:

● The sequence number is 32 bits in size and works as an incremental counter.


● The first packet has a sequence number 1 assigned to it whenever sent through SA

3. Payload Data:

● Payload data don’t have fixed size and are variable in size to use
● It refers to the data/ content that is provided security by the method of encryption

4. Padding:

● Padding has an assigned size of 0-255 bytes assigned to it.


● Padding is done to ensure that the payload data which needs to be sent securely fits
into the cipher block correctly, so for this padding payloads come to the rescue.

5. Pad Length:

● Pad Length is assigned the size of 8 bits to use


● It is a measure of pad bytes that are preceding

6. Next Header:

● The next header is associated with a size of 8 bits to use


● It is responsible for determining the data type of payload by studying the first header
of the payload

7. Authentication Data:

● The size associated with authentication data is variable and never fixed for use-case
● Authentication data is an optional field that is applicable only when SA is selected. It
serves the purpose of providing integrity

Combining Security Associations

An individual SA can implement either the AH or ESP protocol but not both. Sometimes, we may
wish to employ multiple SAs on the same traffic flow to achieve some desired IPSec services. We
refer to a sequence of SAs through which traffic must be processed to provide the desired set of
IPSec services as a security association bundle (SA bundle).

Security Associations can be combined into bundles in two ways:


1. Transport Adjacency: Applying more than one SA to a single IP packet without invoking
tunnelling. This approach only allows one level of combination, as further nesting yields
no added benefit since the processing is performed at one IPSec instance, namely the
end destination.
2. Iterated Tunnelling: Applying multiple layers of security protocols through IP tunnelling.
This approach allows for multiple layers of nesting since each tunnel can originate and
terminate at a different point along the path.

ESP with Authentication

As we have seen earlier, ESP can be applied to the data to be protected, and then we append the
authentication data field. In transport mode, ESP provides authentication and encryption to the
IP payload delivered to the host, but the IP header is not protected. In tunnel mode, ESP
provides authentication to the entire IP packet delivered to the outer IP destination address,
where the authentication is performed.

Transport Adjacency

For Transport Adjacency, we use two bundled transport SAs; the inner one being an ESP SA
without authentication, and the outer being an AH SA. The advantage of this approach over
using ESP with authentication is that the authentication covers more fields, namely the source
and destination IP addresses. However, it brings an overhead of using two SAs instead of a single
SA.

Transport-Tunnel Bundle

For a Transport-Tunnel Bundle, the idea is to apply authentication before encryption, which can
be desirable as the authentication data is protected by encryption, meaning an attack cannot
intercept the message and alter the authentication data without detection. In this approach, we
use a bundle consists of an inner AH transport SA and an outer ESP tunnel SA.
Key management refers to the processes and procedures involved in generating, storing,
distributing, and managing cryptographic keys used in cryptographic algorithms to protect
sensitive data. It ensures that keys used to protect sensitive data are kept safe from
unauthorized access or loss. Good key management helps maintain the security of encrypted
information and is important for protecting digital assets from cyber threats. Effective key
management is crucial for ensuring the confidentiality, integrity, and availability of encrypted
information by securing cryptographic keys from unauthorized access, loss, or compromise.
Key Management Lifecycle
The key management lifecycle outlines the stages through which cryptographic keys are
generated, used, and eventually retired or destroyed. Proper management of these keys is
critical to ensuring the security of cryptographic systems. Here’s an overview of each stage:

1. Key Generation:

● Creation: Keys are created using secure algorithms to ensure randomness and
strength.
● Initialization: Keys are initialized with specific parameters required for their
intended use (e.g., length, algorithm).

2. Key Distribution:

● Sharing: For symmetric keys, secure methods must be used to share the key
between parties.
● Publication: For asymmetric keys, the public key is shared openly, while the private
key remains confidential.

3. Key Storage:

● Protection: Keys must be stored securely, typically in hardware security modules


(HSMs) or encrypted key stores, to prevent unauthorized access.
● Access Control: Only authorized users or systems should be able to access keys.

4. Key Usage:
● Application: Keys are used for their intended cryptographic functions, such as
encrypting/decrypting data or signing/verifying messages.
● Monitoring: Usage is monitored to detect any unusual or unauthorized activities.

5. Key Rotation:

● Updating: Keys are periodically updated to reduce the risk of exposure or


compromise.
● Re-Keying: New keys are generated and distributed, replacing old ones while
ensuring continuity of service.

6. Key Revocation:

● Invalidation: Keys that are no longer secure or needed are invalidated.


● Revocation Notices: For public keys, revocation certificates or notices are
distributed to inform others that the key should no longer be trusted.

7. Key Archival:

● Storage: Old keys are securely archived for future reference or compliance purposes.
● Access Restrictions: Archived keys are kept in a secure location with restricted
access.

8. Key Destruction:

● Erasure: When keys are no longer needed, they are securely destroyed to prevent
any possibility of recovery.
● Verification: The destruction process is verified to ensure that no copies remain.

You might also like