Upcoming improvements

[jlmucb]

Datica Research (https://www.daticaresearch.com/) is planning a number of additions to support Confidential Computing. Most of these will elements will become part of the Certifier Framework for Confidential Computing, others may be provided elsewhere to complement the Framework. Here is the current plan:

1. Factoring: The simulated enclave implementation will move to a sub-directory of src so that it is analogous to all the other platform providers.
2. Java: We plan to add a Java swig and interface including an implementation of "simple-app" in Java.
3. AWS support: We plan to build a "canonical" certifier-framework Sev-VM example, as a foundation for new applications that can easily run in the AWS environment. This will include configuration help and instructions on adding new applications to the VM, managing policy (like module loading), and maintaining a policy domain on the AWS platform. Most of this work should also work on other platform providers. We also plan to baseline the Certifier Service for these environments and introduce mitigations for attacks from adversarial VMM's. This will help provide a complete baseline for cloud hosted environments.
4. Android: We plan to do a port to Android including a simple, useful Kotlin application. Although Android is not, technically, a pure Confidential Computing platform, it allows us to start a client application set.
5. New platforms: We are considering ports to the following platforms:
   1.1 RISC-V (see https://github.com/IBM/ACE-RISCV)
   1.2 ARM CCA (see https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture)
   1.3 TDX (see https://docs.kernel.org/arch/x86/tdx.html)
   1.4 Nitro (see https://aws.amazon.com/ec2/nitro/ and https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html)
6. As conforming hardware becomes available, we'll add support for post-quantum crypto (NIST Fips 203 and 204). Many of the libraries we use already support it but there is no supporting hardware (as far as we know) yet.
7. We are adding tools and example for a new use model (VM OS security model).
8. Item 7 is nearly complete. As part of that, I fixed a few bugs but I noticed some changes I'd like to make in
   an upcoming pull:
   a. Paul England pointed out that the simulated_enclave, which is currently in $CERTIFIER_ROOT/src should move to a
   subdirectory like the other platform interfaces.
   b. Some of the interfaces assumed that a program (or app) would talk to only one application server and participate
   in one domain. Later improvements removed these restrictions. So some calls (like cold_init) ask for the URL
   of an applications server when initializing the trust manager and the trust manager has a concept of
   "primary" domain. Neither of these are necessary. No certified domain is distinguished and you only need
   to know the url (and port) of an applications server when you connect to it using secure_authenticated_channel.
   These changes (and some other cosmetic ones) will have minimal effect on application writing but should make
   the code easier to understand.

Added 2 Sept 2025

Items 1, 2, 3, 7 are done and item 8 is largely done although I have to write the documentation for the new API and
convert the existing sample apps to use the new API; they still work with the old API.

I have added "prepare-test.sh" and "run-test.sh" scripts to $CERTIFIER_ROOT/vm_model_tools/examples/scenario1
and modified the instructions in $CERTIFIER_ROOT/vm_model_tools/examples/scenario1/instructions.md to show
how to use them. Now you can test the application without "copying and pasting" commands to prepare the tests
and run them. Both simple_app and certifier_utility have been change to use the new API.

Added 8 Sept 2025:

I have modified most examples so that you can run a shell script (prepare-test.sh) that compiles examples,
writes certifier policy, and creates the supporting files and directories to run tests (See
$CERTIFIER_ROOT/sample_apps/simple_app, $CERTIFIER_ROOT/vm_model_tools/examples as well as
others); a second shell script (run-test.sh) will run the tests. This replaces the "copy and paste" instructions
in "instructions.md" in those same directories although they are still instructive in teaching the underlying
design and procedure. I am also moving the application enclave code (application_enclave.cc) into a subdirectory,
application (application-enclave) as I did with simulated-enclave. Then all the "enclave HALs" will have a
parallel structure. Finally, I am documenting the supporting infrastructure in
"$CERTIFIER_ROOT/APP-RUNTIME-STRUCTURE.md" to describe the supporting files for the runtime
envirronment for tests and real deployments. This was somewhat opaque for the simulated-enclave and
application-enclave. I will also change some file and directory names to make them consistent between
examples and utilities. Hopefully, this will clarify things and make them a bit more uniform.

Additional suggestions for platforms, language support and sample applications are welcome.