ECC Encryption and Decryption in Apigee

[wrietetorajeshk]

Dear @dchiesa1 , @anil 

There is a requirement where the consumer is encrypting end-user credentials using the ECC (Elliptic Curve Cryptography) algorithm, and we need to decrypt and propagate the credentials to the target application. I have not found any suitable apigee libraries available for ECC encryption/decryption in this context.

Could you kindly advise on the best approach to implement encryption/decryption for this purpose? Specifically, should we utilize JavaScript or a Java callout for this implementation? Also, please let me know if there are any relevant Apigee libraries or resources that could assist with this task.

[hartmann]

Hello,

You are correct in that there is not an Apigee-native policy/definition to support ECC encryption/decryption. As a result, I would recommend something as the following:

• Use an Apigee KVM to store the pertinent key/value pair referencing all certificates needed as a part of this decryption logic (most likely just your private key as a part of this initial use case)
• In code (Java/JavaScript, preference should really depend on what your team is most comfortable with but I would lean towards Java) you can read in the private key/value pair and decrypt/propagate the credentials accordingly. I know that Java's Bouncy Castle library can easily achieve this use case, and there are a ton of examples online as per how to decrypt/utilize the ECC pertinent methods as needed

Let me know if this helps - thanks!

[wrietetorajeshk]

Thank you for your response. What would be the best option from a performance perspective?

[dchiesa1]

a requirement where the consumer is encrypting end-user credentials using the ECC (Elliptic Curve Cryptography) algorithm, and we need to decrypt and propagate the credentials to the target application.

Can you elaborate on that requirement? or provide more details? What curve is required here? Is an encrypted JWT suitable as an "envelope" for the credentials? Is there a publicly-accessible document that describes this requirement? I have seen open banking standards that require SIGNED JWT for exchanging information, but I am not aware of standards that require ENCRYPTED JWT.

How is the client app encrypting the credentials? Do you have sample code for that? Who owns the client? Is that a 1st party client, or someone else is implementing it?

Why is it necessary to transmit credentials anyway? As you are aware, transmitting long-lived secrets like user credentials is generally considered to be bad practice. What problem are you REALLY trying to solve?

[wrietetorajeshk]

Thank you for your response. please find below requirement details.

Requirement Details

1. Encryption Context:

   • The consumer (APP/Web Application) encrypts end-user credentials using the Elliptic Curve Cryptography (ECC) algorithm.
   • Encryption is performed with the ECC public key provided by existing API gateway.Please note we don't have client encryption code with us.

2. Decryption & Propagation:

   • APi Gateway acts as an authentication broker:
     • Decrypts the credentials using its ECC private key.
     • Pass to target application to Authenticates the user.
     • Generates an access token post successful authentication.

3. Single-Use Operation:

   • This process is invoked only once per session/request, aligning with minimal data exposure principles.

4. Client Cybersecurity Guidelines:

   • App/web applications must encrypt sensitive data using ECC before invoking the API.
5. I am curious if there are any existing Java libraries in the community that can fulfill the above requirement.

[dchiesa1]

It sounds to me that this requirement is referring to TRANSPORT layer encryption.  

TLS (transport layer security) does this for you.  Apps get automatic encryption at that layer by using TLS, and you can enforce that the TLS layer uses ECC for your API Endpoints.  (Specifically, that it uses ECDHE for key exchange, which is a way to apply elliptic curve encryption to perform a secure key exchange).   Using the Google Cloud Load Balancer (which you will use for Apigee X), you can specify MODERN or RESTRICTED SSL Policy (See here: https://cloud.google.com/load-balancing/docs/ssl-policies-concepts) and you will get ECDHE for your TLS .

With TLS, the client side automatically encrypts data, and the receiving side (the load balancer at Google) decrypts, just before handing the data to your Apigee proxy. 

When you configure your SSL Policy to use ECDHE, then the client side is compelled to use that cipher suite based on ECC for key exchange, and you will automatically be in compliance with that requirement. The  load balancer will insist that clients use that encryption, and will reject any connection attempt by a client that does not use that encryption during the TLS handshake. 

ECDHE stands for Elliptic Curve Diffie Hellman Ephemeral and is a key exchange mechanism based on elliptic curves.  To be clear, TLS is an example of a hybrid crypto system, that uses both public/private key encryption as well as symmetric encryption. It will use ECC (the public/private part) for key exchange, and then use AES for the encryption of the data using that agreed-upon secret key.  This is the industry standard. 

So I would say: configure your load balancer correctly, and you're done. But you will want to check with the party that specified these requirements to be sure. 

If you are using Apigee hybrid, then .... you need to configure the correct cipher suite and TLS keys, on whatever is the ingress point for your hybrid APIs.  If you are using Apigee Edge, you cannot comply. Edge does not support ECDHE keys, so you cannot comply with this requirement, at this time, if you use Apigee Edge. 

[wrietetorajeshk]

Thanks for your prompt response,  we are using Apigee edge platform. This is an existing implementation on other API Gateway and it uses the one way SSL(RSA X.509 certificate ) at transport layer and on top this  encryption at the application layer. And we are trying to implement the same at Apigee edge platform.

[dchiesa1 · Accepted solution]

ok then, if you need ECC at the app layer, then:

• you can use encrypted JWT. Apigee has a VerifyJWT policy that can decrypt a JWT that has been encrypted with ECDH-ES, which is ECC. (Like TLS, encrypted JWT uses a hybrid  crypto system, where it uses asymmetric keys (in this case, elliptic curve keys) to establish a shared secret, to apply AES (symmetric) encryption).  The client side would need to produce an encrypted JWT, using the public key provided by the Apigee endpoint.  There are lots of libraries out there that clients could use. Web clients can use the subtle crypto library that is built-in to web browsers.

• Option2: build it yourself. I don't advise this. But you could design some sort of framework for producing your own crypto approach using ECC. The app client would have to have the encrypt implementation, and you would need to build a decrypt custom policy for use in Apigee. You would use Java for this. JavaScript would be inappropriate.

  The reason i do not advise this is, it's hard to get cryptography right. This is captured in the well-trod aphorism: don't roll your own crypto.  You might think the statement "don't roll your own crypto" implies "don't try to invent an encryption algorithm."  But it's much more expansive than that.  Even if you select a known-secure algorithm, and if you use strong keys, if you don't manage keys correctly, or if you don't use the right padding, or the right nonce, or, or, or,... any of a large number of things can lead to a security hole in a system that is intended to provide secrecy.  Something like JWT has been vetted and reviewed and is a known good approach or "framework" for applying ECC. If you make up your own, you may not get it right.

I'd advise using encrypted JWT. It's much easier and the eJWT standard is already vetted.

I believe the support for Encrypted JWT is included in Edge, despite the lack of documentation for this. 

Also, you should upgrade to Apigee X.