Security Evaluation Questions on card.io

[vaspnet]

Hi card.io Engineers,

Can you please help answer the following security evaluation questions on card.io?

1. Does card.io adhere to secure coding practices and conduct vulnerability assessments on its SDKs?
2. Does card.io conduct penetration testing exercises on its SDKs?
3. What security assurance does card.io provide to enterprise consumers of the card.io SDKs?
4. If there is a security flaw/critical fix identified in the current or future versions of the card.io SDK, what communication mechanism does card.io team adopt to help consumers of card.io to stay updated with such fixes/patches?
5. Does card.io have dynamic integrity check mechanism (like a checksum) to ensure card.io SDK integrity at runtime?
6. Does the card.io app token have an expiry time to it?
7. How often does the card.io app token get validated?
8. Can the card scan operation performed without a network connection from a mobile device?
9. How does the card.io app token get validated when the mobile device does not have a network connection?

Thank you!

[josharian]

Can you provide some context for this request?

[tooluser]

Some are in the FAQ I think but I’d like to see an overall policy, too, actually. That’d be great. Especially given the delicate nature of the data and opacity of the project.

I could imagine contexts ranging from “cares about security/privacy of user financial data” to “company is an acquisition target and basic due-diligence requires addressing security risks with customer financial data”.

Thanks!

On Jul 17, 2014, at 12:22 PM, Josh Bleecher Snyder notifications@github.com wrote:

Can you provide some context for this request?

— Reply to this email directly or view it on GitHub.

[vaspnet]

We were evaluating card.io to scan card on mobile device - as part of our evaluation process, we had some questions that we posted on the tech support and tech support asked us to post it here to get answered directly from card.io engineers.

[dgoldman-pdx]

@vaspnet we do take security considerations into account when designing, implementing, and maintaining our SDKs.

However, please note that unlike an app, any SDK which gets incorporated into a third-party app is completely open to a sufficiently motivated attacker (via the app itself). There is, ultimately, no way for the SDK to hide anything from the embedding app.

In any case, the card.io SDK merely provides a way for your users to enter their card number via camera rather than keyboard. It then returns that card number to your app. Therefore there is no user information to hide or protect within the SDK. It is up to your app to protect the user's data.

Regarding your non-security questions:

what communication mechanism does card.io team adopt to help consumers of card.io to stay updated with such fixes/patches?

See here.

Does the card.io app token have an expiry time to it?

No.

How often does the card.io app token get validated?

That is proprietary information.

Can the card scan operation performed without a network connection from a mobile device?

Yes.

How does the card.io app token get validated when the mobile device does not have a network connection?

Obviously, it does not get validated under such circumstances.

[tooluser]

Your points are good, and thank you, but don’t really address the extent of security requirements. For example, it’s entirely within the potential of the SDK to introduce vulnerabilities the containing app doesn’t have, and/or itself be compromised (what the checksumming was intended to measure). 
Or the SDK could be compromised, and, while the containing app maintains perfectly good security, it could be transmitting financial information without any participation from that app (NSURLProtocol whitelisting could prevent this). Without open code, this is impossible to verify, so it seems reasonable to ask what procedures are in place to prevent it, since users of the SDK can’t verify its security themselves.

On Jul 17, 2014, at 1:34 PM, Dave Goldman notifications@github.com wrote:

@vaspnet we do take security considerations into account when designing, implementing, and maintaining our SDKs.

However, please note that unlike an app, any SDK which gets incorporated into a third-party app is completely open to a sufficiently motivated attacker (via the app itself). There is, ultimately, no way for the SDK to hide anything from the embedding app.

In any case, the card.io SDK merely provides a way for your users to enter their card number via camera rather than keyboard. It then returns that card number to your app. Therefore there is no user information to hide or protect within the SDK. It is up to your app to protect the user's data.

Regarding your non-security questions:

what communication mechanism does card.io team adopt to help consumers of card.io to stay updated with such fixes/patches?

See here.

