1. 1
API SECURITY
(POSSIBLE ATTACKS ON APIs OF UPI
AND ATTACKS ON PIN PROCESSING API)
KRISHNA MURARI VIKAS MAURYA
B.TECH 2nd
YEAR COMPLETED B.TECH 3rd YEAR COMPLETED
ELECTRICAL ENGINEERING, COMPUTER SCIENCE ENGINEERING,
IIT ROORKEE IIT (BHU)
EMAIL: krishna.murari34@gmail.com EMAIL:vikas.maurya.cse12@iitbhu.ac.in
Project Guide
Radha krishna Akella
Associate Vice President,
NPCI ,Hyderabad

2. 2
INSTITUTE OF DEVELOPMENT AND RESEARCH IN BANKING TECHNOLOGY
(IDRBT)
Road No. 1, Castle Hills, Masab Tank,
Hyderabad-500057
CERTIFICATE
This is to certify that Mr Krishna Murari, pursuing B.Tech in Electrical Engineering at
IIT ROORKEE and Mr Vikas Maurya pursuing B.Tech in Computer Science
Engineering at IIT (BHU) have undertaken a project as an intern at IDRBT,
Hyderabad from May 6, 2015 to July 6, 2015 and May 18, 2015 to July 10,2015
respectively. He has successfully completed project titled “API SECURITY
(POSSIBLE ATTACKS ON APIs OF UPI AND ATTACKS ON PIN PROCESSING
API)”under my guidance. During the course of the project he has undertaken the
study of “API security” in detail and did an excellent work. I wish him all the best for
all his future endeavours.
RADHA KRISHNA AKELLA
(Project Guide)
Associate Vice President
NPCI, HYDERABAD

3. 3
ACKNOWLEDGEMENT
I would like to express my sincere gratitude to the Institute for Development and
Research in Banking Technology (IDRBT) and particularly Mr.Radha Krishna Akella,
Associate Vice President, NPCI Hyderabad who was my guide in this project. I would
not hesitate to add that this short stint in IDRBT has added a different facet to my life
as this is a unique organization being a combination of academics, research,
technology, communication services, crucial applications etc. and at the same time
performing roles as an arm of regulation, spread of technology, facilitator for
implementing technology in banking and non-banking system. I am extremely
grateful to Mr.Radha Krishna Akella for his advice, innovative suggestions and
supervision. I thank him for introducing me to a different aspects of “API
SECURITY(POSSIBLE ATTACKS ON APIs OF UPI AND ATTACKS ON PIN
PROCESSING API)”.I am thankful for IDRBT for providing such an amazing platform
to work on real application oriented research. I would like to give special thanks to
Mr.Vedula Sridhar, Senior Manager, NPCI, HYDERABAD for providing resources
and motivation in carrying out this project. Finally, I thank one and all who made this
project successful either directly or indirectly.
KRISHNA MURARI, VIKAS MAURYA
ELECTRICAL ENGINEERING, COMPUTER SCIENCE ENGINEERING,
IIT ROORKEE IIT (BHU)

4. 4
Index
1. Introduction..............................................................................................................6
1.1 API –new technology, old threats
1.2 Definition of API security
1.3 UPI (Unified Payment Interface)
1.4 Need of security in UPI
1.5 APIs used in UPI
2. API attacks..………………....................................................................................17
2.1 Basic API attacks
2.2 proposed solution to avoid xml poisoning
2.3 Crypto key API
2.4 Pin Processing API
2.5Formal model to fix pin processing attacks
3. Mitigation Guidance............................................................................................20
3.1 Various Ways of Tackling API attacks
3.2 Which to choose REST API OR SOAP?
Summary...................................................................................................................21
Future Scope.............................................................................................................22
References................................................................................................................23

5. 5
ABSRTACT
With Internet becoming ubiquitous in every aspect of our life, there is an
increase in the web applications providing day to day services like banking,
shopping, mailing services, news updates, etc. But most of these applications
have vulnerabilities or security loopholes like Cross site scripting (XSS),
Cross-site request forgery (CSRF), SQL Injection which are being exploited
by the hackers for malicious purposes. Hence there is a need for
API’s/automated security tools to identify and/or prevent these vulnerabilities
before the application goes live. My project focuses on API Security. By
definition API security is an Application Program Interface that allows
untrusted code to access sensitive resources in a secure way. This project
focuses on various API attacks mostly attacks on PIN Processing API, a study
of APIs used in UPI (Unified Payment Interface) and mitigation techniques to
overcome these attacks. One solution of mitigating XML poisoning might be
to encrypt the whole XML document instead of encrypting an XML element or
encrypting XML element content. We undergo through known attacks on the
PIN processing API used in the ATM (cash machine) network. This API
controls access to the tamper-resistant Hardware Security Modules where
PIN encryption, decryption and verification take place. PIN Processing APIs
are under Differential Attacks whereby attacker gains information about the
plaintext values of encrypted customer PINs by making changes to the non-
confidential inputs to a command.PIN processing APIs can be extended with
MACs to counteract differential attacks.

