How many is one too many...

How many is one too many when it comes to migrating cryptography libraries to run within a hardware backed secure environment?

Following is a long pending post on the topic of running cryptography libraries within a secure environment.

There are quite a number of innovative ways to use Intel® SGX technology.  The low hanging fruits usually gets the traction right away, not only because they are easier to attain but also because it satisfies an immediate need.  At that level, porting classic libraries to work within a secure environment has received fair amount of attention.  I myself discussed the topic of migrating SQLite to Intel® SGX environment, along with a proof of concept.  A "SGX" keyword search alone, and within GitHub, returns several hundred results.  Areas like cryptography and database technologies get far more attention than the rest when it comes to migrating to a secure environment.  Former more so than the latter, within that.  And that is understandable, mainly because, the point in enlisting cryptography is somewhat, if not fully lost if security cannot be guaranteed in the process.  Thus cryptography makes for an ideal candidate for technologies like Intel® SGX to embrace, or more importantly, the other way around.

Then again, one might ask, how many is one too many when it comes to porting cryptography libraries or to be more specific, services that heavily enlist cryptography, to run within a secure environment like an Intel® SGX enclave?  Intel® itself has ported OpenSSL to work within an enclave environment.  Then there is WolfSSL, TaLos project, LibTomCrypt (source here), mbedTLS and more.  So, when I ventured into porting Cryptlib (commercial version here), a security toolkit that provides varied services in its area, to work within an Intel® SGX enclave, I had to ask - is it really necessary?  That is, to add support for yet another library, albeit with its own differentiating point, in comparison to the rest of its kind.  I won't distract the conversation by getting into why Cryptlib is different and who or why someone might chose that over the rest.  I would suggest looking into their website. 

That said, the question as to whether or not it is worth porting Cryptlib, yet another cryptography library or to be more specific in this case, a security toolkit with considerable amount of cryptography functionality, need addressing.  I believe the answer is, yes.  Any library with an active customer base is worth a consideration.  Because, to the customers of those libraries, it really comes down to whether security is important enough to switch to a tool that provides a more secure way to execute the much needed functionality or keep the same library for its differentiating benefits, over which it was chosen in the first place, but at the cost of better security.  By forcing the active customer base to have to chose between the two is constraining them one way or other and there is no need for it, as porting existing libraries to work within a secure enclave is not that hard!  Cryptlib perhaps being comparatively vast and more versatile in terms of the services it offers, might make porting a more involved task than most others.  Nevertheless, I believe it is certainly worth the effort.

I have ported Cryptlib to a point where it makes for a functional prototype, which acts as a proof of concept that could be turned production ready, if there should be enough interest among its users in the field.  If there are Cryptlib users and customers considering migrating to run the library within a secure enclave environment, powered by Intel® SGX technology, please feel free to reach out to info@kryptoguard.com for further information.