This configuration offers several advantages:

• There are now three levels of defense to thwart intruders

• The outside router advertises only the existence of the screened subnet to the Internet;
therefore the internal network is invisible to the Internet
• Similarly, the inside router advertises only the existence of the screened subnet to the
internal network; hence systems on the inside network cannot construct direct routes to the
Internet
CASE STUDIES ON CRYPTOGRAPY AND SECURITY

Secure Inter-branch Payment Transactions

 Points for classroom discussions
1. What is the technology to achieve non-repudiation? How is this guaranteed?
2. How is the problem of key distribution resolved in PKI?
3. Why are cryptographic toolkits required?
4. How can smart cards be used in cryptography?
General Bank Of India (GBI) has implemented an Electronic Payment System called as EPS
in about 1200 branches across the country. This system transfers payment instructions
between two computerized branches of GBI. A central server is maintained at the EPS office
located in Mumbai. The branch offices connect to the Local VSAT of a private network by
using dial-up connection. The local VSAT has a connectivity established with the EPS office.
GBI utilizes its proprietary messaging service called as GBI-Transfer to exchange payment
instructions. Currently, EPS has minimal data security. As the system operates in a closed
network, the current security infrastructure may suffice the need. The data moving across the
network is in encrypted format.
Current EPS Architecture EPS is used to transmit payment details from the payer branch to
the payee branch via the central server in Mumbai which is also described stepby- step.

 A data-entry person in the Payer Branch enters transaction details through the EPS
interface.
 A Bank Officer checks the validity of the transaction through the EPS interface.
 After validating the transaction, the Bank Officer authorizes the transaction.
Authorized transaction is stored in a local Payment Master (PM) database.

 Once the transaction is stored in PM, a copy of the same is encrypted and stored in a
file. This transaction file is stored in OUT directory.

 The GBI-Transfer application looks for any pending transactions (i.e. for the presence
of any files in the OUT directory) by a polling mechanism and if it finds such
 transactions, it sends all these files one-by-one to the EPS central office located in
Mumbai by dialing the local VSAT.

 The local VSAT gets connectivity to the EPS central office and the transaction is
transferred and
stored in the IN directory at the EPS central office.

 The interface program at the EPS central office collects the file pending in the IN
directory and sends it to the PM application at that office.

 In order to send the Credit Request to PM, the transaction headers are changed. The
transaction with changed headers in encrypted format is then placed in OUT directory
of the EPS central office.

 The GBI-Transfer application at the EPS central office collects the transactions
pending in the OUT directory and sends them to the Payee Bank through the VSAT.

 The transaction is transferred and stored in the IN directory of the Payee Branch.

 The interface program at the Payee Branch collects the transaction and posts it in PM.

 PM marks the credit entry and returns back an acknowledgement of the same. The
acknowledgement is placed in OUT directory of the Payee Branch.

 The acknowledgement is picked by GBI-Transfer at the Payee Branch and sent to the
EPS central office through the VSAT.

 The EPS central office receives the credit acknowledgement and forwards it to Payer
Branch.

 The Payer Branch receives the credit acknowledgement receipt. This completes the
transaction.

Requirements to Enhance EPS As GBI is in the process of complete automation and setting
up connectivity over the Internet or a private network, they need to ensure stringent security
measures, which demand the usage of a Public Key Infrastructure (PKI) framework.
As a part of implementing security, GBI wants the following aspects to be ensured:
• Non-repudiation (Digital Signatures)
• Encryption – 128-bit (Upgrade to the current 56-bit encryption)
• Smart card support for storing sensitive data & on-card digital signing
• Closed loop Public Key Infrastructure :
Proposed Solution Since providing cryptographic functionalities require the usage of a
cryptographic toolkit, it is assumed that GBI will implement an appropriate Certification
Authority (CA) infrastructure and a PKI infrastructure offering.
The transaction will be digitally signed and encrypted/decrypted at the Payer and Payee
branches, as well as at the EPS central office. The signing operation can be performed on the
system or on external hardware like a smart card. On the server side, a provision of
automated signing without any manual intervention will be provided.
The transaction flow described earlier would now be split into two legs:
• The Payer Leg (Payer Branch to the EPS central office)
• The Payee Leg (EPS central office to the Payee Branch)

