I'm designing the security for a smartphone app that can be used to make car reservations.

Clients have to register them with their driver's licence through the application and can then book a car.

Is it a good practice to hardcode the server's public key in the application and then encipher a secret using this public key?

I'm seeing an Eve-in-the-middle attack and authentication as a security issue. How can this be solved? Or how can this process be done securely?


1 Answer 1


Can you please describe your functional requirements in more detail, i.e. what are you trying to solve? That will ensure that you get most appropriate advice.

What do you care to achieve?

  • server to authenticate the client making the reservation?
  • a way for the client to send its driver license in a confidential manner?
  • client to authenticate the server before it sends its driver license?
  • ability to revoke and renew a compromised server key?
  • other?

Having a well defined number of functional requirements will let you laser-focus on determining what crypto primitives you should consider for meeting those functional requirements.

Encrypting the driver's license data with the server's RSA public key, in theory gives you confidentiality of the driver's license data since only the server private key may decrypt the driver license. In practice, the robustness of the confidentiality is a function of quality of your source of randomness, length of the RSA key, what padding is used, server-side protection of the private key, malleability of the client app since someone can hack your client app and replace the public key with their own public key, etc. In other words, take extra care with your implementation.

  • $\begingroup$ Hi Filip, I'm trying to register a before unknown client with the server. Sending the driver's license data using RSA would require a very large key length. Therefore, I thought using AES is a good option. $\endgroup$
    – John
    Commented May 4, 2016 at 22:04
  • $\begingroup$ AES will give you a smaller key. But there is a significant security tradeoff by switching from RSA to AES. The AES key is a symmetric key so the client app will need to have a copy of the secret key. Therefore, the robustness around protecting the AES key is up to how the client app protects that AES key. If the binaries of the client app gets dumped or the client app gets revers-engineered then that AES key might get compromised and with it all the data that it was used to encrypt. It's safe to assume that the client app will get reverse engineered :( Consider very carefully the tradeoff. $\endgroup$
    – Filip
    Commented May 5, 2016 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.