0

I'm passing sensitive financial data to a payment processor online via cloud functions and would like your expert opinions, please.

The workflow is as follows:

  1. A customer indicates they want to transact by tapping a checkout button.

  2. The checkout button hits an API on the server which generates public and private keys. Both keys are sent to a secured database, keyed by the public key. Only the server has permissions to read and write to the database. The server responds to the client with the public key so the customer can asymmetrically encrypt their data.

  3. The customer enters their sensitive bits into the client on ssl/tls, which encrypts the data with the public key and then sends the data and public key back to the server.

  4. The server fetches the private key from the database using the public key, decrypts the customers sensitive data, deletes both keys from the database, tokenizes the decrypted data, and finally submits the tokenized data to the transactional processor. The client is updated with a callback for the transaction state or error.

Is this a secure procedure? What weak points can I address? What is the technical term for this strategy?

irth
  • 103
  • 5
  • 5
    this is not e2e encryption if the server is handling the keys. – schroeder Jan 27 '19 at 13:50
  • 4
    Please read up on PCI etc. . And making your own encryption inside of TLS is not very useful. – deviantfan Jan 27 '19 at 13:52
  • 5
    You do not explain why you want to do things this way and what this scheme is meant to accomplish. I'm unsure what benefit this would have over TLS. – schroeder Jan 27 '19 at 13:52
  • 2
    Why can't the server just generate a symmetric key instead of all the key swapping? What does a public/private key scheme do for you? – schroeder Jan 27 '19 at 13:54
  • @schroeder thank you and apologies for less than useful user story. The processor encourages using their module system on the client but i'm wary of giving them so much analytic access and resource overhead. In lieu of using their modules, I am pinging their API direct which tokenizes user data before sending off to process. The processor needs a secret key from our server anyhow, so i need a best practice to get the customers data to our server from the client app. – irth Jan 27 '19 at 14:16
  • @schroeder to your second point, there's not much swapping happening. the server is storing both keys because it verifies the same public key to locate the private key to decrypt the data before tokenizing on the server. it's one pair generated in the process. am I over thinking this? – irth Jan 27 '19 at 14:18
  • @deviantfan, aye this has to do with the PCI bit about risk management to protect cardholder data. The processor is fully compliant already, but I need to make sure the trip from client to server is as sound as possible. – irth Jan 27 '19 at 14:21
  • 2
    If we ignore the SSL/TLS, then it sounds like this would provide resistance against a passive attacker, but an active attacker could fairly easily steal the client's sensitive data (basically by substituting their own public key in the server's response, tricking the client into passing their sensitive information with the attacker-controlled public key, then re-encrypting it with the server's public-key to avoid detection). But since you are relying on SSL/TLS, what's the intended advantage of the extra encryption? – Nat Jan 27 '19 at 14:39
  • 2
    Note that using your processors modules moves liability for any compliance and confidentiality requirements from you to them. This is not a small item for payment handling in my opinion. – vidarlo Jan 27 '19 at 14:56
  • You really haven't answered my questions at all. Why do you want to use encryption in this way? What is *this* scheme trying to accomplish? why use *this* control? I can see why you might want a step to isolate the client from the processor (but this is a massive risk all on its own), but what is this *encryption* meant to do? And yes, you trigger the generation of a key, you pass a key to the client, then you pass the key back to the server who then uses another key to decrypt. Why not just pass the symmetric key once to the client? – schroeder Jan 27 '19 at 15:13
  • 1
    https://security.stackexchange.com/questions/37879/storing-credit-card-data-on-behalf-of-customers-and-transfer-the-data-later If you are open to different strategies, I would consider some of these approaches. – they Jan 27 '19 at 15:22
  • @Nat thanks again, good points. Are there sound strategies for dealing with active attackers should they gain access? May be naive but I just don't feel comfortable sending naked data over the wire, tls or not. I suppose sending the public key back which allows the data to be decrypted is very similar to being naked but at least the data is only ever exposed in the function's closure. – irth Jan 27 '19 at 15:23
  • @schroeder to build a little more on the reply to Nat and address the open questions better, this encryption is an added layer because, as you point out, i'm assuming extra risk by isolating the processor so want to add extra security via the asymmetric key-pair strategy. I may put additional checks within the closure as need or opportunity arises. It sounds like the extra work is superfluous in your opinion or is it possible that the transaction will be less secure because of? – irth Jan 27 '19 at 15:27
  • 1
    @they, that question is very much along the same lines. like the OP there, i'm not keeping, charging, or able to access the customer's data -- that's still happening through the processor PCI, who tokenizes the data and keeps customer records for the initial charge and further transactions. Thanks for the link! – irth Jan 27 '19 at 15:33
  • 2
    You're dancing your way toward [asymmetric key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange). It's great against passive attackers, but it suffers from active attackers being able to insert themselves into the dialog because neither party knows anything about the other side other than what they get over an insecure line. To resolve this, modern websites use certificates that have public-keys stored in them, denying an active attacker the chance to substitute in their own public-key during communication- unless they're so proactive as to compromise certificates. – Nat Jan 27 '19 at 15:34
  • 1
    Usually in asymmetric key exchange, both parties try to agree on symmetric keys for further, secure communication. You're skipping the symmetric key part because you only want to send sensitive information in one direction once, so your scheme's a much shorter variant. Still, it seems to enjoy some of the same strengths and suffer from some of the same weaknesses, so reading up about key exchange would probably be useful. – Nat Jan 27 '19 at 15:41
  • This would be a lot easier on you if the client is using an app you distribute rather than a website. If they're using an app, you can basically embed a server-controlled public key in it, which would basically give you the same thing as a website-certificate, but without some of the trust-and-distribution problems. However, if the client is using a website, then it's more dangerous because attackers can not only attack the messages, but they can attack the code itself. The only recourse there is to rely on SSL/TLS, which is fairly reasonable in consumer-level products. – Nat Jan 27 '19 at 15:45
  • 1
    (Practically speaking, you'll probably want to listen to the folks recommending the vendor's solutions for liability reasons. This is a neat learning project, but too much can go wrong to be doing this professionally right now.) – Nat Jan 27 '19 at 15:47
  • @Nat i hear and understand. Very helpful and well advised. Pretty sure i'm still doing this by the processors book using their API strategy appropriately and I don't think I'll ever see or have access to card data so should still give them most all of the liability. – irth Jan 27 '19 at 15:58
  • Very appreciate for everyone's input. I'll consider it all in-depth. – irth Jan 27 '19 at 15:59
  • Ah one last bit that might make more sense why I feel the effort is warranted, but is quite out of scope. A later stage of this project involves decentralizing it to be served via p2p torrents and using compute power of current users as a server and database instead of my centralized stack rn. – irth Jan 27 '19 at 16:13

