3

Since the era of contactless payments, it's easy to make payment via card without entering PIN code, but how is the card actually secured?

There is limit of 20€ of course, but even committing 20€ payment without person knowing once a day could make a nice 600€/month revenue for hacker.

Is there any protection against a modified card reader in shop, which could possibly read the data, store them and later use them without person knowing to commit payments again?

Edit: I am not asking how to prevent copying data, but rather how is commiting transactions, if machine could once read data and store them, without user knowing prevented

Improve this question
5
  • 4
    Possible duplicate of How do NFC tags prevent copying?
    – paj28
    Nov 28, 2016 at 16:11
  • Are you asking about contactless payments, or about credit cards in general?
    – Anders
    Nov 28, 2016 at 16:22
  • I am asking more about how is payment schema secured against such things as machine storing card data and committing transaction without card already present
    – user131827
    Nov 28, 2016 at 16:54
  • You usually have a set number of contactless transactions (three in the countries I used the technology in) before the transaction requires a PIN.
    – WoJ
    Nov 28, 2016 at 18:07
  • What about public transport smart-cards? They also carry money. There are no PIN codes there so far, what do they rely on?
    – user131827
    Nov 28, 2016 at 18:14

2 Answers 2

Reset to default
3

There are different types of authentications for cards. Years ago the old mag stripe cards (still in use in the USA) had only "Static Data Authentication" (SDA), which was a fixed, unchanging number embedded in the mag stripe, similar to the CVV2 printed on the back of the card. The data breaches that have rampaged across America in the last few years have been due to exactly the problem you identified; that is the malware in the payment terminal makes a copy of the data and sends it to the hacker. SDA cannot defend against the type of copying you describe.

A more modern type of authentication is called Dynamic Data Authentication (DDA). It takes advantage of the fact that the card data is delivered by a computer chip, and is not just a stream of fixed data. The computer chip runs an algorithm to generate the DDA number; this algorithm uses a rolling code. This DDA then takes the place of the old SDA. During authorization, the bank notes the rolling code value used to generate that DDA and invalidates any older DDAs in order to prevent a replay attack using any earlier DDA codes.

That means that if a terminal makes a copy of a DDA card's data verbatim, including the DDA, the bank will still reject it on future transactions because that DDA has already been used.

Finally, EMV supports the Combined DDA (CDA) method, which is a cryptographic operation based on various pieces of data available in the transaction, including the transaction number, amount, terminal ID, an internal counter, a terminal-generated random number, and a secret key stored there by the issuing bank. The algorithm produces a cryptogram that can only be recalculated by someone who knows all of those components; since they include the secret key, only the bank or the card's chip could reproduce them.

(There was an attack possible when the terminal's generated random numbers weren't truly random; changes to the EMV spec in revision 4.3 addressed that.)

Note that some older EMV chips may still use SDA because it's still supported by the protocols. But if the authorization data is skimmed or copied, the bank who issued the chip with SDA has to pay for the fraud because they used known insecure technology.

Improve this answer
6
  • So if I understand right, DDA is read-only for terminal and bank relies on fact that nobody knows generation algorithm to predict next DDA and CDA brings other factors in, like private key known only by bank. Problem is, I am trying to develop own schema for educational purposes, which would be open-source, but if it's open-source, then everyone could see private keys and algorithms, is it possible to do such thing as open-source at all?
    – user131827
    Nov 28, 2016 at 18:22
  • Consider it like public key technology. You can implement the algorithm as open source, but only the issuer knows the private key. At some point, though, there has to be secret state in the card that can't be extracted.
    – John Deters
    Nov 28, 2016 at 19:31
  • The bank does usually not mark the DDA as used, but uses a counter that is advanced to the number of the DDA in sequence that is used. This means all DDA's equal or prior to that counter is invalid, so even if a fraudster captures a DDA prior to a transaction, its unuseable as soon as transaction is performed (since the bank will see there was a unused DDA and advance the counter 2 times).
    – sebastian nielsen
    Nov 28, 2016 at 23:37
  • In addition, to prevent a malicious terminal requesting multiple transactions during one "tap", the chip have counters which require an online chip-and-pin transaction after a few contactless ones.
    – billc.cn
    Nov 29, 2016 at 11:16
  • But once there is malicious terminal, it could ask user for PIN code too and remember it
    – user131827
    Nov 29, 2016 at 17:12
0

Disclaimer: im not into this field, what i know is very limited, please don't count on it and don't downvote me if im not exactly right. Im trying to help - corrections/edits/falsifications very welcome! :)

As is with every technology which uses Universal Integrated Circuit Card as protection, one can only verify a transaction with it. its not possible (or lets say without very hard efford, e.g. using an very sophisticated radar-microscope to reverse engineer the card) to steal the private key stored on it.

Since transaction rely on a timewindow it is not possible to 'store' the verification and use it later - as far as i know!

What is possible indeed is to show a wrong amount (a lower one) to the user on the manipulated device. Also there are some methods which can increase the range a card can be read. checkout e.g.: http://blog.atlasrfidstore.com/improve-rfid-read-range

Improve this answer
2
  • Yes, but theoretically once the private key is known, it wouldn't be such problem to rewrite some unique identifiers as verification
    – user131827
    Nov 28, 2016 at 16:56
  • the private key is never known. its just used to sign a transaction. it can't be read out (well, it can somehow - as i pointed out with the radar-microskope) - but not by 'using' the UICC. Think about the UICC/RFID/SIM (whatever) as a CPU with only 1 function: ´sign(transaction)´ The privkey never leaves the card.
    – Gewure
    Nov 29, 2016 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy