29

I was reading the Wikipedia article on Card security codes (CSC, CVD, CVV, CVC, V-code, SPC, CID, CV2, CVN2, CAcronym2, etc) and a certain assertion caught my eye (emphasis mine):

The CSC for each card (form 1 and 2) is generated by the card issuer when the card is issued. It is calculated by encrypting the bank card number and expiration date (two fields printed on the card) with encryption keys known only to the card issuer, and decimalising the result.

The description sounds a lot like a HMAC using only already public information as the main input - but in any event, given the sheer number of compromised credit-card numbers (with Card security codes) in existence surely it must be possible to derive the issuer's encryption key by now? (Does it matter if it's symmetric encryption or asymmetric?)

If true, then I'm surprised the system is designed like that instead of generating a unique secret key or number, per card, from which the CSC is derived from instead of an institution-wide key - which my question presupposes can be derived from the large number of output values given knowledge of all cleartext input) - because my current understanding of cryptography tells me that the secret key can be derived given enough known cleartext input (compromised card details) and ciphertext output (compromised CSC codes).

Improve this question
7
  • 15
    which my question presupposes can be derived from the large number of output values given knowledge of all cleartext input Unless the algorithm is really, really broken, knowing plaintext/ciphertext pairs does not allow the discovery of the key itself.
    – forest
    Apr 12, 2018 at 10:11
  • 1
    Propably you think about brute-forcing the key, but if the issuers key is strong as one could expect, then brute-forcing is out of scope. To make it a bit more comprehensible, a 256 bit key allows for 1E77 combinations and even if one can calculate 100Giga values per second, one still expects about 2E58 years to find the key.
    – martinstoeckli
    Apr 12, 2018 at 10:59
  • 25
    The whole thing "credit card" is insecure. The security code is merely a means to thwart the most stupid attempts. PCIDSS forbids storage of the security code after a transaction. Hey wait a minute... does that mean...? Yes, exactly. That's what it means (and if you think about it, it's pretty obvious). Lots of people get to know your security code, it is not by any means secret. The whole system relies on everybody following the rules.
    – Damon
    Apr 12, 2018 at 14:20
  • 1
    I don't see what the advantage would be of randomly generating a per-account secret key, and then using this key to generate a 3-digit security code. Why not just randomly generate a 3-digit security code?
    – Jay
    Apr 12, 2018 at 19:55
  • 1
    @Damon To be fair, unlike rules most of us set, the rules everyone has to follow are generally punishable by jail time, fines, or whatever other sentence the judge decides on.
    – anon
    Apr 13, 2018 at 5:02

1 Answer 1

Reset to default
42

Deriving the issuer's encryption key using a collection of credit-card numbers with their respective security codes would be an example of a known-plaintext attack (KPA).

To be considered secure, a cipher has to be resistant to known-plaintext attacks, i.e. cracking the encryption even with a large number of plaintext-ciphertext pairs should not be significantly quicker than brute-forcing it. This is a basic requirement for ciphers to even be considered for practical application.

In cipher design and evaluation, it's assumed that the attacker has as many known plaintext-ciphertext pairs as he wants, and can produce new ones by feeding chosen plaintexts to be encrypted (CPA). In IT security, known plaintexts are a given - for instance, this page is being served to you encrypted through HTTPS, but any attacker can get most of its plaintext by visiting the website. If this allowed them to derive the private key, HTTPS would've been rendered pointless.

Modern ciphers such as AES and even most deprecated ones are KPA resistant if used correctly. The only use plaintext-ciphertext pairs would have is to check if your key matches.

Outdated, pre-computer era ciphers weren't secure and could indeed be broken with KPA; that's what happened to the Enigma. It's also possible to break modern ciphers with KPA/CPA if they're used incorrectly, e.g. with repeated IVs and nonces. Bad usage can reduce any cipher's security to a simple XOR, so a secure scheme takes more than just a good cipher. Whether any banks have screwed it up quite that badly... I hope not.

Improve this answer
7
  • 2
    As the security codes I've seen are all 3 decimal digits, it would be a lot easier to brute force attack the security code than the key used to generate the security codes.
    – Jay
    Apr 12, 2018 at 19:59
  • 2
    @Jay that's mitigated by a very limited number of tries. Attempting to brute force a CVV would probably set off alarm bells in the system after the 3rd attempt.
    – Dom
    Apr 12, 2018 at 21:51
  • So the "secure key" of credit card is a myth, it does not work in a world where distributed computing using millions PC harvested by botnets are used to perform the tries: these botnets are constantly waiting for new scripts to run for the only benefit of blackhats! That's why most virus now are not stealing anything on the PC, and try to not be detected and not alter their performance! They are even enforcing the system to maintain it stable for use by blackhats!
    – verdy_p
    Apr 13, 2018 at 0:07
  • 2
    Note what the bank do when 3 false guesses have been used by remote tries: they just block the account for a very limited time (24 hourts at most), but unlock it rapidly (without alerting their customers to issuer them a new CVV), allowing 3 new guesses. Those that steal creadit card numbers have plenty of time (up to 2 years) to retry. On a 1 year period this allows them to retry about 1000 times on average and they will finally succeed to use stolen credit card numbers on about 25% of them. This is dramatic ! The CVV system is fully broken by design: KPA/CPA issuer attacks don't matter!
    – verdy_p
    Apr 13, 2018 at 0:14
  • The real parade for now is to use secondary authentication (using SMS: to succeed, the attack must know not just the credit card, but also the phone number, and must be able to collect the SMS sent to them, or deroute the voice calls to authorize a transaction, such as "Verified by Visa phone calls by your bank")
    – verdy_p
    Apr 13, 2018 at 0:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .