1

Cryptography in Cyber Security: Principles and

Practices

Program PG-Cyber Security

Semester I
Category PE I

P S MANN, Ph.D.
M-ACM, M-IAENG, M-CSI, LM-ISTE, LM-PAS
Gujarat Technological University (GTU)
(NAAC Accredited A+ Grade University)
Ahmedabad, Gujarat, India. 382424
UNIT III
2

Introduction to Web Security

Requirements, Secure Socket Layer (SSL) and Transport Layer Security (TLS),

Secure Electronic Transaction (SET), Intruders, Viruses and related threats. Firewall

Design principles, Trusted Systems, MIME

Web Security Considerations
3

 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. This complex software may hide
many potential security flaws.

 A Web server can be exploited as a launching pad into the corporation’s or agency’s
entire computer 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 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 Security Threats
4
Web Traffic Security Approaches
5
Secure Sockets Layer (SSL)
6

 SSL is a general-purpose service implemented as a set of protocols that rely on TCP.

SSL could be provided as part of the underlying protocol suite and therefore be

transparent to applications. Alternatively, SSL can be embedded in specific

packages. For example, most browsers come equipped with SSL, and most Web

servers have implemented the protocol.

SSL Architecture
7

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. 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 defined as part of SSL: the Handshake Protocol, The Change

Cipher Spec Protocol, and the Alert Protocol. These SSL-specific protocols are used in

the management of SSL exchanges.

SSL Architecture
8
SSL Architecture
9

Two important SSL concepts are the SSL session and the SSL connection, which are
defined in the specification as follows.

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

 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. Sessions are
used to avoid the expensive negotiation of new security parameters for each
connection. Between any pair of parties , there may be multiple secure connections.
SSL Architecture
10
SSL Record Protocol
11

The SSL Record Protocol provides two services for SSL connections:

 Confidentiality: The Handshake Protocol defines a shared secret key that is used

for conventional encryption of SSL payloads.

 Message Integrity: The Handshake Protocol also defines a shared secret key that is

used to form a message authentication code (MAC).

SSL Record Protocol
12
Change Cipher Spec Protocol
13

 The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use

the SSL Record Protocol, and it is the simplest. 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
14

 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. 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. Other connections on the same session

may continue, but no new connections on this session may be established. The

second byte contains a code that indicates the specific alert.

Handshake Protocol
15

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.

Handshake Protocol
16

Each message has three fields:

 Type (1 byte): Indicates one of ten messages.

 Length (3 bytes): The length of the message in bytes.

 Content (>= 0 bytes): The parameters associated with this message.

Transport Layer Security (TLS)
17

TLS goal is to produce an Internet standard version of SSL.

Version Number

 The TLS Record Format is the same as that of the SSL Record Format, and the

fields in the header have the same meanings. The one difference is in version values.

For the current version of TLS, the major version is 3 and the minor version is 3.
Transport Layer Security (TLS)
18

Message Authentication Code

 There are two differences between the SSLv3 and TLS MAC schemes: the actual

algorithm and the scope of the MAC calculation. TLS makes use of the HMAC

algorithm.

 SSLv3 uses the same algorithm, except that the padding bytes are concatenated with

the secret key rather than being XORed with the secret key padded to the block

length. The level of security should be about the same in both cases.
Transport Layer Security (TLS)
19

Alert Codes

 TLS supports all of the alert codes defined in SSLv3 with the exception of
no_certificate.

Cipher Suites

There are several small differences between the cipher suites available under SSLv3
and under TLS:

 Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the
exception of Fortezza.

 Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption

algorithms found in SSLv3, with the exception of Fortezza.
Transport Layer Security (TLS)
20

Padding

In SSL, the padding added prior to encryption of user data is the minimum amount

required so that the total size of the data to be encrypted is a multiple of the cipher’s

block length. In TLS, the padding can be any amount that results in a total that is a

multiple of the cipher’s block length, up to a maximum of 255 bytes. A variable

padding length may be used to frustrate attacks based on an analysis of the lengths of

exchanged messages.
HTTPS
21

HTTPS (HTTP over SSL) 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. Its use depends on the
Web server supporting HTTPS communication. For example, some search engines do
not support HTTPS. Google provides HTTPS as an option:

https://google.com.

The principal difference seen by a user of a Web browser is that addresses begin with
https:// rather than http://. A normal HTTP connection uses port 80. If HTTPS is
specified, port 443 is used, which invokes SSL.
HTTPS
22

When HTTPS is used, the following elements of the communication are encrypted:

 URL of the requested document

 Contents of the document

 Contents of browser forms (filled in by browser user)

 Cookies sent from browser to server and from server to browser

 Contents of HTTP header

Note : There is no fundamental change in using HTTP over either SSL or TLS, and both
implementations are referred to as HTTPS.
Secure Electronic Transaction (SET)

23

Secure Electronic Transaction or SET is a system that ensures the security and

integrity of electronic transactions done using credit cards in a scenario. SET is not

some system that enables payment but it is a security protocol applied to those

payments. It uses different encryption and hashing techniques to secure payments over

the internet done through credit cards. The SET protocol was supported in development

by major organizations like Visa, Mastercard, Microsoft which provided its Secure

Transaction Technology (STT), and Netscape which provided the technology of Secure

Socket Layer (SSL).

Secure Electronic Transaction (SET)

24

SET protocol restricts the revealing of credit card details to merchants thus keeping

hackers and thieves at bay. The SET protocol includes Certification Authorities for

making use of standard Digital Certificates like X.509 Certificate.

Requirements in SET
25

