encrypt app state and private keys?

Solar2D General Questions/Discussion
#1

Hi,

I am thinking about using scrypt[0] to store my app’s private keys on the device. There are “KeyStore” mechanisms available on both on Android[1] and iOS[2] etc but they are different beasts with the need for device specific solutions for each.

 

It would be ideal to use NaCl[3] for the pk crypto and then use scrypt to store the private key on the device.

 

The same solution could then be used on all type of devices with all the benefits which comes with NaCl and scrypt.

 

The native “KeyStore” mechanisms in iOS and Android comes with their own pros of course.

 

Is this a lame idea? Anyone?

 

Cheers
/Joakim

 

[0] https://github.com/Tarsnap/scrypt

[1] https://developer.android.com/training/articles/keystore.html

[2] https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
[3] https://nacl.cr.yp.to/box.html

#2

Why do you need to store the keystore on the device?

#3

Do you propose that end-users should store their private pk crypto key on the server side?

#4

What is a “private pk crypto key”?

A keystore is used when building for Android. Private keys like keystores and provisioning profiles don’t need to be explicitly handled when developing apps with Corona. It sounds like you are referring to something different.

#5

I refer to the private key in public-key cryptography (https://en.m.wikipedia.org/wiki/Public-key_cryptography).

The private key is to be a secret for the end-users/clients only. In my app this private key never leaves the device (maybe except for a hard copy backup).

The public key is obviously stored on the server for each user.

#6

I’m confused:

  • Are you talking about signing your app?
  • Are you talking about public-private keys for something else?

  1. As Alex said, when we read your post, this sounds like you’re talking about app signing.  If so, you don’t include your signing certificate in your source folder when building your game/app.  If you do, it will get bundled with the app and later rejected by Google or Apple when the detect the key is in your ‘data’.

  2. If you’re talking about some other use of signing and cryptography, please give us an explicit and clear example of what your app is using it for and how you’re using it.  

At the end of the day, if you’re looking for a way to make your app un-steal-able or more-secure (whatever that would mean), changing the traditional method of signing your app won’t help.

#7

Sorry for being unclear. I do not talk about app signing but rather a scenario were users, for example, stores encrypted data on the server. This way the data on the server is opaque to the server owner.

To achieve this the app generates a public and a private key (using for example NaCl) and the private key never leaves the device and the public key is published on the server.

The app user can then, for example, public-key encrypt data with his/her public key and upload it to the server. Later on he/her can download the data and decrypt it using the private key. Many other scenarios comes to mind where users can interchange information meant for each other specifically using each others public keys. Nothing strange. This is the way public-key encryption promises secure interchange of data.

One of the weak links in such a scenario is to keep the private key safe(er) on the device.

Storing the private key scrypt encrypted on the device makes a brute force attack a bit harder. Not fool proof of course. Just a little bit harder.

The end-user could even be advised to print a hard copy of the private key (for example in a 2D bar code format) and put it in a safe place. That way the end-user can erase the encrypted private key from the device in case of emergency, i.e. the private key can later on be reread from the hard copy.

This last emergency scenario aside my question just is: How can I protect the private key on the device to make it harder to resist a brute force attack. 

If my question still is unclear I rest my case. :slight_smile:

Cheers

/Joakim

PS I might add that the scrypt encryption of the private key would require the end-user to remember a “pin-code” to unscramble the private key on app startup. By design. DS

#8

Summary: I talked shortly with the guy behind tarsnap/scrypt and he confirmed that my approach isn’t completely broken as long as I can get the end-user to provide a pin-code on application startup. I already have plugins written for NaCl and a scrypt so I will just run with this.

It seems that even Android’s key store uses/d scrypt encryption to resist brute force attacks on the key store. At least until Trusted Execution Environments (TEE) [1] becomes a commodity. iOS have the same as well. 

On to the next topic. Thanks for your input.

 [1] https://source.android.com/security/trusty/

#9

Why do you need to store the keystore on the device?

#10

Do you propose that end-users should store their private pk crypto key on the server side?

#11

What is a “private pk crypto key”?

A keystore is used when building for Android. Private keys like keystores and provisioning profiles don’t need to be explicitly handled when developing apps with Corona. It sounds like you are referring to something different.

#12

I refer to the private key in public-key cryptography (https://en.m.wikipedia.org/wiki/Public-key_cryptography).

The private key is to be a secret for the end-users/clients only. In my app this private key never leaves the device (maybe except for a hard copy backup).

The public key is obviously stored on the server for each user.

#13

I’m confused:

  • Are you talking about signing your app?
  • Are you talking about public-private keys for something else?

  1. As Alex said, when we read your post, this sounds like you’re talking about app signing.  If so, you don’t include your signing certificate in your source folder when building your game/app.  If you do, it will get bundled with the app and later rejected by Google or Apple when the detect the key is in your ‘data’.

  2. If you’re talking about some other use of signing and cryptography, please give us an explicit and clear example of what your app is using it for and how you’re using it.  

At the end of the day, if you’re looking for a way to make your app un-steal-able or more-secure (whatever that would mean), changing the traditional method of signing your app won’t help.

#14

Sorry for being unclear. I do not talk about app signing but rather a scenario were users, for example, stores encrypted data on the server. This way the data on the server is opaque to the server owner.

To achieve this the app generates a public and a private key (using for example NaCl) and the private key never leaves the device and the public key is published on the server.

The app user can then, for example, public-key encrypt data with his/her public key and upload it to the server. Later on he/her can download the data and decrypt it using the private key. Many other scenarios comes to mind where users can interchange information meant for each other specifically using each others public keys. Nothing strange. This is the way public-key encryption promises secure interchange of data.

One of the weak links in such a scenario is to keep the private key safe(er) on the device.

Storing the private key scrypt encrypted on the device makes a brute force attack a bit harder. Not fool proof of course. Just a little bit harder.

The end-user could even be advised to print a hard copy of the private key (for example in a 2D bar code format) and put it in a safe place. That way the end-user can erase the encrypted private key from the device in case of emergency, i.e. the private key can later on be reread from the hard copy.

This last emergency scenario aside my question just is: How can I protect the private key on the device to make it harder to resist a brute force attack. 

If my question still is unclear I rest my case. :slight_smile:

Cheers

/Joakim

PS I might add that the scrypt encryption of the private key would require the end-user to remember a “pin-code” to unscramble the private key on app startup. By design. DS

#15

Summary: I talked shortly with the guy behind tarsnap/scrypt and he confirmed that my approach isn’t completely broken as long as I can get the end-user to provide a pin-code on application startup. I already have plugins written for NaCl and a scrypt so I will just run with this.

It seems that even Android’s key store uses/d scrypt encryption to resist brute force attacks on the key store. At least until Trusted Execution Environments (TEE) [1] becomes a commodity. iOS have the same as well. 

On to the next topic. Thanks for your input.

 [1] https://source.android.com/security/trusty/