Does the card.io app token have an expiry time to it?

No.

How often does the card.io app token get validated?

That is proprietary information.

Can the card scan operation performed without a network connection from a mobile device?

Yes.

How does the card.io app token get validated when the mobile device does not have a network connection?

Obviously, it does not get validated under such circumstances.

— Reply to this email directly or view it on GitHub.

[dgoldman-pdx]

@tooluser I understand your concerns and appreciate the points you've raised.

But re compromise of the SDK, to be caught by the SDK checksumming itself, I don't see how that would be usefully implemented. You download the SDK from our github repo and integrate it into your app. If the SDK were already compromised prior to downloading, then any dynamic integrity check mechanism within the SDK would presumably also have been compromised (assuming a mildly competent attacker). On the other hand, once you've downloaded the SDK it is now just another part of your app's codebase, and thus subject to any app-checksumming you'd like to perform.

[tooluser]

I was only offering that as supporting logic for one of the questions he raised. The usual mechanism for checksumming is for a code base to be checksummed via signature tying the proof to a culpable individual via a public authority, using e.g. a PK system like PGP. Code can be compromised several places along the development path, so signatures when it leaves the mother ship are still valuable. 

It’s a tough issue, to be sure, but once he raised the overall point, I did realize that there isn’t really any public guarantee nor verifiable code for this system, which is after all handling really delicate and valuable data. 

(Why is it that it’s not open source, anyway? You’d expect a closed-source system of this nature to balance that decision with really transparent validations, but it doesn’t seem like either is forthcoming. Is there a company policy? Does it prevent statements about the company policy?)

Please don’t misunderstand - it’s a nice piece of kit, and it’s a pleasure to use. But it is very odd to both have this strange opaque library ‘git repository’ that isn’t really showing what’s going on, and very little public statement of privacy guarantee, combined with no signature verifying the SDK - when it handles user financial data. I’m realizing that, as it stands, unless I’m mistaken, I have no way to guarantee within the limits required by law that the data are correctly handled! Am I missing some public statements about the kit somewhere? 

Thanks much.

On Jul 17, 2014, at 1:52 PM, Dave Goldman notifications@github.com wrote:

@tooluser I understand your concerns and appreciate the points you've raised.

But re compromise of the SDK, to be caught by the SDK checksumming itself, I don't see how that would be usefully implemented. You download the SDK from our github repo and integrate it into your app. If the SDK were already compromised prior to downloading, then any dynamic integrity check mechanism within the SDK would presumably also have been compromised (assuming a mildly competent attacker). On the other hand, once you've downloaded the SDK it is now just another part of your app's codebase, and thus subject to any app-checksumming you'd like to perform.

— Reply to this email directly or view it on GitHub.

[vaspnet]

Thank you Mr. Goldman for your quick response to my questions - although some of my questions had obvious answers and may seem unnecessary as I could have answered them myself, I was looking for card.io engineers to respond to them so we don't assume anything and thank you for answering them.

As for the security questions (1-3), you stated "We do take security considerations into account when designing, implementing, and maintaining our SDKs" - can you elaborate on my question #3?

What security assurance does card.io provide to enterprise consumers of the card.io SDKs? For instance, card.io uses a dependent library to protect the core operational code - "libCardIO.a" what security assurance does consumers of the card.io SDK have that no card info is being masked and sent at time of validation of the app token?

Thank you again for your response.

Regards.

[vaspnet]

Please note, my question No. 3 above is only focused to help seek assurance with the SDK - The basis of my question is: open source software is typically made open to software engineers in the community to contribute towards making the software more extendible while supporting many more use-cases hence software product evolves to become more useful while bugs are reported, discussed and fixed all in a collaborative environment.

This particular SDK applying innovative techniques dealing with OCR while rendering the card number although brings high value, it also brings concerns around security around consumer card data. If a branded company like PayPal makes a statement that their card.io SDK is being developed internally without external contribution to the core SDK that in itself should help significantly with security evaluation questions I've posted here. Hope this explains some of the thought process behind my questions.

