Reputation: 1600
I am developing an android application that uses a public key certificate to sign messages sent to the server. When the user logs in, he receives a x509 certificate. Now, when he wants to send messages to the server, he has to sign the message using the certificate public key and send it to the server along with the message. I am new to security and I don't know how to go about this. These are some of the questions I have:
How can i securely store the certificate in the phone so that my app can use it to sign messages sent to the server?
I am also planning to do key rotation once in some time. So, the server will send the updated certificate to the user and my app has to update the certificate stored in the phone.
If you can point me to a tutorial or any issues i need to carefully handle , it will be really helpful. Thanks
Upvotes: 1
Views: 2292
Reputation: 359
The first question you should be asking yourself is whether you want to sign or encrypt your message. If you want to sign (= prove to the recipient that your message was not altered on the transport way and also prove that the sender is really your app) then you should sign with the private key and have the server verify the signature with the public key. If you want to encrypt the message then you should encrypt it with the server's public key and have the server decrypt it with its private key.
Second problem is the transport of the certificate: If you are concerned about a man-in-the-middle tampering with your application's messages then this very attacker could also intercept the certificate you're sending to the app and therefore sign his messages.
To answer your questions:
The only way I can think of to store anything securely on the phone (so that no attacker can access it even if he gains root privileges) is encrypting it with a user password that is not stored on the device but has to be entered by the user everytime the certificate is to be accessed.
If you managed to get one certificate safely to the device (which I doubt you can) then you could perform the key rotation by encrypting the new certificate with the old certificate's public key on the server side and send it to the device. There you can decrypt it with the private key.
Upvotes: 3
Reputation: 305
This really depends on what you goal is. If the goal is to assert that a valid authenticated user sent the request, then signing with the public key is not the way to go. To identify that the sender is who you think it is, you sign with the private key and validate with public key. However, depending on your environment, the client keeping the private key private may be an issue.
If your goal is simply tamper-evidence then perhaps a HMAC (keyed hash) may be a more efficient way to go.
Upvotes: 0