While working at a biotech company, we aim to advance ML & AI Algorithms to enable, for instance, brain lesion segmentation to be executed on the hospital/clinic location where patient data resides, so it’s processed in a secure manner. This, in essence, is guaranteed by federated learning mechanisms, which we’ve adopted in quite a few real-world hospital settings. Nonetheless, when an algorithm is already regarded as an organization asset, we also need implies that protect not only sensitive data, but additionally secure algorithms in a heterogeneous federated environment.
Most algorithms are assumed to be encapsulated inside docker-compatible containers, allowing them to make use of different libraries and runtimes independently. It’s assumed that there’s a third party IT administrator who will aim to secure patients’ data and lock the deployment environment, making it inaccessible for algorithm providers. This angle describes different mechanisms intended to package and protect containerized workloads against theft of mental property by a neighborhood system administrator.
To make sure a comprehensive approach, we’ll address protection measures across three critical layers:
- Algorithm code protection: Measures to secure algorithm code, stopping unauthorized access or reverse engineering.
- Runtime environment: Evaluates risks of administrators accessing confidential data inside a containerized system.
- Deployment environment: Infrastructure safeguards against unauthorized system administrator access.
Methodology
After evaluation of risks, we’ve identified two protection measures categories:
- Mental property theft and unauthorized distribution: stopping administrator users from accessing, copying, executing the algorithm.
- Reverse engineering risk reduction: blocking administrator users from analyzing code to uncover and claim ownership.
While understanding the subjectivity of this assessment, we’ve considered each qualitative and quantitative characteristics of all mechanisms.
Qualitative assessment
Categories mentioned were considered when choosing suitable solution and are considered in summary:
- Hardware dependency: potential lock-in and scalability challenges in federated systems.
- Software dependency: reflects maturity and long-term stability
- Hardware and Software dependency: measures setup complexity, deployment and maintenance effort
- Cloud dependency: risks of lock-in with a single cloud hypervisor
- Hospital environment: evaluates technology maturity and requirements heterogeneous hardware setups.
- Cost: covers for dedicated hardware, implementation and maintenance
Quantitative assessment
Subjective risk reduction quantitative assessment description:
Considering the above methodology and assessment criteria, we got here up with an inventory of mechanisms which have the potential to ensure the target.
Confidential containers
Confidential Containers (CoCo) is an emerging CNCF technology that goals to deliver confidential runtime environments that can run CPU and GPU workloads while protecting the algorithm code and data from the hosting company.
CoCo supports multiple TEE, including Intel TDX/SGX and AMD SEV hardware technologies, including extensions of NVidia GPU operators, that use hardware-backed protection of code and data during its execution, stopping scenarios wherein a determined and skillful local administrator uses a neighborhood debugger to dump the contents of the container memory and has access to each the algorithm and data being processed.
Trust is built using cryptographic attestation of runtime environment and code that’s executed. It makes sure the code is just not tempered with nor read by distant admin.
This appears to be an ideal fit for our problem, because the distant data site admin wouldn’t give you the option to access the algorithm code. Unfortunately, the present state of the CoCo software stack, despite continuous efforts, still suffers from security gaps that enable the malicious administrators to issue attestation for themselves and effectively bypass all the opposite protection mechanisms, rendering all of them effectively useless. Every time the technology gets closer to practical production readiness, a brand new fundamental security issue is discovered that should be addressed. It’s value noting that this community is fairly transparent in communicating gaps.
The usually and rightfully recognized additional complexity introduced by TEEs and CoCo (specialized hardware, configuration burden, runtime overhead because of encryption) can be justifiable if the technology delivered on its promise of code protection. While TEE appears to be well adopted, CoCo is close but not there yet and based on our experiences the horizon keeps on moving, as latest fundamental vulnerabilities are discovered and should be addressed.
In other words, if we had production-ready CoCo, it could have been an answer to our problem.
Host-based container image encryption at rest (protection at rest and in transit)
This strategy relies on end-to-end protection of container images containing the algorithm.
It protects the source code of the algorithm at rest and in transit but doesn’t protect it at runtime, because the container must be decrypted prior to the execution.
The malicious administrator at the location has direct or indirect access to the decryption key, so he can read container contents just after it’s decrypted for the execution time.
One other attack scenario is to connect a debugger to the running container image.
So host-based container image encryption at rest makes it harder to steal the algorithm from a storage device and in transit because of encryption, but moderately expert administrators can decrypt and expose the algorithm.
In our opinion, the increased practical effort of decrypting the algorithm (time, effort, skillset, infrastructure) from the container by the administrator who has access to the decryption key is just too low to be regarded as a legitimate algorithm protection mechanism.
Prebaked custom virtual machine
On this scenario the algorithm owner is delivering an encrypted virtual machine.
The important thing could be added at boot time from the keyboard by another person than admin (required at each reboot), from external storage (USB Key, very vulnerable, as anyone with physical access can attach the important thing storage), or using a distant SSH session (using Dropbear as an example) without allowing local admin to unlock the bootloader and disk.
Effective and established technologies corresponding to LUKS could be used to totally encrypt local VM filesystems including bootloader.
Nonetheless, even when the distant key’s provided using a boot-level tiny SSH session by someone apart from a malicious admin, the runtime is exposed to a hypervisor-level debugger attack, as after boot, the VM memory is decrypted and could be scanned for code and data.
Still, this solution, especially with remotely provided keys by the algorithm owner, provides significantly increased algorithm code protection in comparison with encrypted containers because an attack requires more skills and determination than simply decrypting the container image using a decryption key.
To stop memory dump evaluation, we considered deploying a prebaked host machine with ssh possessed keys at boot time, this removes any hypervisor level access to memory. As a side note, there are methods to freeze physical memory modules to delay loss of knowledge.
Distroless container images
Distroless container images are reducing the variety of layers and components to a minimum required to run the algorithm.
The attack surface is greatly reduced, as there are fewer components vulnerable to vulnerabilities and known attacks. Also they are lighter when it comes to storage, network transmission, and latency.
Nonetheless, despite these improvements, the algorithm code is just not protected in any respect.
Distroless containers are really useful as safer containers but not the containers that protect the algorithm, because the algorithm is there, container image could be easily mounted and algorithm could be stolen with no significant effort.
Being distroless doesn’t address our goal of protecting the algorithm code.
Compiled algorithm
Most machine learning algorithms are written in Python. This interpreted language makes it very easy not only to execute the algorithm code on other machines and in other environments but additionally to access source code and give you the option to switch the algorithm.
The potential scenario even enables the party that steals the algorithm code to switch it, let’s say 30% or more of the source code, and claim it’s now not the unique algorithm, and will even make a legal motion much harder to supply evidence of mental property infringement.
Compiled languages, corresponding to C, C++, Rust, when combined with strong compiler optimization (-O3 within the case of C, linker-time optimizations), make the source code not only unavailable as such, but additionally much harder to reverse engineer source code.
Compiler optimizations introduce significant control flow changes, mathematical operations substitutions, function inlining, code restructuring, and difficult stack tracing.
This makes it much harder to reverse engineer the code, making it a practically infeasible option in some scenarios, thus it may well be regarded as a solution to increase the associated fee of reverse engineering attack by orders of magnitude in comparison with plain Python code.
There’s an increased complexity and skill gap, as a lot of the algorithms are written in Python and would need to be converted to C, C++ or Rust.
This selection does increase the associated fee of further development of the algorithm and even modifying it to make a claim of its ownership but it surely doesn’t prevent the algorithm from being executed outside of the agreed contractual scope.
Code obfuscation
The established technique of constructing the code much less readable, harder to know and develop further could be used to make algorithm evolutions much harder.
Unfortunately, it doesn’t prevent the algorithm from being executed outside of contractual scope.
Also, the de-obfuscation technologies are getting a lot better, due to advanced language models, lowering the sensible effectiveness of code obfuscation.
Code obfuscation does increase the sensible cost of algorithm reverse engineering, so it’s value considering as an option combined with other options (as an example, with compiled code and custom VMs).
Homomorphic Encryption as code protection mechanism
Homomorphic Encryption (HE) is a promised technology aimed toward protecting the info, very interesting from secure aggregation strategies of partial ends in Federated Learning and analytics scenarios.
The aggregation party (with limited trust) can only process encrypted data and perform encrypted aggregations, then it may well decrypt aggregated results without having the ability to decrypt any individual data.
Practical applications of HE are limited because of its complexity, performance hits, limited variety of supported operations, there’s observable progress (including GPU acceleration for HE) but still it’s a distinct segment and emerging data protection technique.
From an algorithm protection goal perspective, HE is just not designed, nor could be made to guard the algorithm. So it’s not an algorithm protection mechanism in any respect.
Conclusions
In essence, we described and assessed strategies and technologies to guard algorithm IP and sensitive data within the context of deploying Medical Algorithms and running them in potentially untrusted environments, corresponding to hospitals.
What’s visible, probably the most promising technologies are those who provide a level of hardware isolation. Nonetheless those make an algorithm provider completely depending on the runtime it should be deployed. While compilation and obfuscation don’t mitigate completely the danger of mental property theft, especially even basic LLM appear to be helpful, those methods, especially when combined, make algorithms very difficult, thus expensive, to make use of and modify the code. Which might already provide a level of security.
Prebaked host/virtual machines are probably the most common and adopted methods, prolonged with features like full disk encryption with keys acquired during boot via SSH, which could make it fairly difficult for local admin to access any data. Nonetheless, especially pre-baked machines could cause certain compliance concerns on the hospital, and this must be assessed prior to establishing a federated network.
Key Hardware and Software vendors(Intel, AMD, NVIDIA, Microsoft, RedHat) recognized significant demand and proceed to evolve, which supplies a promise that training IP-protected algorithms in a federated manner, without disclosing patients’ data, will soon be nearby. Nonetheless, hardware-supported methods are very sensitive to hospital internal infrastructure, which by nature is kind of heterogeneous. Subsequently, containerisation provides some promise of portability. Considering this, Confidential Containers technology appears to be a really tempting promise provided by collaborators, while it’s still not fullyproduction-readyy.
Definitely combining above mechanisms, code, runtime and infrastructure environment supplemented with proper legal framework decrease residual risks, nonetheless no solution provides absolute protection particularly against determined adversaries with privileged access – the combined effect of those measures creates substantial barriers to mental property theft.
We deeply appreciate and value feedback from the community helping to further steer future efforts to develop sustainable, secure and effective methods for accelerating AI development and deployment. Together, we are able to tackle these challenges and achieve groundbreaking progress, ensuring robust security and compliance in various contexts.
Link & Resources
Intel Confidential Containers Guide
Nvidia blog describing integration with CoCo Confidential Containers Github & Kata Agent Policies
Industrial Vendors: Edgeless systems contrast, Redhat & Azure
Distant Unlock of LUKS encrypted disk
An ideal match to raise privacy-enhancing healthcare analytics
Differential Privacy and Federated Learning for Medical Data