Thank you

[dgoldman-pdx]

Your questions arise at a time when we're having some relevant internal discussions. I hope to have a more definitive response for you next week.

[vaspnet]

Thank you - no rush, your response is very much appreciated and valued.

[tooluser]

Yes, thanks a million!

On Jul 18, 2014, at 12:00 PM, vaspnet notifications@github.com wrote:

Thank you - no rush, your response is very much appreciated and valued.

— Reply to this email directly or view it on GitHub.

[vaspnet]

Just a friendly reminder to card.io engineers to respond with specifics on security evaluation questions to help with card.io adoption.

[dgoldman-pdx]

@vaspnet thanks for the friendly reminder.

My impression is that you need either of two things: (1) an official statement from a representative of PayPal (such as myself), or (2) open-source code for the card.io SDK. Right?

At this moment I cannot give you the second thing.

To save time regarding the first thing, could you please provide a draft statement that would fully satisfy your needs?

[tooluser]

I’d be interested in knowing why CardIO isn’t willing to open source the code. Would that be possible to get an official statement on?

On Jul 24, 2014, at 11:45 AM, Dave Goldman notifications@github.com wrote:

@vaspnet thanks for the friendly reminder.

My impression is that you need either of two things: (1) an official statement from a representative of PayPal (such as myself), or (2) open-source code for the card.io SDK. Right?

At this moment I cannot give you the second thing.

To save time regarding the first thing, could you please provide a draft statement that would fully satisfy your needs?

— Reply to this email directly or view it on GitHub.

[dgoldman-pdx]

@tooluser my statement above, in its entirety, was At this moment I cannot give you the second thing.

At this moment, we have nothing to add to that statement.

[vaspnet]

Thank you @dgoldman-ebay - I perfectly understand the options and no concerns there - I will send a draft statement that would satisfy our needs and you can send it back with an official statement as you stated.

[tooluser]

I’m sorry, I didn’t mean to give the impression I hadn’t read your statement when I asked for an expansion on it. I understand that you are unwilling to expand on it.

I’m sensing a rising antagonism here, and I hope we can put it aside. The (very nice) Card.IO kit handles some very sensitive data, and its policies about the openness of its code are odd given that handling. I think it’s reasonable for users of the (very nice) kit to be concerned about the privacy of their users - especially anyone who has to certify PCI compliance on their app!

I just want to be able to keep using the (very nice) kit. We’ll be unable to if we can’t be sure it’s PCI complaint, which would be disappointing! It seems like a reasonable thing to do, though, given the sensitivity of the data and the professionalism of Card.IO, so I hope we can work something out. It sounds like it.

I didn’t mean to pry into corporate secrets when I asked why this code that handles sensitive user data wasn’t amenable to open sourcing. It seemed like a question that could be answered even if the code itself couldn’t be opened. EG, “our imaging algorithm is private”. Of course that would lead to asking why only that code wasn’t factored, in that case. . . . but it seems a reasonable conversation. I am sorry that it is not, and that Card.IO is unwilling to converse about it.

Thank you for your willingness to provide some sort of statement about the privacy and security of the system.

On Jul 24, 2014, at 11:53 AM, Dave Goldman notifications@github.com wrote:

@tooluser my statement above, in its entirety, was At this moment I cannot give you the second thing.

At this moment, we have nothing to add to that statement.

— Reply to this email directly or view it on GitHub.

[tooluser]

Would it be reasonable to 

a) state whether Card.IO is PCI-complaint and b) publish this statement publicly as part of this official statement?

Thanks much;

Joshua

On Jul 24, 2014, at 11:56 AM, vaspnet notifications@github.com wrote:

Thank you @dgoldman-ebay - I perfectly understand the options and no concerns there - I will send a draft statement that would satisfy our needs and you can send it back with an official statement as you stated.

— Reply to this email directly or view it on GitHub.

[dgoldman-pdx]