6. 6
1. INTRODUCTION:
The application programming interface (API) is an emerging technology for
integrating applications using Web technology. This approach is exploding in
popularity because it builds on well-understood techniques and leverages some
existing infrastructure. But it is a mistake to think you can secure APIs using the
same methods and technology with which we secured the browser-centric Web.
APIs are fundamentally different from websites and have an entirely unique risk
profile that must be addressed .APIs expose data or functionality for use by apps
and the developers that create them. They make enterprise assets reachable by
apps, and they’re the tool that enterprises use to add a digital layer to their
interactions with customers, employees, and partners’ .A security API is an
Application Program Interface that allows less trusted code to access sensitive
resources in a secure way. Examples of security APIs include the interface
between the tamper-resistant chip on a smartcard (trusted) and the card reader
(less trusted), the interface between a cryptographic Hardware Security Module,
or HSM (trusted) and the client machine (less trusted), and the Google maps API
(an interface between a server, trusted by Google, and the rest of the
Internet).The crucial aspect of a security API is that it is designed to enforce a
policy, i.e. no matter what sequence of commands in the interface are called, and
no matter what the parameters, certain security properties should continue to
hold. This means that if the less trusted code turns out to be malicious (or just
faulty), the carefully designed API should prevent compromise of critical data.
Designing such an interface is extremely tricky even for experts. A number of
security flaws have been found in APIs in use in deployed systems in the last
decade .APIs expose corporate data in very deliberate and thoughtful ways, but,
as with any technology that involves enterprise data, security should always be a
prime concern. With the explosive growth in API use, business unit leaders at
companies that are undergoing digital transformations are calling upon their
CSOs to ensure the security of APIs. Security must be built into the APIs
themselves. But that’s not enough.Threat protection, identity services,
infrastructure security, and compliance also must be top of mind for the CSO.
1.1New Technology, Old Threats:
APIs may represent a relatively new technology, but they are susceptible
to many of the same risks that have plagued computing since the early
days of the Internet. SQL injection, for example, has its roots in the
beginning of client/server programming. One would expect that, by now,
developers would be well versed in countermeasures for coping with such

7. 7
a mature attack. But SQL injection migrated easily into Web apps and it is
now seeing a significant resurgence as more organizations publish
Internet-facing APIs linked directly into their application infrastructures
.APIs are windows into applications and—as with any window—an API
can easily be misused. Well-designed APIs have the quality of self-
description; a good developer should be able to intuit how to use an API
simply by inspecting its URL, the input parameters and any returned
content. However, this same clarity often exposes the underlying
implementation of an application—details that would otherwise be
obfuscated by developers of Web app functionality. The transparency an
API provides into the internal structure of an application often gives
hackers dangerous clues that may lead to attack vectors they might
otherwise have overlooked. Not only do APIs put applications under the
hacker microscope, they also offer greater potential for nefarious control,
by increasing the attack surface on client applications. APIs give client-
side developers—both legitimate developers and potential system
crackers—much more finely-grained access into an application than a
typical Web app. This is because the granularity boundary for calls to
backend tiers moves from relatively secure internal tiers (those that reside
safely in a DMZ) all the way out to the client application residing on the
Internet..A typical Web app consolidates finely-grained operations—such
as calls to a data tier—behind simple Web pages. On the traditional,
HTML-oriented Web, interactions were limited to basic form interactions.
This reduced the range of potential interactions and—in doing so—
reduced overall exposure, particularly if the application properly sanitized
its inputs. APIs, in contrast, move this granularity boundary all the way out
to the client application itself. This offers a hacker considerably more
avenues to exploit. Rather than having one simple form acting as a proxy
for many internal calls to backend resources, an API-driven application
may individually make all these calls on its own and any of them may
expose vulnerabilities. This growth in attack surface increases the risk an
organization must manage as it publishes APIs to the greater Internet.
1.2 API security:
API security, and the security of the infrastructures these APIs are running
on, is of paramount importance to a CSO at an enterprise that is exposing
digital assets. Exposure entails enabling external access by apps. How do
you do that? You build an API tier, either from scratch or with the help of a
vendor. The goal of today’s API tier is to allow a large number of apps,

8. 8
which are often mobile and created by your partner channels or new
application teams, to access content and data from internal systems.
API Tier Architecture:
 A typical API centric architecture is composed of an exposure and a
consumption side:
 Exposure - Rather than having app developers consume your services
directly, they access an API proxy. The API proxy functions as a mapping of
a publicly available HTTP endpoint to your backend service. By creating an
API proxy you let an API infrastructure handle the security and authorization
tasks required to protect your services, manage data transformations and
filtering, execute conditional logic or custom code, and perform many other
actions.
 Consumption - Includes capabilities that enable developers to build and
deploy apps in a secure way, engage with a developer community, build
compelling and feature rich apps (push notification, Geolocation, social, and
so on) and help manage application life cycles via self-service APIs and
developer portals.
1.3UNIFIED PAYMENT INTERFACE:

9. 9
Objectives of a unified system is to offer an architecture and a set of
standard APIs to facilitate the next generation online immediate payments,
leveraging trends such as increasing Smartphone adoption, Indian
language interfaces, and universal access to Internet and data. The
Mission statement indicates RBI’s renewed commitment towards providing
a safe, efficient, accessible, inclusive, interoperable and authorised
payment and settlement systems for the country.
UPI provides the following core features via a set of APIs:-
a) Ability to use personal mobile as the primary device for all payments
including person to person, person to entity, and entity to person.
b) Ability to use personal mobile to "pay" someone (push) as well as "collect"
from someone (pull).
c) Ability to use Aadhaar number, mobile number, card number, and account
number in a unified way. In addition, ability to pay and collect using "virtual
payment addresses" that are "aliases" to accounts that may be
payee/amount/time limited providing further security features.
d) Make payments only by providing an address without having to ever provide
account details or credentials on 3rd party applications or websites.
e) Ability for sending “collect” requests to others (person to person or entity to
person) with "pay by" date to allow customer to pay at a later date without
having to block the money in the account.
f) Ability to pre-authorize multiple recurring payments similar to ECS (utilities,
school fees, subscriptions, etc.) with a one-time secure authentication and
rule based access.
g) Ability for all PSPs to use a standard set of APIs for any-to-any push and pull
payments.
h) Ability to have PSP provided mobile applications that allow paying from any
account using any number of virtual addresses using credentials such as
passwords, PINs, or biometrics.
Following diagram shows the overall architecture of the unified interface allowing
USSD, Smartphone, Internet banking, and other channel integration onto a common
layer at NPCI. This common layer orchestrates these transactions and ensures
settlement across accounts using systems such as IMPS, AEPS, NFS, E-com etc.
3rd party API integration (merchant sites, etc.) can "collect" payment from “an
address” avoiding the need to share account details or credentials on 3rd party
applications or websites. Within this solution, payment authentication and
authorization are always done using personal phone.

