CODEWITHSUNDEEP
iphoneioskeyencryption
user2393462435
user2393462435

Reputation: 2652

Dynamically generating a decryption key rather than hardcoding a string literal? (Objective-C / iPhone)

My iPhone app is using encrypted assets. The decryption key will need to be hardcoded but I'm trying to avoid using a string literal. Is there a good standard algorithm to do this sort of thing?

Assume my key is:

abcdef01-2345-6789-abcd-ef0123456789

Rather than do this:

NSString *key = @"abcdef01-2345-6789-abcd-ef0123456789";

I rather do something like this:

-(NSString *)key {

    //TODO: generate abcdef01-2345-6789-abcd-ef0123456789 dynamically

    return generatedKey;
}

Thoughts?

Upvotes: 4

Views: 667

Answers (2)

emboss
emboss

Reputation: 39620

Bad idea. The reason is the same as for hard-coded passwords. You can obfuscate and XOR the final password together from several places, but a capable hacker will monitor the memory of the device and reverse engineer any clever protocol with enough time. That he has if he simply steals the phone. Or could mount side-channel attacks and measure execution time or power consumption, therefore guessing the key much like safecrackers in movies would - fiddling with keys bit for bit and "listening" if they are any closer to their goal.

So you can make it harder, but without a hardware-supported secure storage mechanism (that would protect memory access and obfuscate power consumption, execution time etc. much like smart cards or hardware security modules do) there's no chance to make this secure.

The password needs to stay out-of-band information, separated from the device. Ideally, the user would enter it each time it is needed. Of course that is tedious from a user perspective - but at least it's secure.

Upvotes: 1

rossum
rossum

Reputation: 15685

One possible method is to use two or three byte arrays such that key[i] = ary1[i] ^ ary2[i] ^ ary3[i]. You should initialise them in three separate places. You don't have to XOR then in the same loop either, two can be XOR'ed first and the third later. It depends how awkward you want to make it for any attacker.

It won't be perfectly secure but it will deter a casual attacker. For a non-casual attacker you will need a crypto expert, which I am not. How much you can pay for a consultant will depend on how much it will cost you if data is stolen.

Oh, and never call your key key[], that is just asking for trouble. :)

Upvotes: 0

Related Questions