Not sure how many ways I can emphasize this: "at the moment".

[tooluser]

Apologies. Email is hard (for me, apparently). I’ve noticed you’re pretty much ‘the guy’ on this project, too, and it’s probably not your only project. Good luck, sir, and godspeed.

On Jul 24, 2014, at 12:05 PM, Dave Goldman notifications@github.com wrote:

Not sure how many ways I can emphasize this: "at the moment".

— Reply to this email directly or view it on GitHub.

[vaspnet]

@tooluser - I believe, PCI compliance deals with securely handling and storing payment card information at a high level - from what i understand as stated before by card.io engineers, card.io puts that responsibility of PCI compliance on the consuming mobile app that uses card.io SDK since its the consuming mobile app that handles and/or stores the card data. card.io is merely providing an alternative to keypad entry to capture the card number. Hope this helps with respect to PCI compliance topic.

[tooluser]

Hmm. I suppose I misspoke about it then. . . . maybe I’m missing something.

If our app uses a service that we hand images of customer credit cards to and get back PANs, isn’t it part of our PAN-handling chain? 
And aren’t we required to state that that chain doesn’t mishandle the PANs? That is, providing access to images of the customer’s card seems like it is a PCI issue. 
I’m not suggesting Card.IO *is* of course. Just that I can’t say that, and fear someone asking me to prove it!

Perhaps I’m misunderstanding my PCI obligation - I’ve actually just asked someone to clarify it for me. 
In any case, thanks for the comment. It sounds like we are after essentially the same kind of thing, and it’s clear good intent is there and it sounds like wheels may be turning. 

On Jul 24, 2014, at 12:11 PM, vaspnet notifications@github.com wrote:

@tooluser - I believe, PCI compliance deals with securely handling and storing payment card information at a high level - from what i understand as stated before by card.io engineers, card.io puts that responsibility of PCI compliance on the consuming mobile app that uses card.io SDK since its the consuming mobile app that handles and/or stores the card data. card.io is merely providing an alternative to keypad entry to capture the card number. Hope this helps with respect to PCI compliance topic.

— Reply to this email directly or view it on GitHub.

[vaspnet]

on the other hand, if card.io was providing a complete echo system to capture and manage your payment card information and engaged with card.io servers - this kind of processing would certainly fall under requiring PCI compliance and we could see PayPal consider PCI compliance and with that, i'm quite certain we would be looking at a licensed product and SLA.

[vaspnet]

Hi @dgoldman-ebay is there a way for me to send a tech eval questionnaire? I would like to send it through secure channel. Please advice.

[dgoldman-pdx]

@vaspnet you can find my email address in my github profile.

[dgoldman-pdx]

I still have nothing new to say regarding open-sourcing card.io. :disappointed:

However, I did want to mention that the just-released version 3.10.0 has eliminated the app token, along with all the associated networking code. card.io no longer knows of this thing called the Internet.

[tooluser]

And good riddance, right? It’s a fad anyway.

That’s fantastic, Mr Goldman. Thanks a thousand times.

Love the ‘preload', too. We tried to stimulate a preload but it was a hassle; this is very nice.

On Oct 2, 2014, at 3:42 PM, Dave Goldman notifications@github.com wrote:

I still have nothing new to say regarding open-sourcing card.io.

However, I did want to mention that the just-released version 3.10.0 https://github.com/card-io/card.io-iOS-SDK/releases has eliminated the app token, along with all the associated networking code. card.io no longer knows of this thing called the Internet.

— Reply to this email directly or view it on GitHub https://github.com/card-io/card.io-iOS-SDK/issues/57#issuecomment-57721282.

[dgoldman-pdx]

Closing this issue because:

• @vaspnet has gotten his original questions answered, through direct communication;
• the most important card.io issues regarding security and confidentiality have been rendered moot by the removal of all networking code, as mentioned above;
• we still don't seem to have anything to say re open-sourcing card.io. At this moment.

[dgoldman-pdx]

@tooluser you might be interested in this.