2

I want my native applications (android/ios) to have a keypair (RSA or ECIES) so that certain data on requests to my API can be encrypted. I want each client to have a unique keypair. The device will register that keypair with my API and it will be locked down to the unique fingerprint of that device.

I have two options for key generation. The first option is to generate key pairs server side signed with some intermediate cert and deliver these to the application. All API calls are TLS encrypted.

The second option would be to have the app generate key pairs locally. This means the private key does not need to be transmitted, but these keys will be 'self-signed'.

Since my use case is largely to lock down API requests to registered devices, is there any security benefit to generating key pairs server side?

Improve this question
3
  • Why do you think that not generating the key on the server means that it will have to be self signed?
    – Joseph Sible-Reinstate Monica
    Oct 29, 2019 at 16:30
  • We could deliver a signing key with the app itself but that might as well be public. How would I be able to protect a signing key if the client needs it to generate keys?
    – Tom L.
    Oct 29, 2019 at 22:27
  • 1
    Have the client generate a keypair, then send just the public key to the server to get it signed?
    – Joseph Sible-Reinstate Monica
    Oct 29, 2019 at 22:28

1 Answer 1

Reset to default
1

You absolutely don't need to generate a key pair on the server-side. In fact, this is the last thing you want to do.

Generating the keys on the mobile side means that the private key NEVER leaves the device and only the public key gets shared with the server, which minimizes the exposure of the private key.

Public key becomes a fingerprint of the device as you requested.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .