Secure Multiparty Computation

Alice adds a secret random number to her salary, encrypts the result with
Bob's public key, and sends it to Bob.
Bob decrypts Alice's result with his private key. He adds his salary to what
he received from Alice, encrypts the result with Carol's public key, and
sends it to Carol.
Carol decrypts Bob's result with her private key. She adds her salary to what
she received from Bob, encrypts the result with Dave's public key, and
sends it to Dave.
Dave decrypts Carol's result with his private key. He adds his salary to what
he received from Carol, encrypts the result with Alice's public key, and
sends it to Alice.
Alice decrypts Dave's result with her private key. She subtracts the random
number from step (1) to recover the sum of everyone's salaries.
Alice divides the result by the number of people (four, in this case) and
announces the result.
Virtual Elections:

Electronic voting systems provide significant advantages to

conventional voting and save significant resources in the process of
setup, distributing, voting, collecting and counting of ballots. However,
for all the above savings electronic voting systems must provide
security in each stage of the process to avoid any compromise on the
authenticity of the results. These concerns of verifiability and security
need to addressed appropriately especially if electronic voting is
performed over the internet. This project aims at providing one such
secure framework by implementing a secure election voting protocol
that maintains privacy and ensures fairness of the elections.
 The protocol that this project will implement must satisfy the following
requirements:
• Only authorized voters can vote.
• No one can vote more than once.
• No one can determine for whom anyone else voted.
• No one can duplicate anyone else's votes.
• Every voter can make sure that his vote has been taken into account in the
final tabulation.

Entities
A secure voting protocol essentially entails communication between three different
entities:-
1. Voter: The person who will be using the electronic voting system to cast his vote.
2. CLA (Central Legitimization Agency): The task of CLA is to certify the voters. The CLA
assigns validation numbers to the voters and maintains a list of validation numbers and
voters to avoid any voter from voting twice.
3. CTF (Central Tabulating Agency): The task of CTF is to count the votes. CTF receives
the vote and validation number from voters and records the vote for a particular
election candidate and updates the validation number as “voted” to prevent the same
voter from voting twice.
The electronic voting process can be divided into following four phases:-

Phase 1: In this phase, the voters and CLA communicate and the validated
voters receive validation numbers.
Phase 2: In this phase, the CLA and CTF communicate, and CLA transfers the
list of validation numbers to the CTF.
Phase 3: In this phase, the voters cast their votes to the CTF.
Phase 4: In this phase, the CTF declares the results of the electronic voting
process.

Underlying security support :

To support the necessary security requirements of our protocol we will be using

SSL (Secure Sockets Layer) in the underlying implementation. SSL is a
cryptographic protocol that provides secure communication using message
encryption and authentication between two communication parties. This helps us
in implementing the privacy and authentication needs of our protocol.
Figure : The above figure describes the message flow protocol during various stages in the
electronic voting system.
 single sign-on

SSO can be defined as a user experience of logging in just once and being able to navigate
across many applications seamlessly without a need to enter credentials for each
application. It is very common for organizations to have many applications running to take
care of different business functions. SSO makes it easy for the users to login once and be
able to access all the applications they can, reducing the need for users to remember a
plethora of logins and passwords.
 How can SSO products address security issues in an organization?

Reduces the need for users to remember many logins & passwords and hence reduces
the chance of users following insecure practices like writing the passwords on post-it slips
pasted to their workstations etc.
 Central enforcement and administration of security policies on the applications
participating in SSO.
 Enforcing restrictions on passwords like minimum length, having at least one special
character, character in upper case, numeric digit, etc.
Forgotten password recovery mechanism can alleviate a user from the fear of forgetting
passwords
Enforcing change of password on first login or after password reset by an administrator.
Expiring passwords after a specified amount of time.
Session timeout. A user session can be timed out because the session has been inactive
for a specified amount of time (called inactivity session timeout) or because the user
session has been in progress continuously for a specified amount of time say, the last 2
hours (called absolute timeout).
 Advanced monitoring and reporting capabilities.
secure inter branch payment transactions:

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.
Current EPS Architecture:
EPS is used to transmit payment details from the payer branch to the payee branch via
the central server in Mumbai
A typical payment transfer takes the following steps:
1. A data-entry person in the Payer Branch enters transaction details through the EPS interface.
2. A Bank Officer checks the validity of the transaction through the EPS interface.
3. After validating the transaction, the Bank Officer authorizes the transaction. Authorized transaction is
stored in a local Payment Master (PM) database.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. The transaction is transferred and stored in the IN directory of the Payee Branch.
11. The interface program at the Payee Branch collects the transaction and posts it in PM.
12. PM marks the credit entry and returns back an acknowledgement of the same. The acknowledgement is
placed in OUT directory of the Payee Branch.
13. The acknowledgement is picked by GBI-Transfer at the Payee Branch and sent to the EPS central office
through the VSAT.
14. The EPS central office receives the credit acknowledgement and forwards it to Payer Branch.
15. The Payer Branch receives the credit acknowledgement receipt. This completes the transaction
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

Fig: New EPS transaction flow at the Payer Branch

Fig: New EPS transaction flow at the Payee Branch
Cross Site Scripting Vulnerability (CSSV):

Cross-site scripting is what happens when an attacker takes advantage of a vulnerability

in a webpage to inject their own code. That code can steal user information such as
credentials, session cookies, and other sensitive data, and can even live persistently on
a site to attack multiple users.

A XSS attack is unique because these vulnerabilities don't target the website or web
app they exploit—it's only an attack vector. XSS uses scripts that are executed on a
user's machine; these scripts are called client-side scripts. The vast majority of these
are coded in JavaScript or HTML, though there are other languages that can be used
for client-side scripts.

XSS attacks fall into two categories: Reflected and stored attacks.
Reflected attacks are quick, one-off attacks that rely on server-side scripts not
properly sanitizing requests to eliminate scripts or other embedded objects.
An attacker using a reflected XSS attack has to get a user to click on a link, either
through email, a malicious website, or elsewhere. The link contains a malicious script
that a vulnerable website won't strip away through sanitization, thus bouncing the
script off the site and onto the user's computer.

Stored attacks, while less common, are far more dangerous and destructive than
reflected attacks. Unlike reflected attacks, which have minimal interaction with a
website, stored attacks exploit a site to get it to save the malicious script an attacker
wants to run on targeted computers.
A stored attack requires a website to store user information in a public place, such as a
social media platform, online forum, third-party retail site, or similar site. More
specifically, attackers require the website to allow unsanitized HTML to be embedded in
the site that visitors would be unknowingly subjected to simply by viewing the page. As
with a reflected attack, the script embedded in the infected content wouldn't be visible,
so no suspicion is raised.
Unlike reflected attacks, which require a user to click on a link, stored attacks don't
require any interaction from the user. Examples of stored attacks could include
embedding a XSS in a username, a blog post, a product description, a forum post, or
anywhere else unsanitized user-generated HTML content is allowed