Cross Site Scripting Vulnerability (CSSV)

Points for classroom discussions
 What is the purpose of scripting technologies on the Internet?
 What can prevent CSSV attacks?
 What sort of testing can the creators of a Web site perform in order to guard against possible
CSSV attacks?
Cross Site Scripting Vulnerability (CSSV) is a relatively new form of attacks that exploits
inadequate validations on the server-side. The term Cross Server Scripting Vulnerability
(CSSV) is actually not completely correct. However, this term was coined when the problem
was not completely understood and has stuck ever since. Cross-site scripting happens when
malicious tags and/or scripts attack a Web browser via another site’s dynamically generated
Web pages. The attacker’s target is not a Website, but rather its users (i.e. clients or
browsers).
The idea of CSSV is quite simple to understand and is based on exploiting the scripting
technologies, such as JavaScript, VBScript or JScript. Let us understand how this works.
Consider the following Web page containing a form as shown in Fig. 10.9, in which the user
is expected to enter her postal address. Suppose that the URL of the site sending this page is
www.test.com and when the user submits this form, it would be processed by a server-side
program called as address.asp.
We would typically expect the user to enter the house number, street name, city, postal code
and country, etc. However, imagine that the user enters the following weird string, instead:

<SCRIPT>Hello World</SCRIPT>
As a result, the URL submitted would be something like www.test.com/address.asp?address=
<SCRIPT>Hello World </SCRIPT>.
Now suppose that the server-side program address.asp does not validate the input sent by the
user and simply sends the value of the field address to the next Web page. What would this
translate to? It would mean that the next Web page would receive the value of address as
<SCRIPT>Hello World</ SCRIPT>.
As we know, this would most likely treat the value of the address field as a script, which
would be executed as if it is written in a scripting language, such as JavaScript etc on the
Web browser. Therefore, the user would get to see Hello World.
Virtual Elections
Points for classroom discussions
 Is it technically possible to have elections on the Internet? How? What sort of
infrastructure would be needed for this?
 What would be the main concerns in such a virtual election?
 What would be the use of digital signatures and encryption in virtual elections?

Another situation where cryptography is useful is virtual elections. Computerized voting

would become quite common in the next few decades. As such, it is important that the
protocol for irtual

Fig. Secret splitting

P Original secret

≈ XOR

R Random Number

S Combined secret

Alice gets only S Bob gets only R

They must come together; combine their

respective secrets (S and R) to generate the
original secret (P).

elections should protect individual privacy and should also disallow cheating. Consider the
following protocol in order that voters can send their votes electronically to the Election
authority (EA).
  Each voter casts the vote and encrypts it with the public key of the EA.

 Each voter sends the encrypted vote to the EA.

 The EA decrypts all the votes to retrieve the original vote, tabulates all the votes
and announces the result of the election.

Is this protocol secure and does it provide comfort both to the voters as well as to the EA?
Not at all!
There are following problems in this scheme:

 The EA does not know whether the authorized voters have voted or it has
received fake (bogus) votes.
 Secondly, there is no mechanism to prevent duplicate voting.
What is the advantage of this protocol? Clearly, no one would be able to change another
voter’s vote, because it is first encrypted with the EA’s public key and is then sent to the EA.
However, if we observe this scheme carefully, an attacker need not change someone’s vote at
all. The attacker can simply send duplicate votes!
How can we improve upon this protocol to make it more robust? Let us rewrite it, as follows:
 Each voter casts the vote and signs it with her private key.
 Each voter then encrypts the signed vote with the public key of the EA.
 Each voter sends the vote to the EA.
 The EA decrypts the voter with its private key and verifies the signature of the
voter with the help of the voter’s public key.
 The EA then tabulates all the votes and announces the result of the election.
This protocol would now ensure that duplicate voting is disallowed. Because the voter has
signed the vote (with her private key) in Step 1, this can be checked. Similarly, no one can
change another voter’s vote. This is because a vote is digitally signed and any changes to it
will be detected and exposed in the signature verification process.
Although this protocol is a lot better, the trouble with this scheme is that the EA would come to
know who voted for whom, leading to privacy concerns. We shall leave it to the reader to
figure out how this problem can be solved.