10. 10
Since this layer offers a unified interface, any-to-any (Aadhaar number, mobile,
account, virtual addresses) payments to be done using standard set of APIs.
a) Every payment has the following core elements:
a) Payer and payee account and institution details for routing and
authorization
b) Authentication credentials (password, PIN, biometrics, CVV, etc. as
required for debit, can be bank provided or 3rd party provided such as
UIDAI)
c) Transaction amount
d) Transaction reference
e) Timestamp
f) Other metadata attributes such as location, product code, mobile
number, device details, etc. as required.
1.4NEED OF SECURITY IN UPI:
Security Considerations are important since customer secret data needs to
be protected while capturing and transmitting to various switches.
For data security, the following classes of information are defined:
a) Sensitive Data - Data such as PIN, passwords, biometrics, etc.
These are not to be stored and should only be transported in
encrypted form.
b) Private Data - Data such as account number. This information may
be stored by the PSP, but only in encrypted form.
c) Non-Sensitive data - Name, transaction history (amount,
timestamp, response code, location, etc.) that can be stored in
unencrypted form. We need to Protect Authentication Credentials
for which trusted common library for credential
(MPIN/Password/PIN/Biometrics etc) capture is provided by NPCI.

11. 11
This library needs to be integrated with PSP application.
Authentication credentials are secret data which should be captured
and encrypted within the common library. PSP should not capture
issuer specific authentication credentials outside the common
library. The encrypted credentials should be base64 encoded by the
common library and given back to PSP application for subsequent
transports through UPI. PSP should not log or store encrypted
credentials within any permanent storage.
d) Protecting against Phishing; In a typical phishing scam, phishers
send out emails, which appear to come from a legitimate company,
in an attempt to scam users into providing private information that
will be used for identity theft.
e) Message Security, , Trust, and Non-Repudiability: the privacy of
data in flight and at rest (a key requirement for PCI Compliance) is
of great value .For security purpose it should:-
 Support SSL & TLS as well as message-based encryption
and decryption using the XML-Encryption standards
 Sign and verify messages and headers to provide non-
repudiation
 Simplify key and certificate generation, distribution and
management with built-in PKI services.
1.5 The below are the list of APIs defined in the UPI system:-
All APIs are exposed as stateless service over HTTPS.API input data
should be sent to the following URL as XML document using Content-Type
“application/xml” or “text/xml”.
https://<host>/upi/<api>/<ver>
All APIs have same ack response as given below:
<upi:Ack xmlns:upi=”” api=”” reqMsgId=”” err=”” ts=””/>
S NO APIs NAME
1. ReqPay , RespPay
2. ReqAuthDetails , RespAuthDetails
3. List PSP
4. List Account Providers
5. List Keys
6. List Account
7. List Verified Address Entries
8. Manage Verified Address Entries
9. Validate Address
10. Set credentials
11. Check txn status
12. OTP-request
13. Balance enquiry
14. Heart Beat Messages
15. Request Pending Messages

12. 12
2. Possible API threats:
It is easy to become dismayed by the range of potential attacks against APIs.
Since every API is unique, each instance carries unique risk based on its
underlying implementation. This would seem to make API security impossible.
Fortunately though, most individual attacks against APIs fall into one of three
broad categories:
a) Parameter attacks exploit the data sent into an API, including URL,
query parameters, HTTP headers and/or post content.
b) Identity attacks exploit flaws in authentication, authorization and
session tracking. In particular, many of these result in bad practices
from the Web migrating into API development.
c) Man-in-the-middle attacks intercept legitimate transactions and
exploit unsigned and/or unencrypted data. They can reveal
confidential information (such as personal data), alter a transaction
in flight or even replay legitimate transactions.
This time around we’re going to start with some basic attacks. Although the
high-level goal of an API hack might be to get access to credit card numbers
or user passwords – a single attack is often just a step on the way. To get to
those credit card numbers, we have to learn about a system’s underpinnings
and its weaknesses. We have to pry around to find out how it works and what
its vulnerabilities are. A common approach is to provoke an API with
unexpected content in the hope that its inability to handle it correctly will teach
us about its inner workings. For example, getting the target API to return a
database error for an unexpected input is of great value. Some of basic API
attacks are listed below:-

