2

I'm building a mobile app that accepts payments. The user enters their CC details, and the payment info is submitted to a retailer's POS system over HTTPS. The POS processes the payment directly and needs the actual credit card info to work, therefore we cannot use services like Stripe that will store the card, and give us back a token to process payments.

Because of the nature of the app, users will be making regular payments and so I want to store their CC info for convenience. However this is not recurring billing, the user will be initiating the transaction at will. Therefore I don't need to keep CC centrally on a server and I'm considering storing individual cards on each user's device using this method:

  • Collect CC number & expiration date
  • Encrypt it using AES256, using the CVC as key (CVC not stored)
  • Then store the encrypted data in iOS keychain (or equivalent for Android)
  • To make a payment, (a) data is taken out of keychain, and
  • (b) the user must enter the CVC to decrypt the CC info

The idea being, that if the user knows the CVC they likely possess the card anyway, hence they don't need to try hacking the device.

For encryption, I'm considering using the RNCryptor lib. One of its primary features is the automatic conversion of common passwords to cryptographically 'random' byte sequences of two 256-bit keys, for encryption and authentication. The key stretching is implemented through 10k rounds of PBKDF2. The implementation details are in the link, but in short:

  • AES-256 encryption
  • CBC mode
  • Password stretching with PBKDF2
  • Password salting
  • Random IV
  • Encrypt-then-hash HMAC


Questions:

I don't understand the math well-enough to judge if seeding RNCryptor's key-stretching implementation with just the 3 CVC digits, would produce a statistically random enough key. I haven't been able to find any docs on what password specifications are required for RNCryptor to stay secure. Any thoughts on that would be appreciated. Using this lib is as simple as this:

// Encryption
NSData *data = ...
NSString *password = @"Secret password";
NSData *ciphertext = [RNCryptor encryptData:data password:password];

// Decryption
NSError *error = nil;
NSData *plaintext = [RNCryptor decryptData:ciphertext password:password error:&error];
if (error != nil) {
    NSLog(@"ERROR:%@", error);
    return
}
// ...

When storying the AES256 encrypted CC info on iOS keychain (or droid equivalent), does it matter if there is no device lock passcode enabled? My thinking is, the info is already AES256 encrypted, it could be stored on the device without keychain's encryption anyway?

