3

I am new of iOS swift 3 development. Now, I am working on a project which needs encryption, message authentication code(MAC) and Hashed-base-MAC. These algorithms require secret keys. I know that it is a bad practice to hard-code the keys inside the code, like:

let key = "secretkeyabc123"

Searched and read some articles like: In iOS, how can I store a secret "key" that will allow me to communicate with my server?

Since other people may perform reverse engineering, I am finding a way to protect my keys. Requirements:

  1. No hash the key. Time allows to crack it, or with hashed table and dictionary
  2. May not connect to Internet (My app. is an offline app. If your answer needs to connect to Internet. Yes, please point it out. I will think about it)
  3. It is a static key. It may change monthly
  4. It is a symmetry key.

Codes, concept or other things are welcome. Thanks!

mfaani
  • 33,269
  • 19
  • 164
  • 293
Cally Chan
  • 53
  • 1
  • 5
  • "Time allows to crack it" if you're worried about an amount of time on the order of the lifespan of the universe, then I guess so. – Alexander Nov 04 '16 at 13:08
  • @Alexander what do you do with a secret key? Hash/encrypt every API call you make? And then the server will also decrypt it using the same key it has given you? – mfaani Jul 25 '19 at 11:11
  • @Honey Well your secret key can't be in the app binary, at all. If it's plaintext (like it was the case for Snapchat, lol), then it's trivial to see it. If you store your secret key in a hashed form, then you lose access to your secret key (since you can't unhash it). If you use the hashed form of your secret key for encryption/signing, then your hashed secret key is effectively your new secret key, and it's stored in plaintext, which fails. Encrypting the secret key doesn't work, because you only "kick the can down the road", because then you have to figure out how to store the encryption key – Alexander Jul 25 '19 at 15:18
  • @Honey As I state in my answer, the key is to have the server provide the secret key after installation, over an encrypted channel (using a DH handshake to derive the encryption keys for that channel). "Hash/encrypt every API call you make?" This is a separate question, of how to use the secret key after you have securely acquired and stored it. Your secret key should never leave the device. It should be used to locally sign/encrypt out-going traffic, that the server will decrypt using the same key. – Alexander Jul 25 '19 at 15:20
  • @Alexander "Well your secret key can't be in the app binary, at all." Isn't that what is being asked and recommended [here](https://stackoverflow.com/questions/29760216/in-ios-how-can-i-store-a-secret-key-that-will-allow-me-to-communicate-with-my). I'm not trying to trigger a debate, rather **just to confirm that there's difference of opinions**. To your point though I see a different answer from Rob Napier [here](https://stackoverflow.com/a/14865043/5175709). So you disagree Because obviously if a secret app is hacked, then all of them are. – mfaani Jul 25 '19 at 18:48
  • To your point though I see a different answer from Rob [here](https://stackoverflow.com/questions/14778429/secure-keys-in-ios-app-scenario-is-it-safe/14865043#14865043). So you disagree Because obviously if a secret app is hacked, then all of them are. Also doesn't your last sentence confirm my initial comment? – mfaani Jul 25 '19 at 18:58
  • @Honey This conversation is suffering from the ambiguity of the term "key". There are two definitions in use in this conversation: API keys, and encryption keys. They have different threat models. API keys you want to keep secret from anyone but the developer, the app, and the API that requires them. As rob suggests, you can't really do much there. I was talking about encryption keys. There's no harm done if a user can figure out what encryption key is being used by one of their apps. It just needs to be protected from everyone *else*. – Alexander Jul 25 '19 at 19:15
  • @Honey So my statements only conflict with Rob's if you conflate API keys and encryption keys. Otherwise, they're making two different statements within two separate domains. – Alexander Jul 25 '19 at 19:15
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/197008/discussion-between-honey-and-alexander). – mfaani Jul 25 '19 at 19:34
  • @Alexander I added you to another chat discussion [here](https://chat.stackoverflow.com/rooms/198200/continue-discussion). Can you join please – mfaani Aug 21 '19 at 13:07

2 Answers2

2

Don't store the key at all. Perform a Diffie-Hellman key exchange to start an asymmetrically encrypted channel, and use this channel to send across a symmetric key to the client, which can be used for subsequent client use.

Alexander
  • 59,041
  • 12
  • 98
  • 151
1

Check iCloud Keychain (based on your tags [ios], [swift], [key]).

It functions as a secure database that allows information including a user's website login passwords, Wi-Fi network passwords, credit/debit card management (though without CVV), and other account data, to be securely stored for quick access and auto-fill on webpages and elsewhere when the user needs instant access to them. They are always stored encrypted using 256-bit AES encryption, are stored on device and pushed from iCloud between devices, and only available on a user's trusted devices.

user3441734
  • 16,722
  • 2
  • 40
  • 59
  • 1
    The keychain is a good place to put security credentials, but it's another question of how to securely get them there, in the first place. – Alexander Jul 25 '19 at 15:16
  • @Alexander what is the trouble? – user3441734 Jul 26 '19 at 19:18
  • Let's say you have an encryption key that you want your client to use for encrypted communication. You'll eventually store it in the keychain for safe keeping. How would you get it there, in a manner that can't be intercepted? – Alexander Jul 26 '19 at 19:42
  • @Alexander to create, store etc. , and to use private and public part of the key you have public iOS API. The symmetric key should be generated for one-time usage only, never use it twice, so there is no need to store it at all. – user3441734 Jul 26 '19 at 20:00