13. 13
a) Fuzzing:
Fuzzing is a classic way of attacking (and testing!) a target system; the basic
idea is to repeatedly generate randomized input for a target API until we
stumble upon something that provokes an error message or system. With
today’s tools, it’s easy to set up a script that runs millions of requests in the
hope that some combination of input parameters will achieve our purpose.
b) Invalid Input Attacks:
Where fuzzing has little structure to it, invalid input attacks are slightly more
intelligent as they aim to provoke a target system by sending input that it
doesn’t expect. The better an API is described via metadata or
documentation; the easier it is to do this efficiently. Examples would be
sending strings when the API expects numbers, sending text when it expects
dates, or for any field, send nothing or send something too long. Given our
knowledge of HTTP this can be done at the protocol level also by sending
invalid HTTP Headers and values – targeting both the APIs HTTP layer and
its own logic.
c) XML Injection and XPath Injection:
Most sites have a way to store data, the most common of which is a
database. However some sites use XML to store data, and use a method of
looking at the data known as XPath.
XML and XPATH Injection
Applications which return different results based on user input (such as
logging a user in based on username/password) may not properly filter all
user input. Imagine that you have user data stored in an XML file, and that
XML file looks something like this:
<users>
<user ID =1>
<username>Admin</username>
<password>MyPassw0rd</password>
<role>admin</role>
</userid>
</users>
Looking at the code the site uses to log in, it dynamically builds an XPath
query in PHP, after a user has given username and password in a form (with
user and pass variables):
<?php
$login = simplexml_load_file("users.xml");
$result=$login->xpath("//User[username/test()='".$_POST['user']."AND
password/text()='".$_POST['pass']."'";
?>

14. 14
The main problem above is that data from the user is not sanitized; the POST
variable is being used to pull data directly from the login form, and placing it
into the XPATH query. At this point, an attacker could try putting in a special
string for username:
‘or 1=1 or’
Now the query always returns the first user (admin in our case) and the
attacker is logged in as an administrator!
Other attacks are possible using similar logic. Instead of logging in as an
administrator, an attacker could use other special strings to request data from
the document they should not have access to, potentially gathering all the
data in the XML file.
The most well-known XXE-related denial of service attack is the "billion
laughs" attack which exploits the ability to define nested entities defined within
an XML DTD to build an XML memory bomb. This bomb is a specially-crafted
document that an attacker writes with nested entities and in-line DTDs that will
cause the parser to generate an exponentially expanded payload, potentially
overloading the application process memory and causing a disruption in
service.
d) JSON INJECTION:
The method writes invalidated input into JSON. This call could allow an
attacker to inject arbitrary elements or attributes into the JSON entity. JSON
injection occurs when.
(i)Data enters a program from a less trusted source.
(ii)The data is written to a JSON stream.
Applications typically use JSON to store data or send messages. When used
to store data, JSON is often treated like cached data and may potentially
contain sensitive information. When used to send messages, JSON is often
used in conjunction with a RESTful service and can be used to transmit
sensitive information such as authentication credentials.
The semantics of JSON documents and messages can be altered if an
application constructs JSON from invalidated input. In a relatively benign
case, an attacker may be able to insert extraneous elements that cause an
application to throw an exception while parsing a JSON document or request.
In a more serious case, such as that involving JSON injection, an attacker
may be able to insert extraneous elements that allow for the predictable
manipulation of business critical values within a JSON document or request.
In some cases, JSON injection can lead to cross-site scripting or dynamic
code evaluation.
e) SQL INJECTION:
SQL Injection is one of the many web attack mechanisms used by hackers to
steal data from organizations. It is perhaps one of the most common

15. 15
application layer attack techniques used today. It is the type of attack that
takes advantage of improper coding of your web applications that allows
hacker to inject SQL commands into say a login form to allow them to gain
access to the data held within your database. In essence, SQL Injection
arises because the fields available for user input allow SQL statements to
pass through and query the database directly. SQL Injection is the hacking
technique which attempts to pass SQL commands (statements) through a
web application for execution by the backend database. If not sanitized
properly, web applications may result in SQL Injection attacks that allow
hackers to view information from the database and/or even wipe it out. Such
features as login pages, support and product request forms, feedback forms,
search pages, shopping carts and the general delivery of dynamic content,
shape modern websites and provide businesses with the means necessary to
communicate with prospects and customers. These website features are all
examples of web applications which may be either purchased off-the-shelf or
developed as bespoke programs. Firewalls and similar intrusion detection
mechanisms provide little defence against full-scale web attacks.
2.2 Proposed solution to overcome XML poisoning:
One of the solutions to avoid XML injection might be to encrypt the whole
XML document instead of encrypting an XML element or encrypting XML
element content.
 Encrypting Arbitrary Data and XML Documents
If the application scenario requires all of the information to be encrypted, the
whole document is encrypted as an octet sequence. This applies to arbitrary
data including XML documents.
<? xml version='1.0'?>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
MimeType='text/xml'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>

16. 16
 Super-Encryption: Encrypting EncryptedData
An XML document may contain zero or more EncryptedData elements.
EncryptedData cannot be the parent or child of another EncryptedData
element. However, the actual data encrypted can be anything, including
EncryptedData and EncryptedKey elements (i.e., super-encryption). During
super-encryption of an EncryptedData or EncryptedKey element, one must
encrypt the entire element. Encrypting only the content of these elements or
encrypting selected child elements is an invalid instance under the provided
schema.
For example, consider the following:
<pay: PaymentInfo xmlns: pay='http://example.org/paymentv2'>
<EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Element'>
<CipherData>
<CipherValue>originalEncryptedData</CipherValue>
</CipherData>
</EncryptedData>
</pay: PaymentInfo>
A valid super-encryption of "//xenc:EncryptedData [@Id='ED1']" would be:
<pay: PaymentInfo xmlns: pay='http://example.org/paymentv2'>
<EncryptedData Id='ED2' xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Element'>
<CipherData>
<CipherValue>newEncryptedData</CipherValue>
</CipherData>
</EncryptedData>
</pay: PaymentInfo>
Where the CipherValue content of 'newEncryptedData' is the base64
encoding of the encrypted octet sequence resulting from encrypting the
EncryptedData element with Id='ED1'.
2.3 CRYPTO KEY API:
Cryptographic key management, i.e. the secure creation, storage, backup, use and
destruction of keys has long been identified as a major challenge in applied
cryptography. Solutions aim to enforce security by dividing the system into trusted
parts (HSM, server) and untrusted parts (host computer, the rest of the network).
The trusted part makes cryptographic functions available via an API.
Hence we arrive at our first security API problem: how to design an interface for a
key management device so that we can create, delete, import and export keys from
the device, as well as permitting their use for encryption, decryption, signature and
verification, all so that if the device comes into contact with a malicious application
we can be sure the keys stay secure.