What sections of PCI compliance are relevant in this case, given that there is no central server storing lots of CC numbers? I tried reading the PCI specs but the docs are a maze to navigate :(

DTs
  • 1,196
  • 1
  • 11
  • 28
  • At a minimum you will need to verify that the iDevice has a passcode enabled. – zaph Apr 13 '17 at 21:09
  • 1
    Aes256 needs a 256 bit key but a cvc code only contains 10 bit of information. If using the cvc code as key, brute force would not only break this instantly, but would also leak the cvc code in the process. – Ebbe M. Pedersen Apr 13 '17 at 23:03
  • Isn't this what ApplePay is for, on the iOS side? – Bobson Apr 13 '17 at 23:26
  • @Bobson Not everyone has ApplePay setup, an ApplePay supported credit card or has a device capable of ApplePay, think older iPhones and iPads. – zaph Apr 14 '17 at 16:46
  • @EbbeM.Pedersen very good point! I updated the question with more details on how I was thinking to counter this. However I don't understand the math well-enough to judge if seeding RNCryptor's key-stretching implementation with just cvc, would produce a statistically random enough key. Thought on that? – DTs Apr 15 '17 at 00:09

2 Answers2

3

  1. As Ebbe points out using just a CVC as the key, even derived from the CVC with PBKDF2 is not secure, there are only 1000 possible keys. Something else must be included in the key.

  2. The date acts as a partial crib since it has a known format and limited values. Also be careful not to include any other cribs such as field separators or field indicators.

  3. The Credit Card Account Number Verification Check Digit is also a crib.

  4. In order for the Keychain to be secure the user must have entered a device lock passcode.

  5. Jailbroken and rooted devices must be avoided and that is difficult to determine.

  6. As long as only the CC# and expiration date are saved, not any track 2 data and it is encrypted to PCI standards you should be OK.

  7. See the PCI Point to Point Encryption Standard, it is free on the PCI site. See Table 2, Application Developer.

  8. Finally get a PCI auditor to review your scheme, this is just "best information" with the information provided and without a through evaluation.

Update based on the OP's comment:

There are 1000 CVCs to try. RNCryptor will take ~200ms per CVC try, that means all 1000 can be tried in ~4 minutes—ouch. RNCryptor has authentication so it will be immediacy known when the correct CVC is tried. This not not secure in the least and the authentication is working against you.

Without authentication then cribs need to be relied on. The first crib is the check digit, that will rule out ~900 CVCs leaving 100.

But is is is really worse depending the format that is encrypted. Decryption with an incorrect key will return essentially random bytes. If the CC# and date are a string the odds of the result being a digit string are virtually zip so again a correct decryption will be immediately known. The best bet is to convert the CC# to a large integer and the date to a numeric day+year and encrypt this. But even then there is the check digit crib and a valid date to use to validate the decryption. It is actually more secure to not include the expiration date in the encryption.

In the end using a CVC as the key will not be secure, a much longer key is needed.

The Keychain does not protect its contents from the device owner and the device owner in reality is whoever has access, the passcode is what determined access and thus the device owner.

zaph
  • 111,848
  • 21
  • 189
  • 228
  • Thanks @zaph, your comments helped me update my question with some missing details. I'm using RNCryptor for creating a 'good key' out of the 3 CVC digits. My understanding is that this lib does 10k rounds of PBKDF2 stretching, to produce two 256 bit keys of statistically random bytes. However I don't understand the math well-enough to judge if seeding RNCryptor with just 3 digits, would be secure enough. Any thoughts on that? About the iOS keychain, does it matter if there is no device lock passcode (since the sensitive info is already AES256 encrypted)? Great tips on cribs to avoid! Thanks! – DTs Apr 15 '17 at 00:34
  • Ok, so trying to break this in practice would work like this? (a) user gets access to device without (or with known) passcode, (b) jailbreaks the device, (c) programmatically extracts the encrypted data out of the keychain, (d) tries to brute-force the password on own machine? In which case, key stretching is irrelevant? How about if I mutate the CVC with a static long string (invisibly from the user), and then use the same mutation during decryption? Somebody would then have to reverse engineer my code to figure out that there is a key-enrichment, and the mechanics of it. For example: – DTs Apr 17 '17 at 03:48
  • the CVC password becomes xxxxxxCxxxxxxxVxxxxxxCxxxxx, where 'x' are random padding characters. Two ideas: (a) these characters are hard-coded in the app, (b) if that’s not safe, the padding can be generated on the server uniquely for each user, kept in a DB, and sent to the device over HTTPS during encryption / decryption (an overkill?). The goal being, rendering password brute-forcing a non-option. Then only need to worry about cribs? How about if I include random chars (device generated) in the encrypted message? Would that “de-power” the cribs you've identified? – DTs Apr 17 '17 at 04:04
  • If not, I guess I could also store the dates and check digit on the server (is it the first, or last digit)? If brute force is attempted manually (though the app's UI), then the padding I proposed above would be useless. In that case, I could delete the encrypted CC info from the keychain after 5 unsuccessful attempts. Thoughts on all that? – DTs Apr 17 '17 at 05:07
  • any thoughts on these latest comments? Thanks! – DTs Apr 29 '17 at 22:26
  • The CC# must be encrypted with a secure method such as AES and the encryption key must be of sufficient size to be secure, the CVC is not even close to sufficient. Best to hire a PCI QSA. password becomes xxxxxxCxxxxxxxVxxxxxxCxxxxx, where": ["Schneier's Law"](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html): Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. – zaph Apr 30 '17 at 02:16
  • I'm a one-guy startup, trying to do the best I can so that I can launch and see if anybody is even interested in the product. The dream is to succeed and become able to afford a PCI QSA, but until then I just have to rely on generous people like yourself who donate their time in return of SO credit points, which is much appreciated :-). Back to the question, thanks for explaining at length why the CVC is weak. However if I pad it with random chars generated (and stored) on the server, to my understanding it's not a CVC any more. What am I missing? And how do I fix it? – DTs Apr 30 '17 at 20:29
0

In case if you don't want to implement all the stuff by yourself, you can check VGSCollect SDKs for iOS and Android. SDK collects all the data in PCI scope. All the encryption staff is done on their side, so you just get alias which you can use when sending payment request.

SpartaqUA
  • 41
  • 1
  • 5