Decrypting a value (encrypted by means of AES_256_GCM_SHA_384)

[pawel-tutka]

Hello,

I wanted to ask you guys about Apigee decrypting a formparam/queryparam/header which has been encrypted using AES_256_GCM_384. The length of the value will be maximum 13 chars. The expected traffic load will be quite big, to say the least. The communication protocol used is HTTPS. We're using Apigee-On-Premises.

Is it feasible that such an operation could be done in Apigee? If so, how is it going to affect the length of the flow? And the load on the platform itself?

I and my colleague think that such an operation should not be done in Apigee, but somewhere else in the whole flow (in front of/next to Apigee layer?) by means of a dedicated nodejs/Java/whatever app/proxy/something else.

Has anyone encountered such a "specific" requirement? How did you proceed with that?

[dchiesa1 · Accepted solution]

I'm not familiar with a cipher named "AES_256_GCM_384"

For AES, the term "AES_256_GCM" refers to AES encryption with a 256 bit key, using Galois Counter Mode. That is something you can do in Apigee Edge.

There's an additional "SHA-384" in there, and I'm not sure what you'd do with that.

---

It sounds to me that you may be referring to the back-half of a TLS cipher suite, and yes, you can configure Apigee to handle TLS ciphers. See here: https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference

That deals with crypto on the transport layer. You don't configure the "Proxy" to do that, but rather the virtual host.

---

If you are talking about crypto at the Messaging or Application layer (in the HTTP message payload), then I think you should examine the AES crypto callout to see if it satisfies. It does AES with 256-bit keys in mode=GCM.

https://github.com/DinoChiesa/ApigeeEdge-CustomPolicy-AesCrypto

And then if you need a SHA-384 hash of something,

https://github.com/DinoChiesa/ApigeeEdge-Java-Compute-Hash

I don't know what you mean by describing the expected traffic load as "quite high". That is a relative term of course.

AES encryption does incur a CPU cost, but it's a very efficient crypto.

[pawel-tutka]

Hi Dino, thanks for the comment. Of course, I meant AES_256_GCM_SHA_384 - just forgot about the "SHA" part.

I thought this could be feasible, but I'm wondering about how it's going to affect the platform, since, as you wrote, the AES encryption incurs a CPU cost. Hence my suggestion that it perhaps be done elsewhere in the whole flow.

Then I thought I could implement that feature in node-js, since it can also be done this way, but, like I've written earlier, the traffic can be quite high (talking about a few hundred thousand clients - don't know yet if the requirements speak of daily/weekly/some other period of time; that's still quite a fresh requirement). Hence my wondering about the CPU cost and the effect it's going to have on Apigee-On-Premises.

Now, tackling one topic at a time:

1) Virtual hosts:

I understand that such a cipher could be added to the virtual host, but does it mean that the Edge Routers would have to be restarted? Or does it pertain only to the references when it comes to configuring keystores and truststores? If the latter is the case, then it would actually be good, but I still do not know, if this solution should be implemented on this layer.

2) Application layer:

I think this is going to be just the case - implementing that logic on this layer. Like I wrote above, initially I was thinking about node-js, but now I think that a Java callout would be a better solution for this kind of operation.

All in all, the case is that, once Apigee Edge receives the AES256-encrypted value (be it in queryparam, formparam or header), it would have to decrypt and then send it on to the backend. Still, I am also wondering about the hash part, but that will probably clarify once the requirements become "clearer". Do you think that, with the possible load of a few hundred thousand daily clients (assuming 100,000 at the moment), this feature could perform well? Your thoughts on this would really be appreciated.

[dchiesa1]

Yes- there's no way to know how it will perform unless you test it.

Of course it depends on how large the payloads are, how fast the upstreams are, and how much concurrency there is.

You said 100,000 clients per day. Would that be 1 daily request per client? (100,000 requests per day) Or 1 request per minute per client? (1440 * 100,000 per day) or something in between?

I think you cannot simply choose to use the cipher in the vhost versus in the Api Proxy. I mean they are separate layers in the OSI model. Completely different. Sure, similar encryption algorithms, but totally different implementations.

If the plan is that the client app is sending the encrypted data in the http payload, then the only option is to do the decryption in the application layer.

You can test this yourself; as soon as you have the ability to generate the desired client load, and provide the necessary upstream capacity.

The Java callout is the way to go (not Nodejs, it's out of process).

Try it and see. In general I/O is expensive in a distributed system. Sure, crypto consumes CPU but it doesn't result in waiting. I would not assume that AES in a Java callout will be prohibitively expensive.

[pawel-tutka]

Yes, I still do remember the OSI model and I still remember how it works 🙂

In the end, when I think about it, the payload is the place where this data will be sent, so I'm guessing the Java implementation in the application layer is the place to go.

Talking about Nodejs, I was planning on initially establishing a separate endpoint which would do the work, but then I realized the payload won't be sent back to the app itself. Hence, the whole idea in my head fell through.

I guess some of the clients are not going to login at all during the day, while others might perform that operation a few times a day. I do not have any solid data to present. But, even taking into consideration, let's assume, 800,000 clients per day, do you think that a Java AES_Crypto callout could work effectively and not slow down the whole platform? I mean, would it bottleneck the platform itself?

[dchiesa1]

Ah, ok great!

800,000 requests per day is about 10 per second, on average. That’s not very much. Even if you have peaks of 10x that, it would be 100 requests per second. I don’t expect that to be a problem.

Again it depends on the payload size. If you have a 1kb ciphertext, no problem. If you have a 10mb ciphertext, that will require more CPU.

To me, it sounds completely feasible for payloads of reasonable size. Try it!

[pawel-tutka]

Actually, I had a meeting with a few systems architects today, and they decided that such logic should not be implemented in Apigee. It will be done somewhere else in the flow. I presented the ideas given by you, but they didn't sound convinced. As they have said, "Apigee performs a different role in our org", but what this role is - I'm not entirely sure. Oh well...

Still, you have given me motivation to actually try that out on my own. The load won't definitely be somewhere near the number I have provided, but generating numerous scripted requests might actually test out the concept of decrypting AES256-encrypted payloads (or parts of the body).

I will mark your initial answer here as the answer to my question.

Many thanks for giving me something to ponder about! 🙂