Text / Ziyi Lin, Cloud Native Confidential Computing SIG Maintainer
"How can I keep passwords in Java program memory safe?"
If you have had similar problems and found some incomplete but helpless answers on the Internet, it means that you are a stakeholder in Java program security issues.
The standard answer to this question is Java Confidential Computing Technology, which introduces Confidential Computing Technology into the Java world and brings a significant improvement to the security of Java programs. Based on this, the Cloud Native Confidential Computing SIG of the Dragon Lizard community has launched the specific implementation technology of Java confidential computing - Teaclave Java TEE SDK , hereinafter referred to as Teaclave Java. This technology has the following significant advantages:
-
All-scenario security . When the user has confidential computing hardware support, Teaclave Java can realize Java trusted computing with the highest security level ; when the user does not have relevant hardware, it degenerates into trusted computing at the security sandbox isolation level, which can also effectively protect the user's sensitive data and Security of the computing process.
-
Simple to develop and build . The pure Java programming model based on SPI, one-click construction, lowers the threshold of Java confidential computing development and construction to the bottom.
Teaclave Java has been verified in enterprise-level internal scenarios and is open sourced in the Apache community. The paper describing this technology was published on ICSE 2023 (https://conf.researchr.org/home/icse-2023), the top meeting of software engineering, by the Cloud Native Confidential Computing SIG of the Dragon Lizard Community, in cooperation with Shanghai Jiaotong University and Dalian University of Technology. And won the ACM SIGSOFT Outstanding Paper Award of this conference. This is the first time since 2020 that the Dragon Lizard Community Cloud Native Confidential Computing SIG, Shanghai Jiao Tong University, and Dalian University of Technology have won this honor.
01 The essence of the problem
The essence of this problem is how to safely use sensitive data in a risky runtime environment. When we decrypt the password at runtime, the password will exist in the memory in the form of plain text, that is, on the Java heap, as shown in the left half of Figure 1. If the system is attacked, such as the notorious log4j vulnerability attack in 2021, the contents of the Java heap can be stolen. Even if it is not attacked, it is possible to actively leak sensitive information when performing a heap dump for performance diagnosis. So exposing security-sensitive information such as passwords to common operating environments is highly risky .
(Schematic illustration of simple Java password protection in Figure 1)
One way of protection is to shorten the storage time of plaintext passwords in memory as much as possible, so as to shorten the time window for exposure of sensitive information . As shown in the right half of Figure 1, after the password is used, it will be destroyed from the memory in time, which will be more secure than before. Because the password is text information, it will be saved with the string class java.lang.String. Java's String is an immutable type, and the content cannot be changed after creation, so there is no API that can reset the content. To destroy the password, the only way to erase the password content from the Java heap is to clear the content of the array storing the character content inside the String class through reflection. It is useless to directly set the password string to null, which only sets the pointer of the String variable to null, and has no effect on the password data on the Java heap. cleared. Another way is to store the password in a char array instead of the String class , so that you don't have to call reflection and make destruction more convenient. Another method is to use a byte array to save the password, because the plaintext is character encoding rather than human-readable characters, so it will be more difficult for people to understand.
These are the solutions that can be found on the Internet today, and this article refers to them as "naive" Java password protection schemes . Because these schemes only shorten the life time of the plaintext password on the Java heap, and do not really protect the plaintext password. Moreover, the word "timely" has great flexibility, and developers may not be able to accurately judge when it is timely.
A more typical case is the famous log4j vulnerability issue ( https://nvd.nist.gov/vuln/detail/CVE-2021-44228 ). An attacker can exploit the vulnerability of log4j 2.14 to upload a malicious class file to the server and run it through Java's dynamic class loading mechanism, thereby stealing the server's private key stored in the Java heap. With the private key, all communication content between the server and the client is as plaintext to the attacker.
In both of the above examples, the passwords and keys that need to be protected at runtime are security sensitive data. In actual scenarios, the scope of protection is not limited to sensitive data, but may also be extended to computing processes . For example, in authentication and authentication scenarios, it is necessary to ensure that the authentication process is credible and cannot be tampered with by attackers. Another example is when cloud service users deploy their own algorithms to the cloud, although the deployed products can be encrypted to protect the security of transmission and storage, and cloud vendors provide impregnable security protection against external attacks, users still worry about cloud computing. Does the manufacturer spy on the user's computing process at runtime, and whether there is a possibility of self-stealing.
It can be seen that protecting security-sensitive data and calculations in Java applications is not a distant demand, but a demand with urgent practical significance . For cloud computing providers, the black box that convinces users that their sensitive data and calculations are invisible to cloud vendors also has significant commercial value.
02 Status of Java Confidential Computing
Protecting sensitive data at runtime is not a new topic, but is part of a technology that has evolved over 20 years now—confidential computing. Confidential computing is a technology that provides hardware-level system isolation to ensure data security and program operation security. Confidential computing divides the execution environment into Rich Execution Environment (REE) and Trusted Execution Environment (Trusted Execution Environment, TEE), and believes that REE and TEE should be isolated from each other, and TEE needs to be encrypted by hardware to ensure that the outside world cannot know content. Security-sensitive content should be run in the TEE, and other content should be executed in the REE.
This mechanism was proposed as early as 1999, but the early hardware encryption technology has limited capabilities, only TPM (Trusted Platform Module) hardware that supports the execution of encryption and decryption programs. In 2008, Arm released the TrustZone technical white paper to support general-purpose confidential computing tasks on the Arm platform. In 2015, Intel also launched a hardware device with an SGX (Software Guard Extension) chip that supports general-purpose application encryption. In 2021, SGX will be upgraded to SGX2, which can support 1T memory and have higher performance.
The core concept of confidential computing is to provide a secure area for security-sensitive programs to run in a runtime environment that is at risk of being attacked, and to realize the security and reliability of security-sensitive data and programs in the entire process of transmission, storage, and computing. At present, confidential computing has a wide range of applications and broad prospects in privacy security, blockchain, multi-party computing, IoT and edge devices, as well as personal computing devices.
It seems that confidential computing technology is the standard answer to solve the problem of Java program security, so can we apply confidential computing technology in Java applications?
Occlum - puts the JVM and application monolith in the TEE
SGX, TrustZone, etc. provide the hardware foundation for general-purpose confidential computing, and open-source drivers and SDKs such as Intel and Microsoft provide the software foundation for general-purpose confidential computing. Based on these hardware and software foundations, developers can already use confidential computing in software applications. But confidential computing is not friendly to Java applications, because only native programs can run in TEE, so Java programs cannot run directly in TEE. To run a Java program in the TEE, you must first start a JVM in the TEE, and then execute the Java program on the JVM . So is it possible to run a JVM inside a TEE? The answer is yes, that is Occlum, and its principle is shown in Figure 2.
Occlum is a layer of LibOS between the underlying SDK of the TEE and the JVM. As an operating system, it supports the operation of ordinary JVMs in the TEE . The user deploys the entire Java program including the confidential code in the TEE, which is executed by the JVM supported by Occlum. The right half of Figure 2 shows the deployment structure, where the yellow APP represents the entire Java application and its required three-party library, and the red circle represents the trusted code. Applications are launched by a launcher in REE - usually just a small command-line tool. This solution has good compatibility, and users basically do not need to modify the original code to obtain confidential computing support. But the disadvantage is also obvious - too much code into TEE will cause two problems:
1. Decreased security . There may not be many trusted programs that need to be executed in TEE, but this solution needs to put all Java programs, three-party libraries, JVM and LibOS into TEE, resulting in too large TCB (Trusted Computing Base) , security is not ideal. TCB is an important indicator for measuring security in the security field, referring to the amount of trusted code. The larger the TCB, the more codes that may have security risks, and the worse the security of the program, so the smaller the TCB, the better . Take the log4j attack as an example, Occlum is still not immune to it. Because the log4j library and the confidential code are not separated in different execution environments, but are deployed in the TEE, the malicious class files uploaded by the attacker will also be located in the TEE, and the private key can still be accessed from the memory.
2. Performance degradation . The hardware of TEE is not general-purpose hardware, and there is performance degradation compared with REE, so putting the whole application into TEE will lead to the performance degradation of the whole application. However, the user's original demand is only partial encryption, and the overall performance degradation caused by partial encryption will increase the cost of applying confidential computing. Although general users can accept some performance degradation for security reasons, it is difficult to accept the additional performance degradation caused by over-encryption.
(Figure 2 Schematic diagram of Occlum principle)
In summary, although the Occlum scheme has the advantage of being simple and easy to implement, its shortcomings in terms of security and performance are the main obstacles to its practical application.
03 Teaclave Java TEE SDK – Put only trusted code in TEE
Because the scheme of supporting the JVM and all applications in the TEE will execute too much code in the TEE, resulting in a decrease in security and performance, it is difficult to put it into practice. Can you change the way of thinking and only put trusted code into the TEE? Considering that only native code can be executed in TEE, is it possible to directly compile trusted code from Java code into native code and put it into TEE to run? The answer is yes, this is the protagonist of this article, Teaclave Java TEE SDK, hereinafter referred to as Teaclave Java.
Teaclave Java is a Java confidential computing development framework and construction tool chain developed by the JVM team, which can quickly realize the development and construction of Java confidential computing applications in one stop. Taking a step back, even if the user does not have a hardware environment that supports confidential computing, Teaclave Java can also achieve security sandbox isolation, effectively ensuring the runtime security of sensitive data and programs.
The key technical features of Teaclave Java are:
1) Module separation and confidential computing service, as shown in Figure 3.
2) Concise and complete confidential computing service lifecycle management API.
3) Java statically compiles secrets.
4) Hide implementation details and automatically generate all auxiliary codes.
With the support of these technologies, Teaclave Java can convert the service calls between Java modules from ordinary modules to confidential modules into function calls from ordinary modules to confidential native libraries, as shown in Figure 4.
Module separation, confidential computing service
Teaclave Java divides the application code into three modules, Host, Enclave and Common . Host is a common security non-sensitive program, Enclave is a security-sensitive program, and Common is the common code used by the former two. This method of module division is to allow developers to perceive the security distinction of the code, and the second is to facilitate the use of different tool chains for different modules during construction.
Host and Enclave are decoupled, and they can only interact through Java's SPI (Service Provider Interface) mechanism, and cannot be called directly. The implementation of confidential computing is packaged as a service in the Enclave module, and its interface declaration is defined in the Common module and marked with @EnclaveService annotation. When a program in the Host needs to use a certain confidential computing task, it can first load the service instance and then call the corresponding function. The organizational relationship of this structure is shown in Figure 3.
(Figure 3 Development View of Teaclave Java)
For example, we can declare a confidential computing service interface shown in code block 1 in Common, which provides an API and authenticate function for authenticating whether the encrypted password is valid. This function accepts an encrypted password passed in by the user, and returns the authentication result of the password.
@EnclaveService
public interface AuthenticationService {
/**
* Given an encrypted input password, check if it is the correct password.
* @param inputPwd the encrypted password to be authenticated
* @return true if the given password is correct.
*/
boolean authenticate(String inputPwd);
}
Code block 1 defines a confidential computing service interface declaration example in the Common module
The specific implementation of the AuthenticationService interface is defined in the AuthenticationServiceImpl class of the Enclave module, as shown in code block 2. The authenticate function of this class first uses the private key to decrypt the input encrypted string to obtain the plaintext result, then compares it with the correct password stored in the memory, and then returns the result of checking whether it is consistent. The correct password value and private key stored in this class are all security-sensitive data, and the implementation of the authenticate function is also a security-sensitive operation. They will all run in the TEE, available as black boxes for external use. Only the encrypted input data and the returned judgment result can be seen from the outside, but the actual operation process and data cannot be peeked into.
public class AuthenticationServiceImpl implements AuthenticationService {
private String pwd = "somePwd"; // assume it's got at runtime.
@Override
public boolean authenticate(String inputPwd) {
String decryptedInputPwd = decrypt(inputPwd);
return pwd.equals(decryptedInputPwd);
}
private static String decrypt(String inputPwd) {
return inputPwd; // assume it's decrypted with private key
}
}
Code block 2 defines the implementation example of the confidential computing service interface in the Enclave module
The code example of the Host module using the confidential computing service is shown in code block 3, from which we can see that the use of the confidential computing service AuthenticationService interface is the same as the ordinary SPI interface, and it is still loading services, calling functions, and performing different actions according to the results, etc. process. The slight difference is that an instance of the confidential computing environment Enclave needs to be created first, and then the confidential computing service instance is loaded from it, thereby binding the confidential computing service instance and the environment instance, and finally the environment is destroyed. The API for lifecycle management of these confidential computing environments is provided by Teaclave Java. It can be seen from code block 3 that in the Host module, there is no need to know what the password and private key are, nor to understand the authentication process, but to call the authentication function as a black-box service.
public class Main {
public static void main(String[] args) throws Exception {
Enclave enclave = EnclaveFactory.create();
Iterator<AuthenticationService> services = enclave.load(AuthenticationService.class);
String pwd = "encryptedPwd"; // assume this is an encrypted password
while (services.hasNext()) {
AuthenticationService authenticationService = services.next();
if (authenticationService.authenticate(pwd)) {
System.out.println("Passed");
} else {
System.out.println("Rejected");
}
}
enclave.destroy();
}
}
Code block 3 Example of using Confidential Computing Service from the Host module
The above three parts of code constitute a complete Java confidential computing application. From the perspective of development, it looks basically the same as writing an application called by an ordinary SPI service. You only need to focus on the development of business logic, and you don't need to learn the underlying content of confidential computing. Therefore, Teaclave Java lowers the development threshold of Java confidential computing to zero.
Build confidential computing applications
Teaclave Java provides a complete set of construction tool chains to support the programming model described above, and users only need to enter a few simple maven commands to complete all construction tasks. The construction tool chain compiles non-confidential code and confidential code into Java bytecode products and native libraries that can be deployed in SGX, and automatically generates all auxiliary codes required to complete confidential computing service calls.
Figure 4 shows the build deployment view of Teaclave Java, which mainly includes three aspects:
1) Host and Common modules are compiled into common Java bytecode, deployed and executed in common environments.
2) The contents of the Enclave and the Common modules it uses are compiled into native confidential library files and deployed on the SGX hardware for execution.
3) It cannot be called directly from Java bytecode to native code, but requires some adaptation and conversion work, including:
-
Service proxy: through the dynamic proxy mechanism of Java, the confidential computing service call in the Host module is delegated to the actual native function, and the synchronization of the context, serialization and deserialization of service parameters and return values are completed.
-
JNI layer: native function declaration on the Java side, JNI function declaration on the native side, and auxiliary codes such as calls to confidential library functions.
(Figure 4 Teaclave Java deployment view)
The codes called by these adaptation transformations are automatically generated during construction and deployed in the normal environment and SGX respectively. They are marked in blue in Figure 4.
An important step in the build process is Java static compilation, which compiles the confidential portion of the Java code into native code.
Java static compilation
Java programs originally need to run on the JVM, but Java static compilation technology can compile Java programs (including JDK library dependencies and third-party library dependencies) together with necessary runtime support codes into native code, and then run them directly. In this way, the lightweight running of Java programs without JVM is realized.
Teaclave Java uses the most mature Java static compilation technology - Oracle-led open source project GraalVM for Java static compilation . GraalVM first analyzes the reachability of the Java program, finds all possible code ranges that can be executed from the program entry, and then only compiles these reachable codes to obtain a native artifact (called a native image). The program entry is the main function for the executable program, and the exposed public API for the library file. Specific to the Teaclave Java scenario, the entry point is the confidential computing service function defined by the developer, that is, the implementation function of the confidential computing service interface defined in the Enclave module. These interface implementations will use three dependencies, the code in the Common module, some JDK libraries, and other Java third-party libraries, but only some of the codes of these dependencies will be used, not all the codes. GraalVM will analyze the code actually used, and compile it into a native image together with the implementation code of the confidential computing service and the runtime support provided by GraalVM (called Substrate VM). However, GraalVM is oriented to general scenarios and hardware platforms, so Teaclave Java additionally provides it with the adaptation of the SGX hardware platform and the optimization of confidential computing requirements. When we compile the native image, we will find that it has some special properties:
-
TCB drops . GraalVM only compiles code reachable from the Confidential Computing Service portal, so the TCB is significantly reduced compared to Occlum's solution of putting LibOS, JVM, and Java applications all in the TEE.
-
Improved security . Native image has its own native memory heap at runtime, which is isolated from the Java heap and is difficult to access from Java applications (Java can still access native memory through the Unsafe interface, but it is much more difficult). Moreover, Java static compilation removes the dynamic characteristics of Java. Only reflection and dynamic class loading that are explicitly configured at compile time will take effect, and other dynamic behaviors at runtime are invalid. Log4j vulnerability attack is invalid on native image itself. Therefore, the native image can be regarded as a security sandbox. Even without the SGX hardware environment, the native image improves security compared to Java programs. After being deployed in SGX, the security of TEE will be higher, because the threat of Java dynamic characteristics to TEE security will be eliminated.
-
Performance improvements . GraalVM's Java static compilation has a considerable degree of compilation optimization for the code, and its runtime performance can roughly reach the C1 optimization level of the JVM. In addition, there is no need to start the JVM, no class loading process, no interpretation execution, no JIT consumption of resources, etc., Compared with Java programs, it can have an order of magnitude performance improvement when executing short tasks, and the memory is also greatly reduced.
These properties can effectively improve the security of confidential programs and enhance the practicability of Teaclave Java.
04 Teaclave Java Technology Assessment
The above introduces the technical issues such as the Java confidential computing programming model provided by Teaclave Java and the construction method adopted, so what is the final implementation effect? This paper takes the log4j vulnerability attack as an example to analyze the functional effectiveness of Teaclave Java.
In terms of TCB improvement and runtime performance analysis, we prepared 10 tests as shown in Table 1. The first four "app-" prefixes are simple applications written by ourselves. We treat them as confidential programs, and use their main entries as ordinary programs. The last six use cases prefixed with "ct-" use the unit tests of the famous open source encryption framework BouncyCastle (https://www.bouncycastle.org/java.html) . We provide a single entry to call these tests, and use the test entry as As an ordinary program, unit testing as a confidential program.
| test case | Rely on the main three-party library | describe |
| app-print | \ | print a message string |
| app-digest | BouncyCastle-full | Call BouncyCastle to calculate the hash value |
| app-rsa | BouncyCastle-full | Call BouncyCastle for RSA encryption |
| app-sqlparser | Druid | SQL parsing with Druid |
| ct-asn1 | BouncyCastle-core | BouncyCastle-core's asn1 submodule test |
| ct-i18n | BouncyCastle-core | BouncyCastle-core's i18n submodule tests |
| ct-util | BouncyCastle-core | BouncyCastle-core's util submodule tests |
| ct-math | BouncyCastle-core | The math submodule test of BouncyCastle-core |
| ct-pqc | BouncyCastle-core | The pqc submodule test of BouncyCastle-core |
| ct-crypto | BouncyCastle-core | Crypto submodule test of BouncyCastle-core |
(Table 1 / Test Case Description)
The confidential computing framework for Java uses OcclumJ and Teaclave Java for comparison. OcclumJ is a confidential computing model between Occlum and Teaclave Java implemented by us. It adopts the modularization and confidential computing service model of Teaclave Java, but it does not compile Java statically, but runs in Occlum mode in TEE. Confidential Computing Services.
Functional Effectiveness Assessment
Figure 5 shows the principle of log4j vulnerability attack (subfigure a) and the principle of Teaclave Java preventing log4j vulnerability attack (subfigure b). For an ordinary Java application service, it interacts with the client through three steps.
1) The client obtains the public key from the server.
2) The client encrypts the message with the public key, and then sends the ciphertext to the server.
3) The server takes out the private key from the runtime memory to decrypt the message, and then processes the message content. Assuming that the server uses log4j-2.14.x version for logging, the vulnerability allows the attacker to induce log4j to download the specified malicious class file from the remote server (steps 4, 5, 6 in Figure 5-a), and then load it dynamically The malicious class obtains the private key from the Java heap memory (step 7) and passes it to the attacker.
With the server's private key, all communications between the server and client appear as plaintext to the attacker.
a. log4j vulnerability attack illustration
b. Immune to log4j vulnerability attacks through confidential computing
(Figure 5 / Schematic Diagram of Java Confidential Computing Protecting Applications from Log4j Vulnerability Attacks)
Figure 5-b shows how Teaclave Java protects the application server from log4j vulnerability attacks. Teaclave Java puts the common code of the application in the REE, and puts the security-sensitive decryption and private key in the TEE. The encrypted message sent by the client will be forwarded to the TEE by the proxy service in the REE for decryption. At this time, when the attacker launches a log4j attack, because Log4j is deployed in the REE, the malicious code can only run in the REE, but cannot get the private key in the TEE memory, and the attack fails. What happens if the confidential code also uses log4j for logging, causing log4j to run in the TEE? At this time, log4j downloaded the attacker's malicious code into the TEE, but because Teaclave Java uses Java static compilation technology, the malicious code is unknown at compile time and will not be compiled into the native image. The Java static compilation technology does not support dynamic loading and execution of code that does not exist in the native image, so even if the malicious class is downloaded to the TEE, it will not be executed. Therefore, in this scenario, the confidential computing supported by Teaclave Java is still safe. However, if the Occlum solution is adopted, since there is a JVM in the TEE, the malicious code can be dynamically loaded and run, and the attack will be successful.
Taking a step back, when there is no SGX hardware to encrypt the TEE, the native image is still a native sandbox, and malicious Java code cannot easily obtain security-sensitive content from the native memory.
TCB assessment
Because Teaclave Java no longer needs LibOS and JVM, the confidential code part is also compiled and deployed on demand. Although the OcclumJ scheme adopts the sub-module model, it does not do static analysis, so it only divides the code at the module level. Although it is improved compared with Occlum's no division at all, it still has a considerable gap compared with Teaclave Java's function-level division. . Figure 6 shows a comparison of the size of the OcclumJ and Teaclave Java binary builds put into the TEE. The blue bar is the result of OcclumJ, the orange bar is the result of Teaclave Java, and Lejacon in the figure is the code name of Teaclave Java in the paper.
(Figure 6 TCB comparison of Occlum and Teaclave Java solutions. Lejacon is the code name of Teaclave Java in the paper)
It can be seen from the comparative data in Figure 6 that the compiled TCB size of Teaclave Java is only about 1/20 to 1/10 of that of Occlum . Considering the expansion of native code at compile time, the gap between the actual number of functions between the two is larger, so the TCB of Teaclave Java is an order of magnitude lower than that of Occlum, which has higher security.
runtime performance evaluation
Because the native image will run directly in the form of native code, the cold startup process of the Java program including JVM startup, class loading, interpretation and execution steps is omitted, so the startup speed will be very fast. If there is less confidential code to execute, it will be executed quickly. However, the code compilation quality of the native image is not as good as that of the JVM's C2, so when the program execution time is long enough and the Java code is fully compiled by JIT, the runtime performance of the native image will become closer and closer to that of the Java program as time goes by , and then surpassed. So the performance of Teaclave Java is much better than OcclumJ in small applications, but the advantage will be reduced in long-running applications.
Figure 7 demonstrates this feature. The blue line in the figure is the execution time of the confidential code part using the OcclumJ model, the yellow line is the execution time using the Teaclave Java model, and the green line is the time directly running on a normal JVM in a normal environment . The running time of the program in the TEE is longer than that in the normal environment, mainly because the creation of the confidential environment, the allocation of confidential memory and other overheads are increased, which we collectively refer to as the overhead of the confidential environment. The yellow line maintains performance close to that of the green line in a scene with a short execution time, indicating that the overhead of cold startup of the Java program can almost offset the overhead of the confidential environment of the native image. When the program execution time is long, the cold start overhead is diluted, but the secret environment overhead is proportional to the TEE memory usage, so the yellow line is steeper than the green line on the last three test cases.
Figure 8 shows the runtime memory usage comparison of OcclumJ and Teaclave Java. The memory consumption of OcclumJ includes three parts: LibOS, JVM and application, while the memory consumption of the Teaclave Java model is only the application and the lightweight runtime in the native image. A more simplified structure leads to less memory consumption for confidential computing in Teaclave Java mode.
(Figure 7 OcclumJ and Teaclave Java runtime performance comparison chart. Lejacon is the code name of Teaclave Java in the paper)
(Figure 8 / Comparison of runtime memory consumption between OcclumJ and Teaclave Java. Lejacon is the code name of TeaclumJava in the paper)
05 Summary
Teaclave Java is a Java confidential computing solution that is easy to use, effective, and good in performance. It can help users completely solve the problem of protecting security-sensitive content and computing in Java applications. Teaclave Java has hardware tolerance. When equipped with SGX hardware environment, Java users can enjoy the highest level of runtime security protection brought by confidential computing like other native language users ; A security sandbox can be provided to implement memory isolation for confidential codes to avoid direct exposure of security-sensitive content. It can be said that Teaclave Java is the standard answer to protect sensitive data and computing security in Java applications.
Oracle has contributed GraalVM's Java static compilation technology to OpenJDK, which is expected to be integrated into the OpenJDK backbone in JDK 21. Therefore, the Teaclave Java solution will be able to obtain native support from the JDK in the future. We also plan to submit a document on adding confidential computing specifications to the Java community, hoping to upgrade Teaclave Java's confidential computing model to a native Java confidential computing solution.
The papers published by this technology are: Xinyuan Miao, Ziyi Lin, Shaojun Wang, Lei Yu, Sanhong Li, Zihan Wang, Pengbo Nie, Yuting Chen, Beijun Shen, He Jiang. Lejacon: A Lightweight and Efficient Approach to Java Confidential Computing on SGX .ICSE 2023.
Paper link:
https://ddst.sjtu.edu.cn/Management/Upload/[News]a845acae286b470bb55013c1b5e425e2/20232101456536725sSV.pdf
The source code of the Teaclave Java project has been contributed to the Apache community, joined the confidential computing framework Teaclave project, and is currently in open source incubation.
Project link: https://github.com/apache/incubator-teaclave-java-tee-sdk
Homepage of Dragon Lizard Community Cloud Native Confidential Computing SIG:
https://openanolis.cn/sig/coco
-- over--