17. 17
b) The PKCS#11 standard:
RSA Public Key Cryptography Standards (PKCS) aim to standardise various
aspects of cryptography to promote interoperability and security. PKCS#11
describes the `Cryptoki' API for cryptographic hardware. In PKCS #11-based
API, applications initiate a session with the cryptographic token, by supplying
a PIN. Note that if malicious code is running on the host machine, then the
user PIN may easily be intercepted, e.g. by a key logger or by a tampered
device driver, allowing an attacker to create his own sessions with the device,
a point conceded in the security discussion in the standard. PKCS#11 is
intended to protect its sensitive cryptographic keys even when connected to a
compromised host.
c) The Wrap-Decrypt Attack:
Clulow first published attacks on PKCS#11 based APIs in 2003, where he
gave many examples of ways in which keys with the sensitive attribute set to
true could be read in clear outside the device. The most straightforward of
these is the `key separation' attack, where the attributes of a key are set in
such a way as to give a key conflicting role.
2.4 PIN Processing API:
We now consider our second case study, which addresses the problem of protecting
a user's PIN when withdrawing some money at an Automated Teller Machine (ATM).
International bank networks are structured in such a way that an access to an ATM
implies that the user's PIN is sent from the ATM to the issuing bank for the
verification. While travelling, the PIN is decrypted and re-encrypted by special
tamper-resistant HSMs which are placed on each network switch, as illustrated in
Fig. 8. The first PIN encryption is performed by the ATM keypad which is an HSM
itself, using a symmetric key k1 shared with the neighbour acquiring bank. While
travelling from node to node, the encrypted PIN is decrypted and re-encrypted by the
HSM located in the switch with another key shared with the destination node. This is
done using a so called translation API. The final verification and acceptance/refusal
of the PIN is done by the issuing bank. This check is performed via a verification API.
We can see that the PIN processing API of the HSM will have to (at least):
(i) Translate PINs
(ii) Verify PINs
(iii) Generate
(iv) Print
(v) Change PINs

18. 18
At first sight this setup seems highly secure. However, several API-level attacks
have been discovered on these HSMs in recent years. These attacks work by
assuming that the attacker is an insider who has gained access to the HSM at some
bank switch, a threat considered in-scope by the standard. The attacker performs
some unexpected sequence of API calls from which he is able to deduce the value of
a PIN. API-level attacks on PINs have recently attracted attention from the media.
This has increased the interest in developing formal methods for analysing PIN
recovery attacks. We will briefly survey the literature here.
2.3.1 Attacks on Verification API:
a) Decimalisation Table Attacks:
This family of attacks was discovered by both Bond and Zielinski, and Clulow,
On the basis of a proposal by IBM (the so-called ‘3624 scheme’), many PIN
schemes assign initial customer PIN values by encrypting a customer’s PAN
under a secret PIN derivation key (PDK), and then decimalising the result
using a decimalisation table (or ‘dectab’). A decimalisation table maps each
hexadecimal value to a decimal. The ‘standard’ decimalisation table looks like
this:
Hex.
value
0 1 2 3 4 5 6 7 8 9 A B C D E F
Dec.
value
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Decimalisation table attacks do not determine the PIN digit wise, but rather
determine first what digits are in the PIN, and then where these digits are.
Suppose an attacker has an encrypted PIN block which, when supplied along
with the standard decimalisation table and a known offset, correctly verifies
inside the HSM (that is, the HSM reports that the PIN is correct when the PIN
Verify ( ) function is called).Now suppose the attacker alters the
decimalisation table like this:

19. 19
Old value 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
New
value
1 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5
He then calls PIN Verify (.) again, with the modified dectab. If the verification
still passes, then he knows there are no 0s in the PIN. If however the
verification now fails, he knows there must be at least one 0 somewhere in the
PIN. The problem now is to determine how many there are, and where. This
can be accomplished by altering the offset. The attacker advances the offset
by one at each position, and then at every combination of positions, until the
PIN is once again reported as being correct. This reveals the location of the
0s in the PIN. The table below illustrates the process, for an example where
the customer’s PIN is 3060, and the offset is 0000. We assume the attacker
has already tried the modified dectab shown above, and discovered that there
is at least one 0 somewhere in the PIN.
Attacker set offset Result from HSM Knowledge of PIN as below:
0001 Incorrect PIN????
0010 Incorrect PIN????
0100 Incorrect PIN????
1000 Incorrect PIN????
0011 Incorrect PIN????
0101 Correct PIN ?0?0
The decimalisation table attack takes an average of 16.145 API calls to
determine four-digit PIN.
b) Check Value Attack:
Clulow has described an attack on the PIN verification API that takes
advantage of the ‘check value command’. Many APIs support such a
command, used to ensure that a key has been imported correctly. The
function of the command is to return a 64 bit block of 0s encrypted under a
given key. To make the attack, the attacker must also be able to supply a
block of 0s as validation data to a command for verifying PINs such as the
one described above. The first step is to obtain the check value of the PDK,
and decimalise the first four characters of the result using the standard
decimalisation table. Store this as IPIN. Now, supply a PAN of 000000000000
to the function PIN Verify (.), along with some encrypted PIN block (EPB) you
want to crack. Start with offset 0000. Generally, the command will at first fail.
Increase the offset by 1 until the command reports a successful verification.
Store the final offset as OFFSET. Now we know that the PIN in the block
verifies successfully when compared against IPIN + OFFSET (mod 10 each
digit), and so this must be the customer’s PIN. On average, for a four-digit
PIN, this attack would require one call to the check value command and 5000
calls to the PIN verify function.

