The document discusses web security considerations and threats. It provides 3 levels at which security can be implemented - at the IP level using IPSec, at the transport level using SSL/TLS, and at the application level using protocols like SET. SSL/TLS works by establishing an encrypted channel between the client and server for secure communication. It uses handshake, change cipher spec, and alert protocols for negotiation and management of the secure session. Common web security threats include eavesdropping, message modification, denial of service attacks, and impersonation which can be mitigated using encryption, authentication and other cryptographic techniques.
Fundamental of Secure Socket Layer (SSL) | Part - 2 Vishal Kumar
Â
In this presentation we will learn about the Record Protocol, Alert Protocol, Closing and Resuming SSL Connections and Attacks on SSL.
The Part - 1 cab be founded at : https://www.slideshare.net/vishalkumar245/fundamental-of-secure-socket-layer-ssl-part-1
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).
The Fundamental of Secure Socket Layer (SSL)Vishal Kumar
Â
"The Fundamental of SSL" it is the first part of this Topic in which we covered covers the deep understanding of Secure Socket Layer, its position in the TCP/IP suit, its sub protocols and the working or Handshake Protocol.
Avoiding Man in the Middle Attack Based on ARP Spoofing in the LANEditor IJCATR
Â
As technology is running on its wheels, networking has turned into one of our basic aspects. In this world along with
networking inimical vulnerabilities are also advancing in a drastic manner, resulting in perilous security threats. This calls for the great
need of network security. ARP spoofing is one of the most common MITM attacks in the LAN. This attack can show critical
implications for internet users especially in stealing sensitive informationâs such as passwords. Beyond this it can facilitate other
attacks like denial of service(DOS), session hijacking etc..,. In this paper we are proposing a new method by encrypting MAC address
to shield from ARP cache poisoning
This paper discuss various wireless networks and their security, for each type, structure and related threats are described and how different techniques are applied to achieve security goals starting by general case
Welcome to International Journal of Engineering Research and Development (IJERD)IJERD Editor
Â
call for paper 2012, hard copy of journal, research paper publishing, where to publish research paper,
journal publishing, how to publish research paper, Call For research paper, international journal, publishing a paper, IJERD, journal of science and technology, how to get a research paper published, publishing a paper, publishing of journal, publishing of research paper, reserach and review articles, IJERD Journal, How to publish your research paper, publish research paper, open access engineering journal, Engineering journal, Mathemetics journal, Physics journal, Chemistry journal, Computer Engineering, Computer Science journal, how to submit your paper, peer reviw journal, indexed journal, reserach and review articles, engineering journal, www.ijerd.com, research journals
Fundamental of Secure Socket Layer (SSL) | Part - 2 Vishal Kumar
Â
In this presentation we will learn about the Record Protocol, Alert Protocol, Closing and Resuming SSL Connections and Attacks on SSL.
The Part - 1 cab be founded at : https://www.slideshare.net/vishalkumar245/fundamental-of-secure-socket-layer-ssl-part-1
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).
The Fundamental of Secure Socket Layer (SSL)Vishal Kumar
Â
"The Fundamental of SSL" it is the first part of this Topic in which we covered covers the deep understanding of Secure Socket Layer, its position in the TCP/IP suit, its sub protocols and the working or Handshake Protocol.
Avoiding Man in the Middle Attack Based on ARP Spoofing in the LANEditor IJCATR
Â
As technology is running on its wheels, networking has turned into one of our basic aspects. In this world along with
networking inimical vulnerabilities are also advancing in a drastic manner, resulting in perilous security threats. This calls for the great
need of network security. ARP spoofing is one of the most common MITM attacks in the LAN. This attack can show critical
implications for internet users especially in stealing sensitive informationâs such as passwords. Beyond this it can facilitate other
attacks like denial of service(DOS), session hijacking etc..,. In this paper we are proposing a new method by encrypting MAC address
to shield from ARP cache poisoning
This paper discuss various wireless networks and their security, for each type, structure and related threats are described and how different techniques are applied to achieve security goals starting by general case
Welcome to International Journal of Engineering Research and Development (IJERD)IJERD Editor
Â
call for paper 2012, hard copy of journal, research paper publishing, where to publish research paper,
journal publishing, how to publish research paper, Call For research paper, international journal, publishing a paper, IJERD, journal of science and technology, how to get a research paper published, publishing a paper, publishing of journal, publishing of research paper, reserach and review articles, IJERD Journal, How to publish your research paper, publish research paper, open access engineering journal, Engineering journal, Mathemetics journal, Physics journal, Chemistry journal, Computer Engineering, Computer Science journal, how to submit your paper, peer reviw journal, indexed journal, reserach and review articles, engineering journal, www.ijerd.com, research journals
This paper analyzes vulnerabilities of the SSL/TLS
Handshake
protocol
, which
is
responsible
for
authentication of
the parties in the
communication
and
negotiation of
security parameters
that
will be used
to protect
confidentiality and
integrity of the
data
. It
will
be
analyzed the
attacks
against the implementation of Handshake
protocol, as well as the
attacks against the other
elements
necessary to SSL/TLS protocol to discover security
flaws that were exploited, modes of
attack, the potential consequences, but also studyi
ng methods of defense
.
All versions of the
protocol are going to be the subject of the researc
h but
emphasis will be placed
on the critical
attack that
the most endanger the safety of data.
The goal of
the research
is
to point out the
danger of
existence
of at least
vulnerability
in the SSL/TLS protocol
, which
can be exploited
and
endanger the safety of
the data
that should be protected.
This paper analyzes vulnerabilities of the SSL/TLS Handshake protocol, which is responsible for authentication of the parties in the communication and negotiation of security parameters that will be used to protect confidentiality and integrity of the data. It will be analyzed the attacks against the implementation of Handshake protocol, as well as the attacks against the other
elements necessary to SSL/TLS protocol to discover security flaws that were exploited, modes of
attack, the potential consequences, but also studying methods of defense. All versions of the
protocol are going to be the subject of the research but emphasis will be placed on the critical attack that the most endanger the safety of data. The goal of the research is to point out the
danger of existence of at least vulnerability in the SSL/TLS protocol, which can be exploited and endanger the safety of the data that should be protected.
Comparative Analysis of Open-SSL Vulnerabilities & Heartbleed Exploit DetectionCSCJournals
Â
Since its introduction in 1994 the Secure Socket Layer (SSL) protocol (later renamed to Transport Layer Security (TLS)) evolved to the de facto standard for securing the transport layer. SSL/TLS can be used for ensuring data confidentiality, integrity and authenticity during transport. A main feature of the protocol is its flexibility. Modes of operation and security aims can easily be configured through different cipher suites. During its evolutionary development process several flaws were found. However, the flexible architecture of SSL/TLS allowed efficient fixes in order to counter the issues. This paper presents an overview on theoretical and practical attacks of the last 20 years.
Improving the Secure Socket Layer by Modifying the RSA AlgorithmIJCSEA Journal
Â
Secure Socket Layer (SSL) is a cryptographic protocol which has been used broadly for making secure connection to a web server. SSL relies upon the use of dependent cryptographic functions to perform a secure connection. The first function is the authentication function which facilitates the client to identify the server and vice versa [1]. There have been used, several other functions such as encryption and integrity for the imbuement of security. The most common cryptographic algorithm used for ensuring security is RSA. It still has got several security breaches that need to be dealt with. An improvement over this has been implemented in this paper. In this paper, a modification of RSA has been proposed that switches from the domain of integers to the domain of bit stuffing to be applied to the first function of SSL that would give more secure communication. The introduction of bit stuffing will complicate the access to the message even after getting the access to the private key. So, it will enhance the security which is the inevitable requirement for the design of cryptographic protocols for secure communication.
Explain how SSL protocol is used to ensure the confidentiality and int.docxtodd401
Â
Explain how SSL protocol is used to ensure the confidentiality and integrity of the Internet traffic.
Solution
SSL uses a combination of public-key and symmetric-key encryption to secure a connection between two machines, typically a Web or mail server and a client machine, communicating over the Internet or an internal network.
Using the OSI reference model as context, SSL runs above the TCP/IP protocol, which is responsible for the transport and routing of data over a network, and below higher-level protocols such as HTTP and IMAP, encrypting the data of network connections in the application layer of the Internet Protocol suite. The \"sockets\" part of the term refers to the sockets method of passing data back and forth between a client and a server program in a network, or between program layers in the same computer.
The Transport Layer Security (TLS) protocol evolved from SSL and has largely superseded it, although the terms SSL or SSL/TLS are still commonly used; SSL is often used to refer to what is actually TLS. The combination of SSL/TLS is the most widely deployed security protocol used today and is found in applications such as Web browsers, email and basically any situation where data needs to be securely exchanged over a network, like file transfers, VPN connections, instant messaging and voice over IP.
The SSL protocol includes two sub-protocols: the record protocol and the \"handshake\" protocol. These protocols allow a client to authenticate a server and establish an encrypted SSL connection. In what\'s referred to as the \"initial handshake process,\" a server that supports SSL presents its digital certificate to the client to authenticate the server\'s identity. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards (PKCS). The authentication process uses public-key encryption to validate the digital certificate and confirm that a server is in fact the server it claims to be.
Once the server has been authenticated, the client and server establish cipher settings and a shared key to encrypt the information they exchange during the remainder of the session. This provides data confidentiality and integrity. This whole process is invisible to the user.
For example, if a webpage requires an SSL connection, the URL will change from HTTP to HTTPS and a padlock icon appears in the browser once the server has been authenticated.
The handshake also allows the client to authenticate itself to the server. In this case, after server authentication is successfully completed, the client must present its certificate to the server to authenticate the client\'s identity before the encrypted SSL session can be established.
.
Short questions :
Q1: What are computer VIRUS, WORM and Trojan horse?
Q2: What network protocols are used in Cloud Computing?
Q3: What is DOS Attack?
Q4: What is resource management in cloud computing?
Q5: What is difference between HTTP and HTTPs?
Q6: What is scheduling in Cloud?
Q7: What is difference between authentication and authorization? Explain.
Q8: What is data encryption? Discuss some current techniques used for encryption.
Q9: What is SSL?
Q10: What is Identity Management System? How it is helpful in Cloud Computing?
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
Â
As AI technology is pushing into IT I was wondering myself, as an âinfrastructure container kubernetes guyâ, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefitâs both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
Â
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. Whatâs changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
Â
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more âmechanicalâ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Â
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Â
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Â
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Â
Are you looking to streamline your workflows and boost your projectsâ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, youâre in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part âEssentials of Automationâ series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Hereâs what youâll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
Weâll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Donât miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Â
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Â
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Â
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But thereâs more:
In a second workflow supporting the same use case, youâll see:
Your campaign sent to target colleagues for approval
If the âApproveâ button is clicked, a Jira/Zendesk ticket is created for the marketing design team
Butâif the âRejectâ button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Dev Dives: Train smarter, not harder â active learning and UiPath LLMs for do...UiPathCommunity
Â
đĨ Speed, accuracy, and scaling â discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Miningâĸ:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing â with little to no training required
Get an exclusive demo of the new family of UiPath LLMs â GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
đ¨âđĢ Andras Palfi, Senior Product Manager, UiPath
đŠâđĢ Lenka Dulovicova, Product Program Manager, UiPath
1. 63 INFORMATION SECURITY
A.DHASARADHI
UNIT-VI
WEB SECURITY CONSIDERATIONS
The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets. The Web
presents new challenges not generally appreciated in the context of computer and network security:
The Internet is two way. Unlike traditional publishing environments, even electronic publishing systems involving teletext,
voice response, or fax-back, 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. This complex software may hide many
potential security flaws. The short history of the Web is filled with examples of new and upgraded systems, properly
installed, that are vulnerable to a variety of security attacks.
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 (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 Security Threats
Below table provides a summary of the types of security threats faced in using the Web. One way to group these threats is in terms
of passive and active attacks. Passive attacks include eavesdropping on network traffic between browser and server and gaining
access to information on a Web site that is supposed to be restricted. Active attacks include impersonating another user, altering
messages in transit between client and server, and altering information on a Web site.
Threats Consequences Countermeasures
Integrity
Modification of user data
Trojan horse browser
Modification of memory
Modification of message traffic in
transit
Loss of information
Compromise of machine
Vulnerabilty to all other
threats
Cryptographic
checksums
Confidentiality
Eavesdropping on the Net
Theft of info from server
Theft of data from client
Info about network configuration
Info about which client talks to
server
Loss of information
Loss of privacy Encryption, web
proxies
Denial of Service
Killing of user threads
Flooding machine with
bogus requests
Filling up disk or memory
Isolating machine by DNS attacks
Disruptive
Annoying
Prevent user from getting
work done
Difficult to
prevent
Authentication
Impersonation of legitimate users
Data forgery
Misrepresentation of user
Belief that false
information is valid
Cryptographic
techniques
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.
Below figure illustrates this difference. One way to provide Web security is to use IP Security. 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
that only selected traffic need incur the overhead of IPSec processing.
2. 64 INFORMATION SECURITY
A.DHASARADHI
Figure: Relative Location of Security Facilities in the TCP/IP Protocol Stack
Another relatively general-purpose solution is to implement security just above TCP (figure B). 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. For example, Netscape
and Microsoft Explorer browsers come equipped with SSL, and most Web servers have implemented the protocol.
Application-specific security services are embedded within the particular application. Figure C 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. In the context of Web
security, an important example of this approach is Secure Electronic Transaction (SET).
SECURE SOCKET LAYER AND TRANSPORT LAYER SECURITY
Netscape 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 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 below figure.
Figure: SSL Protocol Stack
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 and are examined later in this section.
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 (in the OSI layering model definition) 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.
A session state is defined by the following parameters (definitions taken from the SSL specification):
Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.
Compression method: The algorithm used to compress data prior to encryption.
3. 65 INFORMATION SECURITY
A.DHASARADHI
īˇī Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as MD5 or
SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash_size.
Master secret: 48-byte secret shared between the client and 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 conventional encryption key for data encrypted by the server and decrypted by the client.
Client write key: The conventional encryption key for data encrypted by the client and decrypted by the server.
Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key.
This field is first initialized by the SSL Handshake Protocol. Thereafter the final ciphertext block from each record is
preserved for use as the IV with the following record.
Sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for each
connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to
zero. Sequence numbers may not exceed 264 1.
SSL Record Protocol
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).
Below figure indicates 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, applies a MAC, encrypts, adds a header,
and transmits the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and reassembled and then
delivered to higher-level users.
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.
In SSLv3 (as well as the current version of TLS), no compression algorithm is specified, so the default compression algorithm is null.
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
hash(MAC_write_secret || pad_2 ||
hash(MAC_write_secret || pad_1 || seq_num ||
SSLCompressed.type ||
SSLCompressed.length || SSLCompressed.fragment))
Figure: SSL Record Protocol Operation
4. 66 INFORMATION SECURITY
A.DHASARADHI
where || = concatenation
MAC_write_secret = shared secret key
hash = cryptographic hash algorithm; either MD5 or SHA-1
pad_1 = the byte 0x36 (0011 0110) repeated 48 times (384 bits) for MD5 and 40 times (320 bits) for SHA-1
pad_2 = the byte 0x5C (0101 1100) repeated 48 times for MD5 and 40 times for SHA-1
seq_num = the sequence number for this message
SSLCompressed.type = the higher-level protocol used to process this fragment
SSLCompressed.length = the length of the compressed fragment
SSLCompressed.fragment = the compressed fragment (if compression is not used, the plaintext fragment)
Next, the compressed message plus the MAC are encrypted using symmetric encryption. Encryption may not increase the content
length by more than 1024 bytes, so that the total length may not exceed 214 + 2048. The following encryption algorithms are
permitted:
Block Cipher Stream Cipher
Algorithm Key Size Algorithm Key Size
AES 128,256 RC4-40 40
IDEA 128 RC4-128 128
RC2-40 40
DES-40 40
DES 56
3DES 168
Fortezza 80
Fortezza can be used in a smart card encryption scheme.
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 total amount of padding is the smallest amount such that
the total size of the data to be encrypted (plaintext plus MAC plus padding) is a multiple of the cipher's block length. An example is
a plaintext (or compressed text if compression is used) of 58 bytes, with a MAC of 20 bytes (using SHA-1), that is encrypted using a
block length of 8 bytes (e.g., DES). With the padding.length byte, this yields a total of 79 bytes. To make the total an integer
multiple of 8, one byte of padding is added.
The final step of SSL Record Protocol processing is to prepend 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.
The content types that have been defined are change_cipher_spec, alert, handshake, and application_data. The first three are the
SSL-specific protocols, discussed next. Note that no distinction is made among the various applications (e.g., HTTP) that might use
SSL; the content of the data created by such applications is opaque to SSL.
Figure: illustrates the SSL record format
Change Cipher Spec Protocol
5. 67 INFORMATION SECURITY
A.DHASARADHI
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 (figure a), 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.
Figure: SSL Record Protocol Payload
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.
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.
The remainder of the alerts are the following:
ī 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, rendering it unacceptable.
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. All of these have the format shown in
Figure C. Each message has three fields:
Type (1 byte): Indicates one of 10 messages. Below Table lists the defined message types.
Length (3 bytes): The length of the message in bytes.
Content (0 bytes): The parameters associated with this message; these are listed in Table.
Table 17.2. SSL Handshake Protocol Message Types
Message Type Parameters
hello_request null
client_hello version, random, session id, cipher suite, compression method
server_hello version, random, session id, cipher suite, compression method
certificate chain of X.509v3 certificates
server_key_exchange parameters, signature
certificate_request type, authorities
server_done null
certificate_verify signature
client_key_exchange parameters, signature
finished hash value
Below figure shows the initial exchange needed to establish a logical connection between client and server. The exchange can be
viewed as having four phases.
6. 68 INFORMATION SECURITY
A.DHASARADHI
Figure:
Handsha
ke Protocol Action
Transport Layer Security
TLS is an IETF standardization initiative whose goal is to produce an Internet standard version of SSL. TLS is defined as a Proposed
Internet Standard in RFC 2246. RFC 2246 is very similar to SSLv3. In this section, we highlight the differences.
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 1.
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 defined in RFC 2104.
7. 69 INFORMATION SECURITY
A.DHASARADHI
HMACK(M) = H[(K+ opad)||H[(K+ ipad)||M]]
Where
H = embedded hash function (for TLS, either MD5 or SHA-1)
M = message input to HMAC
K+ = secret key padded with zeros on the left so that the result is equal to the block length of the hash code(for MD5 and
SHA-1, block length = 512 bits)
ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits)
opad = 01011100 (5C in hexadecimal) repeated 64 times (512 bits)
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.
Alert Codes
TLS supports all of the alert codes defined in SSLv3 with the exception of no_certificate. A number of additional codes are defined
in TLS; of these, the following are always fatal:
decryption_failed: A ciphertext decrypted in an invalid way; either it was not an even multiple of the block length or its
padding values, when checked, were incorrect.
record_overflow: A TLS record was received with a payload (ciphertext) whose length exceeds 214 + 2048 bytes, or the
ciphertext decrypted to a length of greater than 214 + 1024 bytes.
unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA
certificate could not be located or could not be matched with a known, trusted CA.
access_denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed
with the negotiation.
decode_error: A message could not be decoded because a field was out of its specified range or the length of the
message was incorrect.
export_restriction: A negotiation not in compliance with export restrictions on key length was detected.
protocol_version: The protocol version the client attempted to negotiate is recognized but not supported.
insufficient_security: Returned instead of handshake_failure when a negotiation has failed specifically because the
server requires ciphers more secure than those supported by the client.
internal_error: An internal error unrelated to the peer or the correctness of the protocol makes it impossible to
continue.
The remainder of the new alerts include the following:
decrypt_error: A handshake cryptographic operation failed, including being unable to verify a signature, decrypt a key
exchange, or validate a finished message.
user_canceled: This handshake is being canceled for some reason unrelated to a protocol failure.
no_renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial
handshaking. Either of these messages would normally result in renegotiation, but this alert indicates that the sender is
not able to renegotiate. This message is always a warning.
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.
Client Certificate Types
TLS defines the following certificate types to be requested in a certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, and
dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea.
Ephemeral Diffie-Hellman involves signing the Diffie-Hellman parameters with either RSA or DSS; for TLS, the rsa_sign and dss_sign
types are used for that function; a separate signing type is not needed to sign Diffie-Hellman parameters. TLS does not include the
Fortezza scheme.
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. For example, if the plaintext (or compressed text if compression is
used) plus MAC plus padding.length byte is 79 bytes long, then the padding length, in bytes, can be 1, 9, 17, and so on, up to 249. A
variable padding length may be used to frustrate attacks based on an analysis of the lengths of exchanged messages.
8. 70 INFORMATION SECURITY
A.DHASARADHI
SECURE ELECTRONIC TRANSACTION
SET is an open encryption and security specification designed to protect credit card transactions on the Internet. The current
version, SETv1, emerged from a call for security standards by MasterCard and Visa in February 1996. A wide range of companies
were involved in developing the initial specification, including IBM, Microsoft, Netscape, RSA, Terisa, and Verisign. Beginning in
1996, there have been numerous tests of the concept, and by 1998 the first wave of SET-compliant products was available.
SET is not itself a payment system. Rather it is a set of security protocols and formats that enables users to employ the existing
credit card payment infrastructure on an open network, such as the Internet, in a secure fashion. In essence, SET provides three
services:
īļ Provides a secure communications channel among all parties involved in a transaction
īļ Provides trust by the use of X.509v3 digital certificates
īļ Ensures privacy because the information is only available to parties in a transaction when and where necessary
SET Overview
A good way to begin our discussion of SET is to look at the business requirements for SET, its key features, and the participants in
SET transactions.
Requirements
Book 1 of the SET specification lists the following business requirements for secure payment processing with credit cards over the
Internet and other networks:
Provide confidentiality of payment and ordering information: It is necessary to assure cardholders that this information is
safe and accessible only to the intended recipient. Confidentiality also reduces the risk of fraud by either party to the
transaction or by malicious third parties. SET uses encryption to provide confidentiality.
Ensure the integrity of all transmitted data: That is, ensure that no changes in content occur during transmission of SET
messages. Digital signatures are used to provide integrity.
Provide authentication that a cardholder is a legitimate user of a credit card account: A mechanism that links a
cardholder to a specific account number reduces the incidence of fraud and the overall cost of payment processing.
Digital signatures and certificates are used to verify that a cardholder is a legitimate user of a valid account.
Provide authentication that a merchant can accept credit card transactions through its relationship with a financial
institution: This is the complement to the preceding requirement. Cardholders need to be able to identify merchants
with whom they can conduct secure transactions. Again, digital signatures and certificates are used.
Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an
electronic commerce transaction: SET is a well-tested specification based on highly secure cryptographic algorithms and
protocols.
Create a protocol that neither depends on transport security mechanisms nor prevents their use: SET can securely
operate over a "raw" TCP/IP stack. However, SET does not interfere with the use of other security mechanisms, such as
IPSec and SSL/TLS.
Facilitate and encourage interoperability among software and network providers: The SET protocols and formats are
independent of hardware platform, operating system, and Web software.
Key Features of SET
To meet the requirements just outlined, SET incorporates the following features:
Confidentiality of information: Cardholder account and payment information is secured as it travels across the network.
An interesting and important feature of SET is that it prevents the merchant from learning the cardholder's credit card
number; this is only provided to the issuing bank. Conventional encryption by DES is used to provide confidentiality.
Integrity of data: Payment information sent from cardholders to merchants includes order information, personal data,
and payment instructions. SET guarantees that these message contents are not altered in transit. RSA digital signatures,
using SHA-1 hash codes, provide message integrity. Certain messages are also protected by HMAC using SHA-1.
Cardholder account authentication: SET enables merchants to verify that a cardholder is a legitimate user of a valid card
account number. SET uses X.509v3 digital certificates with RSA signatures for this purpose.
Merchant authentication: SET enables cardholders to verify that a merchant has a relationship with a financial institution
allowing it to accept payment cards. SET uses X.509v3 digital certificates with RSA signatures for this purpose.
Note that unlike IPSec and SSL/TLS, SET provides only one choice for each cryptographic algorithm. This makes sense, because SET
is a single application with a single set of requirements, whereas IPSec and SSL/TLS are intended to support a range of applications.
SET Participants
Below figure indicates the participants in the SET system, which include the following:
Cardholder: In the electronic environment, consumers and corporate purchasers interact with merchants from personal
computers over the Internet. A cardholder is an authorized holder of a payment card (e.g., MasterCard, Visa) that has
been issued by an issuer.
Merchant: A merchant is a person or organization that has goods or services to sell to the cardholder. Typically, these
goods and services are offered via a Web site or by electronic mail. A merchant that accepts payment cards must have a
relationship with an acquirer.
Issuer: This is a financial institution, such as a bank, that provides the cardholder with the payment card. Typically,
accounts are applied for and opened by mail or in person. Ultimately, it is the issuer that is responsible for the payment
of the debt of the cardholder.
9. 71 INFORMATION SECURITY
A.DHASARADHI
Acquirer: This is a financial institution that establishes an account with a merchant and processes payment card
authorizations and payments. Merchants will usually accept more than one credit card brand but do not want to deal
with multiple bankcard associations or with multiple individual issuers. The acquirer provides authorization to the
merchant that a given card account is active and that the proposed purchase does not exceed the credit limit. The
acquirer also provides electronic transfer of payments to the merchant's account. Subsequently, the acquirer is
reimbursed by the issuer over some sort of payment network for electronic funds transfer.
Payment gateway: This is a function operated by the acquirer or a designated third party that processes merchant
payment messages. The payment gateway interfaces between SET and the existing bankcard payment networks for
authorization and payment functions. The merchant exchanges SET messages with the payment gateway over the
Internet, while the payment gateway has some direct or network connection to the acquirer's financial processing
system.
Certification authority (CA): This is an entity that is trusted to issue X.509v3 public-key certificates for cardholders,
merchants, and payment gateways. The success of SET will depend on the existence of a CA infrastructure available for
this purpose. As was discussed in previous chapters, a hierarchy of CAs is used, so that participants need not be directly
certified by a root authority.
Figure: Secure Electronic Commerce Components
We now briefly describe the sequence of events that are required for a transaction. We will then look at some of the cryptographic
details.
1. The customer opens an account. The customer obtains a credit card account, such as MasterCard or Visa, with a bank that
supports electronic payment and SET.
2. The customer receives a certificate. After suitable verification of identity, the customer receives an X.509v3 digital certificate,
which is signed by the bank. The certificate verifies the customer's RSA public key and its expiration date. It also establishes a
relationship, guaranteed by the bank, between the customer's key pair and his or her credit card.
3. Merchants have their own certificates. A merchant who accepts a certain brand of card must be in possession of two certificates
for two public keys owned by the merchant: one for signing messages, and one for key exchange. The merchant also needs a copy
of the payment gateway's public-key certificate.
4. The customer places an order. This is a process that may involve the customer first browsing through the merchant's Web site to
select items and determine the price. The customer then sends a list of the items to be purchased to the merchant, who returns an
order form containing the list of items, their price, a total price, and an order number.
5. The merchant is verified. In addition to the order form, the merchant sends a copy of its certificate, so that the customer can
verify that he or she is dealing with a valid store.
6. The order and payment are sent. The customer sends both order and payment information to the merchant, along with the
customer's certificate. The order confirms the purchase of the items in the order form. The payment contains credit card details.
The payment information is encrypted in such a way that it cannot be read by the merchant. The customer's certificate enables the
merchant to verify the customer.
7. The merchant requests payment authorization. The merchant sends the payment information to the payment gateway,
requesting authorization that the customer's available credit is sufficient for this purchase.
8. The merchant confirms the order. The merchant sends confirmation of the order to the customer.
9. The merchant provides the goods or service. The merchant ships the goods or provides the service to the customer.
10. The merchant requests payment. This request is sent to the payment gateway, which handles all of the payment processing.
10. 72 INFORMATION SECURITY
A.DHASARADHI
Dual Signature
Before looking at the details of the SET protocol, let us discuss an important innovation introduced in SET: the dual signature. The
purpose of the dual signature is to link two messages that are intended for two different recipients. In this case, the customer
wants to send the order information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not
need to know the customer's credit card number, and the bank does not need to know the details of the customer's order. The
customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be
linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this
payment is intended for this order and not for some other goods or service.
To see the need for the link, suppose that the customers send the merchant two messages: a signed OI and a signed PI, and the
merchant passes the PI on to the bank. If the merchant can capture another OI from this customer, the merchant could claim that
this OI goes with the PI rather than the original OI. The linkage prevents this.
Below figure shows the use of a dual signature to meet the requirement of the preceding paragraph. The customer takes the hash
(using SHA-1) of the PI and the hash of the OI. These two hashes are then concatenated and the hash of the result is taken. Finally,
the customer encrypts the final hash with his or her private signature key, creating the dual signature. The operation can be
summarized as
DS = E(PRc, [H(H(PI)||H(OI)])
where PRc is the customer's private signature key. Now suppose that the merchant is in possession of the dual signature (DS), the
OI, and the message digest for the PI (PIMD). The merchant also has the public key of the customer, taken from the customer's
certificate. Then the merchant can compute the quantities
H(PIMS||H[OI]); D(PUc, DS)
where PUc is the customer's public signature key. If these two quantities are equal, then the merchant has verified the signature.
Similarly, if the bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer's public key, then the bank can
compute
H(H[OI]||OIMD); D(PUc, DS)
Figure: Construction of Dual Signature
Again, if these two quantities are equal, then the bank has verified the signature. In summary,
1. The merchant has received OI and verified the signature.
2. The bank has received PI and verified the signature.
3. The customer has linked the OI and PI and can prove the linkage.
For example, suppose the merchant wishes to substitute another OI in this transaction, to its advantage. It would then have to find
another OI whose hash matches the existing OIMD. With SHA-1, this is deemed not to be feasible. Thus, the merchant cannot link
another OI with this PI.
Payment Processing
Below table lists the transaction types supported by SET. In what follows we look in some detail at the following transactions:
īļ Purchase request
īļ Payment authorization
īļ Payment capture
11. 73 INFORMATION SECURITY
A.DHASARADHI
Table: SET Transaction Types
Cardholder registration Cardholders must register with a CA before they can send SET messages to merchants.
Merchant registration Merchants must register with a CA before they can exchange SET messages with
customers and payment gateways.
Purchase request Message from customer to merchant containing OI for merchant and PI for bank.
Payment authorization Exchange between merchant and payment gateway to authorize a given amount for a
purchase on a given credit card account.
Payment capture Allows the merchant to request payment from the payment gateway.
Cardholder registration Cardholders must register with a CA before they can send SET messages to merchants.
Certificate inquiry and status If the CA is unable to complete the processing of a certificate request quickly, it will
send a reply to the cardholder or merchant indicating that the requester should check
back later. The cardholder or merchant sends the Certificate Inquiry message to
determine the status of the certificate request and to receive the certificate if the
request has been approved.
Purchase inquiry Allows the cardholder to check the status of the processing of an order after the
purchase response has been received. Note that this message does not include
information such as the status of back ordered goods, but does indicate the status of
authorization, capture and credit processing.
Authorization reversal Allows a merchant to correct previous authorization requests. If the order will not be
completed, the merchant reverses the entire authorization. If part of the order will not
be completed (such as when goods are back ordered), the merchant reverses part of
the amount of the authorization.
Capture reversal Allows a merchant to correct errors in capture requests such as transaction amounts
that were entered incorrectly by a clerk.
Credit Allows a merchant to issue a credit to a cardholder's account such as when goods are
returned or were damaged during shipping. Note that the SET Credit message is always
initiated by the merchant, not the cardholder. All communications between the
cardholder and merchant that result in a credit being processed happen outside of SET.
Credit reversal Allows a merchant to correct a previously request credit.
Payment gateway certificate request Allows a merchant to query the payment gateway and receive a copy of the gateway's
current key-exchange and signature certificates.
Batch administration Allows a merchant to communicate information to the payment gateway regarding
merchant batches.
Error message Indicates that a responder rejects a message because it fails format or content
verification tests.
Purchase Request
Before the Purchase Request exchange begins, the cardholder has completed browsing, selecting, and ordering. The end of this
preliminary phase occurs when the merchant sends a completed order form to the customer. All of the preceding occurs without
the use of SET.
The purchase request exchange consists of four messages: Initiate Request, Initiate Response, Purchase Request, and Purchase
Response.
In order to send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the
payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. This message
includes the brand of the credit card that the customer is using. The message also includes an ID assigned to this request/response
pair by the customer and a nonce used to ensure timeliness.
The merchant generates a response and signs it with its private signature key. The response includes the nonce from the customer,
another nonce for the customer to return in the next message, and a transaction ID for this purchase transaction. In addition to the
signed response, the Initiate Response message includes the merchant's signature certificate and the payment gateway's key
exchange certificate.
The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the OI
and PI. The transaction ID assigned by the merchant is placed in both the OI and PI. The OI does not contain explicit order data
such as the number and price of items. Rather, it contains an order reference generated in the exchange between merchant and
customer during the shopping phase before the first SET message. Next, the cardholder prepares the Purchase Request message
(figure below). For this purpose, the cardholder generates a one-time symmetric encryption key, Ks. The message includes the
following:
1. Purchase-related information. This information will be forwarded to the payment gateway by the merchant and consists of
- The PI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The OI message digest (OIMD)
12. 74 INFORMATION SECURITY
A.DHASARADHI
The OIMD is needed for the payment gateway to verify the dual signature, as explained previously. All of these items are encrypted
with Ks. The final item is
- The digital envelope. This is formed by encrypting Ks with the payment gateway's public key-exchange key. It is called a digital
envelope because this envelope must be opened (decrypted) before the other items listed previously can be read.
The value of Ks is not made available to the merchant. Therefore, the merchant cannot read any of this payment-related
information.
2. Order-related information. This information is needed by the merchant and consists of
- The OI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The PI message digest (PIMD)
The PIMD is needed for the merchant to verify the dual signature. Note that the OI is sent in the clear.
3. Cardholder certificate. This contains the cardholder's public signature key. It is needed by the merchant and by the payment
gateway.
Figure: Cardholder Sends Purchase Request
When the merchant receives the Purchase Request message, it performs the following actions (Figure below):
1. Verifies the cardholder certificates by means of its CA signatures.
2. Verifies the dual signature using the customer's public signature key. This ensures that the order has not been tampered with in
transit and that it was signed using the cardholder's private signature key.
3. Processes the order and forwards the payment information to the payment gateway for authorization (described later).
4. Sends a purchase response to the cardholder.
The Purchase Response message includes a response block that acknowledges the order and references the corresponding
transaction number. This block is signed by the merchant using its private signature key. The block and its signature are sent to the
customer, along with the merchant's signature certificate.
When the cardholder software receives the purchase response message, it verifies the merchant's certificate and then verifies the
signature on the response block. Finally, it takes some action based on the response, such as displaying a message to the user or
updating a database with the status of the order.
13. 75 INFORMATION SECURITY
A.DHASARADHI
Figur
e:
Merc
hant
Verifies Customer Purchase Request
Payment Authorization
During the processing of an order from a cardholder, the merchant authorizes the transaction with the payment gateway. The
payment authorization ensures that the transaction was approved by the issuer. This authorization guarantees that the merchant
will receive payment; the merchant can therefore provide the services or goods to the customer. The payment authorization
exchange consists of two messages: Authorization Request and Authorization response.
The merchant sends an Authorization Request message to the payment gateway consisting of the following:
1. Purchase-related information. This information was obtained from the customer and consists of
- The PI
- The dual signature, calculated over the PI and OI, signed with the customer's private signature key
- The OI message digest (OIMD)
- The digital envelope
2. Authorization-related information. This information is generated by the merchant and consists of
- An authorization block that includes the transaction ID, signed with the merchant's private signature key and encrypted with a
one-time symmetric key generated by the merchant
- A digital envelope. This is formed by encrypting the one-time key with the payment gateway's public key-exchange key.
3. Certificates. The merchant includes the cardholder's signature key certificate (used to verify the dual signature), the merchant's
signature key certificate (used to verify the merchant's signature), and the merchant's key-exchange certificate (needed in the
payment gateway's response).
14. 76 INFORMATION SECURITY
A.DHASARADHI
The payment gateway performs the following tasks:
1. Verifies all certificates
2. Decrypts the digital envelope of the authorization block to obtain the symmetric key and then decrypts the authorization block
3. Verifies the merchant's signature on the authorization block
4. Decrypts the digital envelope of the payment block to obtain the symmetric key and then decrypts the payment block
5. Verifies the dual signature on the payment block
6. Verifies that the transaction ID received from the merchant matches that in the PI received (indirectly) from the customer
7. Requests and receives an authorization from the issuer
Having obtained authorization from the issuer, the payment gateway returns an Authorization Response message to the merchant.
It includes the following elements:
1. Authorization-related information. Includes an authorization block, signed with the gateway's private signature key and
encrypted with a one-time symmetric key generated by the gateway. Also includes a digital envelope that contains the one-time
key encrypted with the merchants public key-exchange key.
2. Capture token information. This information will be used to effect payment later. This block is of the same form as (1), namely, a
signed, encrypted capture token together with a digital envelope. This token is not processed by the merchant. Rather, it must be
returned, as is, with a payment request.
3. Certificate. The gateway's signature key certificate.
With the authorization from the gateway, the merchant can provide the goods or service to the customer.
Payment Capture
To obtain payment, the merchant engages the payment gateway in a payment capture transaction, consisting of a capture request
and a capture response message.
For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which includes the
payment amount and the transaction ID. The message also includes the encrypted capture token received earlier (in the
Authorization Response) for this transaction, as well as the merchant's signature key and key-exchange key certificates.
When the payment gateway receives the capture request message, it decrypts and verifies the capture request block and decrypts
and verifies the capture token block. It then checks for consistency between the capture request and capture token. It then creates
a clearing request that is sent to the issuer over the private payment network. This request causes funds to be transferred to the
merchant's account.
The gateway then notifies the merchant of payment in a Capture Response message. The message includes a capture response
block that the gateway signs and encrypts. The message also includes the gateway's signature key certificate. The merchant
software stores the capture response to be used for reconciliation with payment received from the acquirer.