|
I have explored use cases for trusted execution, Intel® SGX in specific, in several blog posts. This talks about running SQLite within Intel® SGX's secure enclave. And this, talks about running a cryptography library like Cryptlib within a secure enclave. And the internet is full of such examples. But, they are the more obvious use cases. There are varied non obvious and at times out of the box use cases that could greatly benefit from leveraging trusted execution. Patch management is one such area that may not seem like an obvious fit, yet stands to gain from leveraging trusted execution technologies.
On-the-fly patch management in specific, is neither that prevalent nor likely to be perceived as a good practice from conventional software management perspective. However, it does have its place. The following are just two of several examples that comes to mind -
Above mentioned use cases are nothing new. On-the-fly patching software is just for that reason. However, on-the-fly patching of binaries is still vulnerable. Not only are they more prone to stability issues themselves, if not implemented with extra care, they could create more problems than solve any. Even with meticulous implementation, they are still fragile by nature. Plus, unlike re-spun binaries, they don't necessarily secure the fix with a signed patch that is verified and loaded by the platform/OS loader, although they could give away the vulnerability they patch in a more obvious way. In other words, while on-the-fly patching patches vulnerabilities real time, it could potentially leave the system no less vulnerable! Techniques like hooking and patching used by existing on-the-fly patching technologies are now nearly old relics. Thus this type of patch management stands to be seen as outdated. By leveraging hardware virtualization and trusted execution, it can be brought forward to keep up with the fast phased technology landscape. And the entire process can be made more secure and far more obscure to prying eyes. It could redefine the way vulnerable binary codes are scanned, guarded and substituted in real time, and right when the vulnerable code is about to be executed - just-in-time and on-the-fly. Features provided by hardware virtualization can be leveraged towards scanning and guarding the vulnerable regions, in far more powerful ways than current ones. Trusted execution can be used not only towards obscuring which vulnerable region is replaced and with what, the entire process could also be driven using secure remote computation, software attestation and more. So, at several levels, combining hardware virtualization with trusted execution could make on-the-fly patch management exponentially more secure and powerful. While I consider further exploring this myself, I also wanted to invite others to this discussion. So, I thought I would share this insight and seek others' thoughts on this matter. I am especially keen on 0Patch's insight, as they appear to use the equivalency of on-the-fly patching. If they or anyone else would like to further discuss this, please use the comments below or reach out to info@kryptoguard.com.
0 Comments
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. In an earlier post I talked about in-memory data protection and how PCI-DSS could do a lot more to impose a specific requirement in this area. An RFE submitted earlier on the topic can be found here and a follow-up on that here.
We don't ignore end point protection because perimeter protection is in place. Same way we shouldn't ignore data in use protection because data at rest and data in transit protection is in place. One reason data in use protection is getting a short shrift is because of the lack of ubiquity in sophisticated technologies in this area. We might have reached a point where we may have crossed that chasm and entered a phase where the availability of such technology and its seamless adoption is within sight. Microsoft's unveiling of "Azure Confidential Computing" is one example as to us having entered that phase. More information on that by Mark Russinovich, CTO, Microsoft Azure, is here. If a cloud platform with all its complexities has adopted technologies towards data in use protection, there is no excuse for other platforms, environment and sectors giving this topic or the technologies pertaining to it a short shrift. I had talked about Intel® SGX, one such technology and its use here, here and here and a proof of concept of the technology at work is here. If you would like to further discuss this topic or need help adopting this technology towards protecting your business assets, feel free to reach us at info@kryptoguard.com or via the contact form here. A feasibility study of KryptoGuard™ brand leveraging Intel® SGX using SQLite
In the last post I mentioned I will take a scenario to explain how KryptoGuard™ brand leverages Intel® SGX to better protect sensitive data. This post is dedicated towards just that. As part of the feasibility study, I wanted to take a database application and provide it the security and benefit of running in the context of an Intel® SGX enclave. I chose a database software because, more often than not, that's were sensitive data find's its home. And within that, I chose SQLite for a proof of concept because, it makes for a perfect fit, as it is one of the light weight, low foot print open database that has withstood the test of time. The very nature of doing anything security centric dictates opting for the smallest possible attack surface. Intel® SGX provides that at hardware level by reducing the attack surface to CPU boundary. It makes sense for us to follow suite by doing the same at software level as well. And for that SQLite makes for a good candidate. To be able to store certain kinds of sensitive data, businesses are required to abide by relevant regulations. And encryption becomes a mandatory requirement in such cases. It so happens, Intel® SGX's in-built cryptography can be leveraged to enforce that requirement more easily. Leveraging it not only helps meet a need, it also helps make the process simpler. To that end I wanted to enlist Intel® SGX's FS API to demonstrate how easy it is to encrypt and secure a database and SQLite design was a seamless fit to demonstrate that as well. Intel® SGX provides PSW and SDK software to exercise its hardware feature. SQLite design made it easier for me to use both of their software in a mutually complimentary way to show the added security enjoyed by an SQLite database while storing, loading and processing sensitive data, all within an enclave, out of reach from any other layers of software, including higher privilege software! To state for clarity, I refer to SQLite software running within an enclave, powered by Intel® SGX, as trusted SQLite and otherwise as classic SQLite. It is important to note that the database created with trusted SQLite can only be reopened and processed by trusted SQLite. Thus it enjoys all the security provided by Intel® SGX. For example, that database cannot be opened in a hex editor to get to its content in obtuse ways because of it being encrypted (leveraging Intel® SGX in our case) along with other Intel® SGX features like sealing, as and when appropriate. Also, if a classic SQLite database were to be reopened in the same environment, it is susceptible to memory scrapping attacks. Where as, a trusted SQLite database, which can only be loaded within the same trusted environment is not susceptible to similar attacks. This is because, sensitive database data are earmarked as Intel® SGX resources when loaded by trusted SQLite. Hardware level access control checks are applied to such resources upon its access in memory. So, when a memory scrapper software tries to access it, hardware level access checks by Intel® SGX forbids such software from gaining access to the sensitive data irrespective of the privilege at which the scrapper runs, as it is not a code running within the expected enclave to pass those checks. As you might have inferred from the above, Intel® SGX not only protects data in-memory at hardware level, it also provides the added benefit of making data at rest protection simpler in this case! This should fairly explain why I chose SQLite to demonstrate the use of Intel® SGX in protecting sensitive data, which aligns with our KryptoGuard™ brand goals and the use cases we target. In our previous post I talked about leveraging Intel® SGX towards data loss prevention. In this post I will talk about the relevance of Intel® SGX to our KryptoGuard™ Brand.
KryptoGuard™ brand is currently focused on providing services towards enhancing data security, leveraging the latest technologies. This also sets the stage towards delivering products focused on data loss prevention. To that end, we have already covered some of the use cases KryptoGuard™ brand targets. We expect our potential clients/customers to handle sensitive data like payment card data, health information, personally identifiable information(PII), all of which are required to abide by varied regulations. In an earlier post we talked about how PCI-DSS is woefully inadequate in enforcing in-memory requirements for payment card data, which is a frequent target. Sensitive and/or confidential data could use more sophisticated technologies to better protect them. Intel® SGX makes for a perfect candidate to capitalize on to accomplish just that. Not only can sensitive data be earmarked as resources for secure access within Intel® SGX's enclave, access control checks to enforce that restriction is performed at hardware level thus forbidding compromised software at any other layer, including higher privilege software from accessing those resources. This helps protect sensitive data from infractions which target that data while it is being processed, a stage where it is most vulnerable because of lack of maturity in current protection systems to better handle this stage. To top it, Intel® SGX also provides relatively seamless and easy ways to encrypt sensitive data before it is stored on disk. Cryptography key maintenance which would otherwise be a hassle is alleviated by its in-built cryptography feature that could be leveraged towards protecting sensitive data at rest. As you might have realized by now, all of this is very conducive for our KryptoGuard™ targeted use cases ! In a future post, possibly next, I will take a scenario to better explain how we were able to use Intel® SGX towards better protecting sensitive data as it is being generated and processed. Leveraging Intel® SGX towards Data Loss Prevention
Data Loss Prevention software have a lot to gain from creatively and innovatively leveraging hardware technologies. Intel® SGX is one such technology in Intel's hardware enabled security product line. What is Intel® SGX? Intel® SGX provides a hardware assisted trusted execution environment, an enclave, within which select code and data can run in a secure way. It provides the smallest possible attack surface, the CPU boundary. Widely Covered Usecase: There has been much talk about leveraging Intel® SGX in secure remote computation wherein a remote entity, possibly in the cloud, establishes a trusted computing environment, in this case by leveraging Intel® SGX. It then establishes an identity for the trusted environment. Once that identity is attested, this remote entity becomes eligible to receive secrets from its owner. The provisioned secret is then ready for secure processing in the remote environment but within a trusted enclave. Intel® SGX for Data Loss Prevention: Because of currently prevalent cloud services, remote secure computation use case has gained significant focus, with Intel® itself possibly having designed several aspects of SGX with that in mind. This sole focus however, overlooks a wealth of creative ways in which the SGX CPU feature set extensions itself could be leveraged, DLP software being one such area. It's core feature, to earmark select code and data for execution in a hardened environment were access control checks enforced at hardware level prevents those earmarked resources from being accessed by other layers of software, however privileged it be, makes for a perfect fit for DLP software. Watch out for further discussion, proof of concept and more to demonstrate successful use of Intel® SGX towards DLP. PCI-DSS woefully inadequate when it comes to in-memory payment card data requirement!
What is common between how Target, Home Depot, Neiman Marcus, Michael's, TJ Maxx, Albertsons, SuperValu, Heartland Payment Systems and Viator got hacked? That is, other than the huge financial loss they all incurred? One thing - they all lost their payment card data by way of memory scraping attack irrespective of how the attacker might have initially gained access to their IT infrastructure. Memory scraping attack has been quite prevalent in the past several years especially in the payment industry. PCI-DSS is the organization that sets the standard for how payment card data must be handled. While it is rather specific in several different aspects and enforces specific requirements as to how payment card data must be stored on disk and handled while in-transit, requirements for handling the same data while in-memory is at best vague and woefully inadequate. Perhaps, proactively enforcing a specific set of requirements for in-memory payment card data as well would help prevent payment card related memory scraping attacks in future. With that in mind, we submitted a RFE to PCI-DSS requesting that they enforce specific requirements as to how in-memory payment card data is handled. For access to the RFE we submitted, please email info_at_kryptoguard_dot_com. |
AuthorFounder of KryptoGuard™ technology initiative, product and services. Archives
June 2020
Categories
All
|
RSS Feed