1 Answers1

6

On first inspection, I don't see anything egregiously wrong with your scheme, however I question why it's necessary and whether it's actually adding any value.

To summarize @schroeder and @Nat's comments: you are spending a lot of effort to essentially re-invent TLS session encryption from the ground up, and then wrap it inside an existing TLS (HTTPS) session. This seems a little pointless. From the way I read your question, your goal is to have secure data transmission from the user to your server. That's exactly what TLS (HTTPS) was invented for!

If your reason for inventing this scheme is that you don't trust user data to be flowing unencrypted between your TLS endpoint (front-end load-balancer?) and your database, then perhaps your effort would be better spent segregating and hardening your production network.

The usual "Don't Roll Your Own" warnings apply.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • This is a good answer. So the process is secure with nothing more to address, and if anything, it's a TLS-like strategy (wrapped in a TLS-actually strategy). Thanks for summarizing the thread and dropping an answer! – irth Jan 27 '19 at 16:14
  • 2
    @irth You're welcome. If you are going to use this scheme in production, then please have a read through the [Don't Roll Your Own](https://security.stackexchange.com/q/18197/61443) thread; unless you've had your custom encryption protocol professionally reviewed / pen-tested, then assume it is easily breakable and don't use it _instead_ of traditional security mechanisms. Crypto is hard to get right, and even subtle bugs can render it completely broken, even for experts. – Mike Ounsworth Jan 27 '19 at 16:19
  • :) was just reading through.. checked off the first few. aye, this is an addition to not in lieu of. getting a pen test when it's ready too. sound advice for me and any working with security at all. – irth Jan 27 '19 at 16:20