20. 20
2.3.2 Attacks on the Translate API:
c) The codebook attack:
This attack uses the translation API to get rid of variant information from the
EPBs. This makes EPBs containing the same PIN equal, thus enabling
standard codebook attacks. Notice that if EPBs contain random padding, as
e.g. in the ISO-1 format, or if the PAN is xored to the PIN before it is
encrypted, as happens for ISO-0, equal PINs in general produce different
EPBs. The attack can be applied both to switches and to verification facilities.
The attacker first generates all the EPBs for every possible PIN of a fixed
length, in any ISO format. This can be done, e.g., by a network of attackers
trying all of the 10000 PINs at different ATMs and intercepting the
corresponding EPB at the hacked switch. A smarter method, described in ,
only requires 100 trials at the ATMs, but we do not describe it here for lack of
space. Once the 10000 EPBs have been obtained, the attackers translate, at
the switch where they have been intercepted, all these EPBs into ISO-0
format with a chosen fixed PAN, say PANA, and create a look-up table with all
the EPBs and the associated PINs. At the arrival of real EPBs, they translate
them into an ISO-1 format (Removing the PAN) and then reformat them into
an ISO-0 message together with the chosen PANA. The real PIN can now be
revealed by searching this new encryption in the look-up table.
d) Wrong-format attack:
This attack consists of translating a received encrypted message into an ISO-
0 format with different PANs, and to acquire information depending on the
return value of the translate API. More precisely, the attacker provides
different PANs , which are xor-ed to the decrypted value to recover the PIN.
When such an xor operation gives non-decimal values, the API returns an
error code. This gives information about the actual PIN digits. In fact, for an n
digits PIN, by repeating this operation 16(n − 2) times it is possible to recover
the n − 2 rightmost PIN digits up to their parity. For example, for a 4 digits PIN
we might discover that the third and fourth digits are 3 or 4 and 7 or 8,
respectively. Notice that the first two digits cannot be recovered because they
are not xor-ed with the PAN. There is a trick to recover also the first two digits
of the PIN: the attacker first translates a message in ISO-0 (where the PIN
starts from the 3rd position) with a PAN of all 0s, and then claims it is in a
VISA3 message format (that starts with the digits of the PIN ended by a
sequence of Fs), and asks to translate it into ISO-0 with a PAN of all 0s. The
result of this operation is that the PIN is shifted two positions to the right, thus
permitting the attacker to use the previous attack on the entire PIN. Attacks on
other APIs Attacks have also been found on the functions used for customer
PIN change and secure messaging.
2.3.3 Our Proposed Fix:
To understand the rationale behind our fix, first observe that the attacks
explained above are ‘differential attacks’ in the sense that they involve an
attacker learning about the value of the PIN by tweaking parameters to the

21. 21
API commands. The name comes from the similarity to differential attacks on
block ciphers, where certain bits in the inputs to the cipher are changed and
the result observed. One way to prevent these attacks would be to prevent
‘unauthorised’ queries to the API. In theoretical terms, we are trying to
achieve ‘robust declassification’. We know that the functions of the API must
declassify some data, specifically they must tell us whether the encrypted PIN
is the correct one or not. Robust declassification means an intruder cannot
influence what data is declassified. However, the existing APIs have no way
of distinguishing a legitimate query from an illegitimate one.
a) Addressing Verification Attacks:
We observe that the attacks explained in PIN Verification API are ‘differential
attacks’ in the sense that they involve an attacker learning about the value of
the PIN by tweaking parameters to the API commands. One way to prevent
these attacks would be to prevent ‘unauthorised’ queries to the API. In
general differential attacks can be countered by the use of MACs. The idea is
to add a MAC of the non-confidential parameters required for PIN processing
to the input to the relevant API command. The command checks the MAC
before performing the PIN operation. If the MAC check fails, the command
halts without processing the PIN. This way we achieve ‘robust
declassification’.
b) Addressing Translation Attacks:
i. Point-to-point MACs:
There are other ways to upgrade the network to protect against the
translation attacks. For example, we can demand that each switch
shares a MAC key with every switch to which it might send an EPB,
just as it currently shares a PIN encryption key with every such node. It
can then calculate a MAC for every outgoing block, and verify a MAC
for every incoming block. In practice, we cannot assume that all
switches in the network will be upgraded at once. As a consequence,
there will be a time when there are some switches which can calculate
MACs and some that cannot. As a consequence there will be edges in
the network (i.e., some communicating pairs of switches) that can deal
with MACs and share a key, along with some that cannot. PINs
travelling through non-upgraded switches will, of course, still be
vulnerable to translation attacks, even if they come from, or travel to,
upgraded nodes. In fact, once they reach non-upgraded switches, i.e.
switches whose translation function is not MAC enabled, all the old
attacks will be possible. This is, in a sense, natural as we cannot
guarantee the security of PINs passing through insecure sub networks.
Note that even if a PIN does not travel through non-upgraded switches,
it might reach a MAC-enabled switch that is in contact with non-
upgraded ones. This ‘borderline’ switch will have to offer both MAC-
enabled and standard translate functions in order to communicate with
the old protocol. This leaves the door open for attacks as an intruder
might just disregard the MAC and call the old translate function in order

