Is there any plan to implement symmetric algorithm like AES-GCM/CCM for TLS

[sahilnxp]

Is there any plan to implement symmetric algorithm like AES-GCM/CCM for TLS ?

CC: @kshitizvars

[simo5]

I have started writing some code that could add it a while ago, but in OpenSSL there is no way to manage symmetric keys like for EVP_PKEY. See openssl/openssl#25908 for the necessary pre-requisite work for this to be a top tier feature in a future OpenSSL release.

That said, if you are ok exposing the session keys to OpenSSL and have it shim them back and forth we could allow usage of AES via session keys, I have a branch with some initial work I did a while ago here

Far from complete or even working/compiling, I stopped in the middle when I realized I'd have to do a lot of work to import keys, cache them in the session and then recognize them and reuse or re-create in session as needed. Felt a little bit wasteful given all the time the keys are exposed in buffers anyway.

There is no way for me to keep the key in the module and return any kind of handle. One hack way would be to return a "handle" instead of the real key in the key buffer, but that would be extremely dangerous as openssl could decide to use that "key" to perform actual cryptographic operations outside the module and potentially end up exposing sensitive data unless the handle is guaranteed to be as random as an actual key ... in which case you "only" risk to permanently lose data if it turns out that handle was used as a key to encrypt information for long term storage.

So all in all until EVP_SKEY is available it is a bit non-sensical to do symmetric operations in the token, unless what you are implementing is a completely new cipher that OpenSSL does not already have code for.

Note:
It may be possible to restrict the fake handle hack exclusively to the TLS case by allowing it only on the output of the TLS-PRFs or the HKDF when used explicitly for TLS-1.3, in the case we could generate fully random handles to return in the key buffers, and the worst that can happen is that the TLS channel breaks down if OpenSSL decided to use that session key directly instead of through the token. This would not be as dangerous as allowing general usage like this.
If this is something you may be after, we can discuss here whether it is worth doing.

[t-j-h]

One approach that can be taken (and has in various other circumstances) is to use the fact that the pointers are of course unique values in themselves and if you allocate memory and do not free it then it is a fixed value that does not change. You allocate a set of pointers that if passed in as a key represent key handle references. The key bytes reference makes it down into the provider layer and you test it against the allocated set of pointers that represent keys.

At the location those pointers reference you keep the first keylength block set to zeros or some other fixed pattern so it is easy to track when it escapes. You can also use the approach of marking the pointer area as uninitialised data to test that there isn't any copying of keys being done through the various layers.

This sort of approach was always in "vendor" code and not in the main stream openssl implementation logic - but the strategy is an option that would be workable and not depend on when EVP_SKEY lands and applications change to use EVP_SKEY (and it is the second one that is the critical item).

[beldmit]

Well, if we are looking for sophisticated workarounds, we already can provide all parameters to get the PKCS11 key handle in the array of params, and I can make it work (in a provider-specific manner), and it is simpler than your solution - but the EVP_SKEY approach is universal

[sahilnxp]

Thanks @simo5 @t-j-h @beldmit for insight on this

We are working on offloading all crypto operations involved in TLS connection to HSM.

All keys/secrets will be kept in HSM and will never come out of it, only Handles to these secret will come out.

Yeah, we tried passing the handle of shared secret we get after ECDH operation from pkcs#11 token to openssl and we get the same handle in subsequent HKDF operation in provide, but this shared secret is being saved as a session object and will not be available when we try to use it in HKDF operation, @Simo please correct me if I am wrong.(I know that was not the point you had considered since we are giving actual data to openssl as per current implementation). But if we want to work with handles we need to think about this design too.

It may be possible to restrict the fake handle hack exclusively to the TLS case by allowing it only on the output of the TLS-PRFs or the HKDF when used explicitly for TLS-1.3, in the case we could generate fully random handles to return in the key buffers, and the worst that can happen is that the TLS channel breaks down if OpenSSL decided to use that session key directly instead of through the token. This would not be as dangerous as allowing general usage like this.
If this is something you may be after, we can discuss here whether it is worth doing.

Yes @simo5 , I think we can work with this kind of solution.

Also this thing can only be done when all the operations are forced to pkcs-provider/HSM.

One query I have in my mind is that since there is an introduction of a lot of HSM, which will just give the handles of keys/secret out, is there any discussion going on in OpenSSL to expect handles instead of the actual data ?

FYI: I am on vacation this week, my responses might be delayed during this time, Thanks.

[simo5]

@sahilnxp 1. please read the link at the OpenSSL PR I gave you, that is the OPenSSL solution.

@t-j-h sorry but there is absolutely no guarantee a client will keep any pointer around, besides the result of a ECDH operation is stored in client provider pointers, and we need to fill these buffers with something anyway. Pointers are a hack that won't work in most cases for many reasons.

@beldmit sorry but there are currently no params to return from an ECDH operation, we'll need a ECDH operation that returns an EVP_SKEY, and that will have to be wrapped by libcrypto after the provider returns an opaque key handler.

In general all Key Exchange, Key Encapsulation and Key Derivation functions that currently return a bunch of bytes will have to grow counterparts that return an EVP_SKEY to the application (internall the provider retunrns an opaque key pointer that libcrypto wraps in an EVP_SKEY.

[beldmit]

Yes, fair point about returning from ECDH

[t-j-h]

I think you misunderstand the approach. There are two separate contexts - key bytes coming into the provider and key bytes coming out of a provider. A malloc generates a unique pointer value that is never reused for the life of the application if a free is never called. You provide a routine that takes key identifying information and returns a pointer and a routine that takes one of these "special" pointers and returned returns a handle. It won't work for every application if they are written copying bytes around between different buffers but it will make it across the provider boundary in and out and is detectable and usable in applications.

So it doesn't work for everything - but then nothing will without changes - and with EVP_SKEY is also requires changes to all providers and all applications to be able to work this way as well.

[simo5]

Sorry Tim, but I think I understand exactly what you were proposing, and while it is a hack that can "work" in some cases, I am not going to provide this hack in pkcs11-provider, as the failure mode is just bizarre and nobody will be able to figure out why stuff seem to work in some case and not work (or rather potentially catastrophically fail) in other cases, potentially even within the same application.

Additionally, as I said, we need to return actual data in these buffers, that data is interpreted as a key by applications and could be used as a key outside of the pkcs11-provider. It is unacceptable to me to offer software that returns random bytes as a key that may end up being used to encrypt data for long term storage and then gets lost.