Storing In App Purchase receipts in the application Keychain

Question

I've never implemented In App Purchase before, so I used the MKStoreKit wrapper and have a working implementation. MKStoreKit keeps all receipts in the UserDefaults .plist as a BOOL, thus it is very simple for pirates to distribute the in app purchases in a "cracked" state. Once the first purchase is made, the bundle can be distributed and the .plist can be recreated to enable IAP unlocks.

I'd like to extend MKStoreKit to create the In App Purchase validation data in the iOS keychain. Is there any drawback or possible reason for this to fail for paying users, be unreliable, or any other reason why it would be an overall bad idea to do this? I understand that piracy is inevitable, and I definitely don't want to alienate paying users, but I feel that the UserDefaults .plist is too much of an easy way to bypass.

In my scenario, a simple string would be put into the keychain when the purchase is made. That way, if the binary gets distributed, unlockables are not already enabled. Sure, it would be possible to come up with a workaround, but it would take a little more effort and know how to find the TRUE/FALSE flag and cause it to always return the correct value. Through obfuscation I could even make it slightly more difficult to track that down.

Thanks for all of your insights and I appreciate answers avoiding the obligatory inevitable-piracy, deal-with-it replies. I'm more interested in the technical viabilities of this solution.

Shrum

+1 this is relevant to my interests. Currently I add some string (as salt) to the device identifier and md5 all that together and store this in the userdefaults. – Inverson

Very cool. That way it won't authenticate on another device without having iTunes credentials. – Shrum

For the record, I am not sure if you were involved or not, but MKStoreKit now creates validation data in the iOS Keychain. – Chastitychasuble

Yea this post was before that was implemented – Shrum

For the record, @MatthiasBauch's approach is probably a bad idea--if a user upgrades to a new device and restores from backup, the device id (or whatever the UUID replacement that does the same thing is called) will not match! It will look like a pirated copy, so at a minimum the user would have to restore the purchase--or if you're doing something more overt when you think it's pirated, it's likely to backfire on legitimate users in that case. – Mikes

No backfiring involved. At least if you treat "data mismatch" as "not registered" and not "pirate who must be punished". I would go one step further and offer the restore option if there is a data mismatch, because it's most likely not from a pirate, but a legit user who has restored from a backup. Restoring purchases is not a big problem, just make sure to not alter any saved data (e.g. delete all Foo entries in the Database if the Foo feature is not unlocked). I use code like this in literally millions of installs. Not a single support incident was caused by a mandatory purchase restore. – Inverson

I'm not sure if the salted and hashed vendor identifier saved us from any potential pirate, but I still feel better than just saving registered=yes in the keychain (or even worse, userdefaults). If somebody want's to pirate I want him to work for it ;-) – Inverson

Honestly I don't think the UUID is reliable. Because it's not the real "Unique id" of the device so that people can copy everything from valid User defaults to their own copy. – Novel

I'm wondering whether the iCloud Keychain support makes this approach any less desirable? – Black

Answer 1

We do exactly that in our of our apps and it works great.It’s a free app that you can upgrade to a full version and we store the upgrade indicator in the keychain. The upgrade indicator is an arbitrary string that you choose, but for the purposes of the keychain it is treated as a password, i.e. the value for kSecValueData is encrypted in the keychain. A nice bonus about this approach is that if the user deletes the app and then later re-installs it, everything is re-enabled like magic because the keychain items are stored separately from the app. And it’s so little additional work over storing something in the user defaults that we decided it was worth it.

Here’s how to create the security item:

NSMutableDictionary* dict = [NSMutableDictionary dictionary];

[dict setObject: (id) kSecClassGenericPassword  forKey: (id) kSecClass];
[dict setObject: kYourUpgradeStateKey           forKey: (id) kSecAttrService];
[dict setObject: kYourUpgradeStateValue         forKey: (id) kSecValueData];

SecItemAdd ((CFDictionaryRef) dict, NULL);

Here’s how to find the security item to check its value:

NSMutableDictionary* query = [NSMutableDictionary dictionary];

[query setObject: (id) kSecClassGenericPassword forKey: (id) kSecClass];
[query setObject: kYourUpgradeStateKey          forKey: (id) kSecAttrService];
[query setObject: (id) kCFBooleanTrue           forKey: (id) kSecReturnData];

NSData* upgradeItemData = nil;
SecItemCopyMatching ( (CFDictionaryRef) query, (CFTypeRef*) &upgradeItemData );
if ( !upgradeItemData )
{
    // Disable feature
}
else
{
    NSString* s = [[[NSString alloc] 
                        initWithData: upgradeItemData 
                            encoding: NSUTF8StringEncoding] autorelease];

    if ( [s isEqualToString: kYourUpgradeStateValue] )
    {
        // Enable feature
    }
}

If upgradeItemData is nil, then the key doesn’t exist so you can assume the upgrade is not there or, what we do, is put in a value that means not upgraded.

Update

Added kSecReturnData (Thanks @Luis for pointing it out)

Code on GitHub (ARC variant)

Seamanlike

Good stuff. More people need to do this with their apps. So many apps just store stuff in the plist. It is easily editable with a tool like iExplorer and does require a jailbroken device. – Sudoriferous

You may need to add [query setObject:(id) kCFBooleanTrue forKey: (id) kSecReturnData]; before calling SecItemCopyMatching – Shanell

If your app is running in the background (i.e. a navigation app), you should add: [dict setObject: (id) kSecAttrAccessibleAfterFirstUnlock forKey: (id) kSecAttrAccessible]; Otherwise, the keychain item will suddenly become inacessible as soon as the device falls into the state, where you have to enter your pin code in order to unlock it. – Schoenfeld

What would you guys suggest to set kYourUpgradeStateKey and kYourUpgradeStateValue for example for a pro version purchase. Just as an example and for me to get an idea of the possibilities. – Trooper