The SET protocol has some requirements to meet, some of the important requirements
are :

 It has to provide mutual authentication i.e., customer (or cardholder) authentication

by confirming if the customer is an intended user or not, and merchant
authentication.

 It has to keep the PI (Payment Information) and OI (Order Information) confidential

by appropriate encryptions.

 It has to be resistive against message modifications i.e., no changes should be

allowed in the content being transmitted.

 SET also needs to provide interoperability and make use of the best security
mechanisms.
Participants in SET
26

In the general scenario of online transactions, SET includes similar participants:

 Cardholder – customer

 Issuer – customer financial institution

 Merchant

 Acquirer – Merchant financial

 Certificate authority – Authority that follows certain standards and issues

certificates(like X.509V3) to all other participants.
SET functionalities
27

 Provide Authentication

 Merchant Authentication – To prevent theft, SET allows customers to check

previous relationships between merchants and financial institutions. Standard
X.509V3 certificates are used for this verification.

 Customer / Cardholder Authentication – SET checks if the use of a credit card is

done by an authorized user or not using X.509V3 certificates.

 Provide Message Confidentiality: Confidentiality refers to preventing unintended

people from reading the message being transferred. SET implements confidentiality by
using encryption techniques. Traditionally DES is used for encryption purposes.

 Provide Message Integrity: SET doesn’t allow message modification with the help of
signatures. Messages are protected against unauthorized modification using RSA digital
signatures with SHA-1 and some using HMAC with SHA-1,
Dual Signature
28

The dual signature is a concept introduced with SET, which aims at connecting two

information pieces meant for two different receivers :

Order Information (OI) for merchant

Payment Information (PI) for bank

Dual Signature
29

Where,

PI stands for payment information

OI stands for order information

PIMD stands for Payment Information Message Digest

OIMD stands for Order Information Message Digest

POMD stands for Payment Order Message Digest

H stands for Hashing

E stands for public key encryption

KPc is customer's private key

|| stands for append operation

Dual signature DS= E(KPc, [H(H(PI)||H(OI))])

Purchase Request Generation
30

The process of purchase request generation requires three inputs:

 Payment Information (PI)
 Dual Signature
 Order Information Message Digest (OIMD)
Purchase Request Generation
31

Here,

PI, OIMD, OI all have the same meanings as before.

EP which is symmetric key encryption

Ks is a temporary symmetric key

KUbank is public key of bank

CA is Cardholder or customer Certificate

Digital Envelope = E(KUbank, Ks)

Purchase Request Validation on Merchant Side
32

The Merchant verifies by comparing POMD generated through PIMD hashing with
POMD generated through decryption of Dual Signature as follows:

Since we used Customer’s private key in encryption here we use KUC which is the public
key of the customer or cardholder for decryption ‘D’.
Payment Authorization and Payment Capture
33

Payment authorization as the name suggests is the authorization of payment information

by the merchant which ensures payment will be received by the merchant. Payment

capture is the process by which a merchant receives payment which includes again

generating some request blocks to gateway and payment gateway in turn issues

payment to the merchant.

Multipurpose Internet Mail Extension (MIME)
34

 Multipurpose Internet Mail Extension (MIME) is framework that is intended to

address some of the problems and limitations of the use of Simple Mail Transfer

Protocol (SMTP).

 Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement

to the MIME Internet e-mail format standard based on technology from RSA Data

Security.
Limitations of the SMTP
35

 SMTP cannot transmit executable files or other binary objects.

 SMTP cannot transmit text data that includes national language characters because

these are represented by 8-bit codes with values of 128 decimal or higher, and

SMTP is limited to 7-bit ASCII.

 SMTP servers may reject mail message over a certain size.

 SMTP gateways that translate between ASCII and the character code EBCDIC do

not use a consistent set of mappings, resulting in translation problems.

Multipurpose Internet Mail Extension (MIME)
36

The five header fields defined in MIME are

 MIME-Version: Must have the parameter value 1.0. This field indicates that the
message conforms to RFCs 2045 and 2046.

 Content-Type: Describes the data contained in the body with sufficient detail that the
receiving user agent can pick an appropriate agent or mechanism to represent the data to
the user or otherwise deal with the data in an appropriate manner.

 Content-Transfer-Encoding: Indicates the type of transformation that has been used to

represent the body of the message in a way that is acceptable for mail transport.

 Content-ID: Used to identify MIME entities uniquely in multiple contexts.

 Content-Description: A text description of the object with the body; this is useful when
the object is not readable (e.g., audio data).
MIME Content Types
37
Canonical Form
38

 An important concept in MIME and S/MIME is that of canonical form. Canonical form is a
format, appropriate to the content type, that is standardized for use between systems. This is
in contrast to native form, which is a format that may be peculiar to a particular system.
S/MIME
I Functionality
39

S/MIME provides the following functions:

 Enveloped data: This consists of encrypted content of any type and encrypted

content encryption keys for one or more recipients.

 Signed data: A digital signature is formed by taking the message digest of the

content to be signed and then encrypting that with the private key of the signer. The

content plus signature are then encoded using base64 encoding. A signed data

message can only be viewed by a recipient with S/MIME capability.

S/MIME Functionality
40

 Clear-signed data: As with signed data, a digital signature of the content is formed.

However, in this case, only the digital signature is encoded using base64. As a

result, recipients without S/MIME capability can view the message content,

although they cannot verify the signature.

 Signed and enveloped data: Signed-only and encrypted-only entities may be

nested, so that encrypted data may be signed and signed data or clear-signed data

may be encrypted.
Self Learning Topic
41

 Intruders

 Viruses

 Firewalls
Many Thanks !