22. 22
to mount all the old translate attacks. A switch, in fact, only becomes
secure once the old translate command can be disabled. A way to
mitigate this problem is to add new special (temporary) borderline
switch with the only aim of interfacing upgraded and non-upgraded
subnets. These nodes would only be reached by EPBs going to/coming
from an insecure, non-upgraded, sub network. In this way EPBs
travelling inside an upgraded network are not exposed to attacks on
borderline nodes.
ii. Single format:
Since translation attacks are based on reformatting the EPB, another
possibility to prevent them would be to enforce the use of one single
block format. In this way a translate API would only consist of
decrypting and re-encrypting the PIN block. Even in this case,
upgrading the whole network would require time, leading to the same
situation discussed above. This solution does not require any new
modified HSMs and protocols, since it only aims at reducing the
existing functionalities so to operate on a single format thus it is, in
principle, very appealing. However there are some difficulties that have
to be carefully considered:
 the ‘political’ decision on which format should be elected as ‘the one’ is
far from being easy to take since many different standards exist,
proposed by different entities.
 The choice of the format might require upgrading some old HSMs or
PEDs so to support it, especially for randomized formats like ISO1 or
ISO3 which require good random number generators not present in old
hardware.
3. Mitigation Guidance:
Although APIs are susceptible to a broad range of attacks, application of just
five simple mitigation strategies will allow an organization to securely publish
APIs.
I. Validate parameters:-
The single most effective defence against injection attacks is to validate all
incoming data against a white list of expected values. The most practical
approach to this is to apply schema validation to all incoming data against a
highly-restrictive data model. Schemas should be composed to be as tight as
possible, using typing, ranges and sets whenever possible.
II. Apply threat detection:-
Threat detection is generally an exercise in blacklisting risky content, such as
SQL statements or SCRIPT tags. The challenge is to apply this effectively. It
is important to be able to tune your security scanning appropriately for the API
at hand. Virus detection should also be considered on encoded content.

23. 23
Posted binary content can potentially mask executable content. APIs involved
in file transfer should definitely decode base64 attachments and submit these
to server-grade virus scanning.
III. Turn on SSL everywhere:-
Make SSL/TLS the rule for all APIs. In the 21st century, SSL is not a luxury; it
is a basic requirement. Adding SSL/TLS—and applying this correctly—is an
effective defence against the risk of man-in-the-middle attacks. SSL/TLS
provides confidentially and integrity on all data exchanged between a client
and a server, including important access tokens such as those used in OAuth.
It optionally provides client-side authentication using certificates, which is
important in many high-assurance environments. However, despite it being
much simpler than message-level security methods such as WS-Security,
SSL is still subject to misuse.
IV. Role-based access control (RBAC):-
CSOs should ensure that an API infrastructure has RBAC, which governs
actions taken by users on APIs, API products, apps, developers, and reports
in their organizations. There should be at least two roles: the organization
administrator and the user.
V. Logs and audit trails:-
API security must also provide the ability to log all actions, and the ability to
audit such logs.
API infrastructures like Apigee Edge enable enterprises to gain a deep
understanding of customer behaviour and interactions using real-time data from
APIs. Much of this data is operational, which helps to guide business decisions, but it
can also be relevant to monitoring the security of APIs. For example, run-time
detection reports, such as temporal analysis of volume and traffic properties by the
dimensions (/apis, /api products, /apps, /devs, and /envs), should be correlated
against threat detection capabilities, including:
• XML poisoning
• JSON injection
• SQL injection
• Quota/spike arrest
• IP address-based access restrictions
VI. Rate-limiting:
To maintain performance and availability across a diverse base of client apps,
it's critical to maintain app traffic within the limits of the capacity of your APIs
and backend services. It's also important to ensure that apps don't consume
more resources than permitted. There are three mechanisms that enable to
optimize traffic management to minimize latency for apps while maintaining
the health of backend services. Each policy type addresses a distinct aspect
of traffic management. In some cases, you might use all three policy types in
a single API proxy.
 Spike Arrest:-
The Spike Arrest policy protects against traffic spikes. It throttles the
number of requests processed by an API proxy and sent to a backend,
protecting against performance lags and downtime. This policy

24. 24
smoothes traffic spikes by dividing a limit that you define into smaller
intervals. For example, if you define a limit of 100 messages per
second, the Spike Arrest policy enforces a limit of about 1 request
every 10 milliseconds (1000 / 100); and 30 messages per minute is
smoothed into about 1 request every 2 seconds (60 / 30). The Spike
Arrest limit should be close to capacity calculated for either your
backend service or the API proxy itself. The limit should also be
configured for shorter time intervals, such as seconds or minutes. This
policy should be used to prevent sudden traffic bursts caused by
malicious attackers attempting to disrupt a service using a denial-of-
service (DOS) attack or by buggy client applications.
 Quota:-
This policy enforces consumption limits on client apps by maintaining a
distributed 'counter' that tallies incoming requests. The counter can
tally API calls for any identifiable entity, including apps, developers, API
keys, access tokens, and so on. Usually, API keys are used to identify
client apps. This policy is computationally expensive so, for high-traffic
APIs, it should be configured for longer time intervals, such as a day or
month. This policy should be used to enforce business contracts or
SLAs with developers and partners, rather than for operational traffic
management.

