2

My client wants to gather some sensitive info via an app. I don't want to store it on the server. Is this a good plan?

  1. Encrypt it on the phone using a public key embedded in the app.
  2. Send it to the server.
  3. Without saving it, email it to the client.
  4. They copy the base64 into a desktop app that decrypts it using a private key stored on the machine.

They already have such data in-house. So I figure this wouldn't be any less secure.

  • 1
    who is hosting the server? Maybe if your client hosing it then the mobile app should send the data to the server hosted by the client. or the app emails the data directly to the user. Why you have a server in the middle? – Ubaidah Oct 7 '19 at 2:12
  • Oh I didn’t realise it was possible to send an email directly from a phone. – Ian Warburton Oct 7 '19 at 5:52
  • The problem with this is that the device needs email account credentials. – Ian Warburton Oct 7 '19 at 14:45
  • you can use one email address as the sender, that sends the message directly to the clients (several receivers) and the mobile app should have an email API key not regular conditional. The app could not log in the mailbox only send emails – Ubaidah Oct 7 '19 at 17:08
  • If the email account login was misconfigured then perhaps someone could access it if they fished the details out of the binary. It's academic though because I'm planning to store the encrypted data in the database and have the client accesses the data from a web page. – Ian Warburton Oct 7 '19 at 17:15
2

I am a strong proponent of "The best way to protect data at rest is not to store it in the first place"! Keep it in memory for only as long as you need it.

I like your approach of using encryption to achieve this; if your server only touches the encrypted version, that's equivalent to not touching it at all!

I do have one improvement to suggest though. First, let's take a tangent into forward secrecy; the idea is that every time you encrypt something, you use a temporary disposable key that you don't keep a permanent copy of (aka "one time use" or "ephemeral" key) so that it's very hard for an attacker after the fact to get their hands on the decryption key for some data that they intercepted.

The idea of embedding a public key into the app does not have forward secrecy because you're using the same non-temporary key for every encryption.

Improvement #1: forward secrecy

  1. Phone requests a new ephemeral encryption public key from the server.
  2. Phone encrypts the data using the ephemeral public key.
  3. Phone sends the encrypted data to the server.
  4. Server uses the ephemeral private key (which was only stored in memory as part of the session) to decrypt the data.
  5. Server re-encrypts the data for the client.
  6. Send the encrypted data to the client however is easiest.

Once the server forgets the ephemeral key from step 4, the encrypted data blob that was sent up from the Android device is unrecoverable, so you don't need to be too careful about whether it ended up in router logs, etc. It's only the key that you need to protect.

If step 4 is public key encryption (ie RSA, and not symmetric encryption like AES) and only the client has the private key, then you could even keep a copy of that encrypted data in case the client needs it re-transmitted. This would be sorta equivalent security-wise to not storing it because you don't have the key to decrypt it.

Note: We're basically inventing TLS here, so let's do another version that uses a standard TLS stack rather than inventing our own protocol. We'll find that steps 1, 2, 3, and 4 are all taken care of for us at the TLS (HTTPS) layer.

Improvement #2: TLS

  1. Phone sends the encrypted data to the server over HTTPS.
  2. Server encrypts the data for the client.
  3. Send the encrypted data to the client however is easiest.

Again, so long as you are careful to re-encrypt the data for the client, and not keep a copy of the plaintext, you'll meet the requirement of "not storing it on the server".

  • That’s what I first thought of doing but couldn’t a hacker infiltrate the server and intercept the temporarily decrypted data? – Ian Warburton Oct 7 '19 at 5:51
  • Also the second part doesn’t pass forward secrecy either. All of the emails previously sent become accessible if the private key is compromised. So maybe my idea fails. – Ian Warburton Oct 7 '19 at 5:59
  • If storing the encrypted data on the server is safe then the base64 may as well be accessed from a webpage. – Ian Warburton Oct 7 '19 at 6:16
  • 1
    Public key embedded in the app sounds like a no go because there’d be no way to quickly update it if it needs to change. – Ian Warburton Oct 7 '19 at 6:41
  • 1
    @IanWarburton I like that you had a conversation with yourself in comments :) – Mike Ounsworth Oct 8 '19 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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