this paper, the author surveys the failure scenarios of ATMs, to reach to a conclusion
about why cryptosystems fail. He chose to examine the banking sector for this
purpose because in other sectors where cryptography was applied more, like
government or military organizations, we could not reach to conclusions due to
the secrecy about their mistakes. The main finding of this paper is that the
threat model was mistaken, as it was based on cryptanalysis and
other technical attacks while the results showed that most systems failed due
to implementation and management errors. Another fact was the false impression
that acquiring a crypto product was enough to be considered as a solution which
led to many banks to rely on it to a point that they did not have a security
team of managers, consultants, programmers etc. and those who did, did not care
about training them. Finally, the author provided many examples which showed
that the crypto product manufacturers did not provide enough detailed
specifications of proper implementation of the product and made sloppy quality
control which resulted to compatibility issues and need of specialized security
The author found that some banks were using proprietary encryption algorithms
which just “scrambled” data blocks by adding a constant to them. The problem
with the use of such “home-grown” algorithms is that they are known sooner or
later and especially an algorithm of that complexity would be trivial for a
cryptanalyst to break.
Some banks used RSA as the encryption algorithm but as the author states, they
implemented it with key sizes between 100 to 400 bits. In 1974, when RSA was
published, the recommended key size was 512 bits, and any other key size lower
than this would make the algorithm breakable, until the late-1990s when it
increased to 1024 bits for enterprises. That shows that even though the banks
used a well-respected algorithm, a poor implementation of it could lead to the
whole cryptosystem to fail.
In this paper, we can also find examples of poor key management practices which
could lead to cryptosystem failures. One example is that banks blindly trusted
several “facilities management” firms to its ATM systems, giving them their PIN
keys. Furthermore, there have been cases where banks shared their PIN keys with
One example where the human factor was critical in the failure of the
cryptosystem was an incident which happened in a bank which followed ideal
security practices with all the partied involved cooperating smoothly to
control unissued cards and PINs. That was until one favored person of the
deputy managing director decided that costs needed to be cut resulting to
termination of these practices and later increase of the losses. The managers
of the security branches did not complain about that decision as it could risk
their hard-built careers.
One fact relating to cryptography that is no longer true is that in the early
1990s, key management was insufferable. The author states that the sharing of
the cryptographic keys between the manager and the accountant of a bank was a
well understood practice these days due to their packaging and management was
not user friendly. Nowadays, with the evolution of the internet and the cloud,
we have many standards such as KMIP and PKCS #11 which help making the key
management process safer and easier. In the banking business, in particular,
EMV protocol uses a secure key management practice where a Hardware Security
Module is responsible for creating, deleting, sharing and distributing keys, with
an easy to use software.
b) Observing the main findings of the article to today’s technologies and
practices we can safely say that we learned our lesson. Addressing the threat
model, we moved to a more “holistic” approach, creating standards which not
only cover the methods of preventing cryptanalysis and other technical attacks
but also how to implement the solutions properly and manage the human factor.
Nowadays, every organization who wants to protect its assets has a security
operation centre which consists of a team of security architects, programmers,
managers and other certified and trained professionals who are compliant to a
great extent(we are still working on it) to the latest standards.
These standards are not only for people who work in the SOC but they also refer
to every single employee working in the organization, from the CEO to the janitor
of the building. We also adapt our security practices not only to things that
we know that could happen but also to things that are likely to happen in order
to minimize every possible threat. Another today’s practice is that security
“solutions” provided by companies are more detailed in their specifications and
they are just a tool for the specialized personnel to provide maximum security
in an organization.
a) These 3 digits on the back of the card are called
CVV(Card Verification Value) and they are an extra verification measure in
modern payment systems. To compute this value you need some static data like
the Primary Account Number(PAN), the Expiration Date of the card and a 3-digit
service code, as long as two single length 3DES keys. With the use of the 3DES
algorithm, we encrypt the static data with the pair of keys and then we select
randomly three of them as the CVV which is then written on the magnetic stripe.
Usually, the service code is non-zero but in a variant of the CVV, which is
called CVV2, the service code is “000”. Another variation of the algorithm is
the format of the expiration date. Most of the time, the expiration date is
used in the algorithm with the format MM/YY but for example in CVV2 it is with
the format YY/MM. The parameters’ formats on the computation of CVV depend on
the company who created it.
b) CVV enhances security in many ways by being another
verification measure for our credit card. At first, it provides an extra layer
of fraud protection, especially in e-commerce, as an account number is easy to
steal and use in fraudulent transactions. CVV provides a validity mechanism to
verify the connection between the card and the person who owns it. CVV also
helped to minimize the fraud-related chargebacks which is the demand by a
credit card provider for a retailer to make good the loss on a fraudulent or
disputed transaction. Although its security benefits, it cannot protect against
captured credit cards who may have been acquired due to fake ATMs.
Cryptocurrency is a name that is a very
controversial one as it is often judged by cryptographers. They make
transactions using an online P2P system which without cryptographic tools and
public key cryptography would be penetratable. Such tools are digital
signatures, hashing and Merkle trees.
At first, digital signatures are used to
verify that a person actually holds the money needed for the transaction.
Hence, no transaction is made without the digital signature, which is unique
and unforgeable by another entity. In terms of data integrity, cryptocurrencies
use hashing to the blockchain data which includes all people’s balances. We
also use it to encode account addresses and transactions between accounts.
Hashing is also essential for “block mining” which is the whole point of
cryptocurrencies as it is its main feature. Finally, we use a technique called
Merkle trees which allow cryptocurrency applications to run smoothly on binded
hardware devices like cell phones.
Except for these tools, we also use
public key cryptography in the transaction process. Let’s say Bob wants to make
a transaction of X bitcoins(for example) to Alice. He will encrypt the
transaction with his private key and send it to Alice’s public address. Alice
then will verify that Bob is the one who sent her the bitcoins by decrypting
the transaction value with Bob’s public key. So these points show us the
reltionship between cryptocurrencies and cryptography.