25. 25
Concurrent Rate Limiting:
This policy enables traffic management between API Services and your
backend services. Some backend services, such as legacy
applications, may have strict limits on the number of simultaneous
connections they can support. This policy enforces a limit on the
number of requests that can be sent at any given time from API
services to your backend service. This number is counted across all of
the distributed instances of API Services that may be calling your
backend service. Policy limits and time duration should be configured
to match the capacity available for your backend service.
WHICH TO CHOOSE REST API OR SOAP FOR SECURITY?
For machine-to-machine communications such as business processing with BPEL,
transaction security and integrity, I suggest using SOAP. SOAP binding to HTTP is
possible and XML parsing is not noticeably slower than JSON on the browser. For
building public facing API, REST is not the undisputed champion. Consider the
actual application requirements and evaluate the benefits. People would say that
REST protocol agnostic and work on anything that has URI is beside the point.
According to its creator, REST was conceived for the evolution of the web. Most so-
called RESTful web services available on the internet are more truly REST-like as
they do not follow the principle of the architectural style. One good thing about
working with REST is that application does not need a service contract as in SOAP
(WSDL). WADL was never standardized and I do not believe that developers would
implement it.

26. 26
Summary
In this research paper a case study about API Security has been carried out
covering previous API attacks on PIN processing API from previous research
papers.
This paper reports the possible API attacks on UPI , attacks on PIN processing API
and various mitigation techniques to avoid API attacks. APIs are subject to increased
risk from man-in-the-middle attacks when the transmission is not encrypted or signed
or when there is a problem setting up a secure session. If an API does not properly
use SSL/TLS, all requests and responses between a client and the API server can
potentially be compromised. Even those APIs that use SSL/TLS are at risk if this is
improperly configured on the server side, if the server is subject to downgrade
attacks on ciphers or if the client is not properly validating the secure session. All API
s used in UPI are under attacks of old threats like Denial of Service (DoS) attacks,
malformed messages or excessive XML/JSON depth and breadth, , JavaScript or
XPath/XQuery injection attacks.PIN Processing API s are under Differential Attacks
whereby an attacker gains information about the plaintext values of encrypted
customer PINs by making changes to the non-confidential inputs to a command.PIN
processing API attacks involve various attacks on PIN verification API and attacks
on PIN translation API which can be resolved and addressed in many ways
described in this report. APIs are fundamentally different from websites and have an
entirely unique risk profile that must be addressed.
Overall an organisation can control over all aspects of API security, by strong Threat
detection, including SQL injection, XSS, CSRF, message size, etc .Confidentiality
and integrity, including limitations on cipher suites, advanced ciphers based on
technology such as ECC digital certificates, message-based security etc. ,Message
validation, including XML and JSON schema validation ,Authentication support,
including basic credentials, API keys, OAuth, SAML, OpenID Connect, Kerberos,
x509 digital certificates, etc can help to avoid API attacks. Rate limiting and traffic
shaping of transactions against any model, Rich policy-driven audit which includes
the ability to trap events based on custom criteria and to integrate with existing
security and management infrastructure can avoid the pitfalls of exposing enterprise
systems.

27. 27
FUTURE SCOPE
Attacks on PIN processing APIs have been known for years, many logical ideas and
research reports have been proposed to mitigate such attacks. Even in the presence
of strong security there has been news and attempts of API attacks in payment
industry. Unified payment interface proposed with aim of decreasing flow of cash
(increase cashless transaction) via a single payment API and a set of supporting
APIs is under various security threats. Execution of random sequences of command
by user may reveal various secret keys. Since UPI uses existing systems to
orchestrate these transactions and ensure settlement across accounts so security
threats propagates in this common layer also. Our proposed idea of mitigating XML
poisoning might remove some of the attacks on API while translation of messages
through various switches. PIN processing API s could be extended with MACs to
counteract differential attacks. However inclusion of MACs may need to change
existing infrastructure.

28. 28
REFERENCE
1. Unified payment interface (UPI):
http://www.mpf.org.in/pdf/NPCI%20Unified%20Payment%20Interface.pdf
2. Request for Proposal for Development and Implementation of Unified
Payment Interface System:-
http://www.npci.org.in/documents/UnifiedPaymentInterfaceSystemDraft_FIN
AL.pdf
3. R. Anderson. What we can learn from API security (transcript of discussion).
Insecurity Protocols, pages 288{300. Springer, 2003.
4. M. Bond. Understanding Security APIs. PhD thesis, University of Cambridge,
England, 2004. http://www.cl.cam.ac.uk/$sim$mkb23/research.html.
5. O. Berkman and O. M. Ostrovsky. The unbearable lightness of PIN cracking.
In Springer LNCS vol.4886/2008, editor, 11th International Conference,
Financial Cryptography and Data Security (FC 2007),Scarborough, Trinidad
and Tobago, pages 224–238, February 12-16 2007.
6. Spike arrest policy:-http://apigee.com/docs/api-services/reference/spike-
arrest-policy
7. Blunting Differential Attacks on PIN Processing APIs?vRiccardo Focardi1,
Flaminia L. Luccio1, and Graham Steel2
8. An Introduction to Security API Analysis ? Riccardo Focardi1, Flaminia L.
Luccio1 and Graham Steel2
9. Five pillars of API M anagement:-https://www.techwire.net/wp-
content/uploads/5-pillars-of-api-management.pdf
10.XML Encryption Syntax and Processing:-http://www.w3.org/TR/2002/REC-
xmlenc-core-20021210/Overview.html

29. 29

30. 30