Journal jd's Journal: Thoughts on confidential computing 2
https://www.theregister.com/security/2026/07/04/confidential-computings-core-trust-mechanism-is-broken-the-fix-may-not-exist/5266056
The claim in The Register is that confidential computing might not be a fixable problem. I am not going to claim I have "the solution", or that the solution I have come up with meets either the requirement of being necessary or sufficient, but I would argue that it adequately challenges the assumption that the problem cannot be solved at all.
So what is my hare-brained scheme this time?
Well, Brain, it's like this:
We first need to have reasonable confidence we are talking to the computer we are intending to be talking to. Now, in the early days of IPv6, when host-to-host IPSec was mandated, this class of problem looked to be generally solved. If we want to modify it for modern environments, it would need to look something like this. (Note: I'm using Class 3 as per the strong historical intent, as described later, to avoid unnecessary extra wording.)
1. IPSec in tunnel mode, with Class 3 digital certificates, at the entrance to the network at both ends. This gives us some assurance that we're talking to the right network.
I should define the entrance in a biit more detail. Packets arrive at a hardware proxy in a firewall's DMZ. This proxy handles the outer IPSec. The card rigorously enforces packet size and payload size, so underruns and overflows aren't effective. The inner IPSec packet exposes nothing but the source physical machine and target physical machine, but this obviously has to be a valid pairing.
2. IPSec in tunnel mode, with Class 3 digital certificates, on the physical ethernet cards at both ends. The ASN1 records used to build those certificates must include a full description of the hardware. There are optional fields in the X.509 certificate we can place the SHA3 value in. We can use SNMPv3 with strong encryption to interrogate what the system is reported by hardware as being, and can therefore not only validate that the certificate is correct but that it describes the hardware as reported.
The client therefore can validate that the system description, once decrypted, has the same SHA3 hash as the manufacturer described when building the certificate. Because of the type of certificate I'm mandating, the requirement is that the CA is vouching for verifying the credentials of the manufacturer and that the full hardware description genuinely describes the system the certificate is being issued for.
However, SNMPv3 is corroborative, not authoritative. It can compare the live-reported hardware inventory against the certificate manifest, but it cannot prove the hardware state unless the reporting agent is itself inside the trusted/measured boundary. The real machine must therefore do this in hardware. A fake machine can, of course, report how it likes, but as SNMPv3 supports strong encryption, getting the right values requires breaking into the SNMPv3 system. Which, over a network already doubly encrypted by IPSec, isn't going to be straightforward.
The certificate is derived from a set of manufacturer-held hardware measurements or device-specific secrets that are unique to the individual physical device and are not derivable from the certificate or from publicly observable behaviour. The hardware exposes only cryptographically protected evidence derived from these values; it does not reveal the values themselves. The authenticated management channel (for example, SNMPv3) is used solely as a confidential transport for this evidence, preventing disclosure of the underlying measurements during normal operation. A counterfeit device may fabricate arbitrary responses, but without knowledge of the device-specific secrets it cannot produce evidence consistent with the manufacturer-certified identity.
(This is distinct from simply using unclonable functions. An unclonable function is simply one way of producing the behaviour you want and not necessarily the best. The implementation is less important than the requirement that the client be able to independently verify - directly or through calculation - that the measurements made independently of the manufacturer match what the certificate says they should.)
The NIC certificate proves the NIC, not the whole physical machine. To prove the whole machine, the NIC identity must be bound to TPM/HSM/CPU/firmware/board measurements, not merely to a hardware manifest. As noted above, the measurements differ between components of the same type but are the same for the same component at all times. The full description of the hardware you're validating against is therefore truly a full a description of the physical environment. This means an attacker can't cheat by simply finding out what you're running. Nor is a replay attack going to help, because the description of the physical environment will vary by measurable criteria and the certificate can specify that relationship.
Our requirements are, however, double-ended. The server has exactly the same level of assurance that the hardware the user is using is the hardware the user is supposed to be using. Because the SNMPv3 is supposed to be a hardware implementation, alterations to the client hardware would be rejected just as much as alterations to the server's hardware.
3. The OS needs to be at a security level similar to B2 or B1. We have one IPSec tunnel per security label that we are using for the application. It is a requirement that the OS implements the Rainbow Book requirement of verification that only data of the right security label go to any given IPSec tunnel AND that IPSec tunnels only connect to machines that report they can handle that security label. Security labels must be end-to-end policy objects. The label has to bind the local process, user the process is running under, tunnel, remote process, remote OS clearance, and remote handler. Otherwise the tunnel may be correctly labeled but terminate in the wrong software context.
Now, again, this is authenticated bidirectionally, so that both client and server are assured that data is never permitted outside of its authorised bounds.
Further, the OS is authenticating all operations. So it is not sufficient that the processes are permitted to access the data. Processes at each end are only authorised certain operations. This is how we stop a process from being manipulated. A process that is only authorised to read data from a unidirectional connection cannot have the binary modified to write, because it isn't authorised to access the write function.
4. We need memory to be encrypted at the hardware level. The contents of memory are encrypted and all access is decrypted on-the-fly. Anything pushed into memory is also encrypted at the hardware level. This is handled per code segment, so one code segment cannot trivially access the memory of another code segment. Communication has to be by a controlled mechanism. This should be as transparent as possible, as you cannot fully trust the OS.
The read/write operations between a client and a server are two halves of the same code segment, so even if modules A and B on the server are both entitled to talk to the same client, module A on the server can only talk to module A on the client because module B will use different encryption so cannot understand anything sent from module A unless sent by a mechanism explicitly designed for that (which, in turn, would never have fine-grain access to the outside network). So even when access controls permit communication, it's not enough - it has to be between appropriate clode blocks.
(And, likewise, the appropriate code blocks running in inappropriate contexts also can't connect as there's now a security label violation.)
5. Data within each segment of program is also encrypted, but this can be a lightweight context-bound cryptographic transform. The idea is to force you to break the application in order to get keys to break the data, knowing the encryption for the memory is insufficient. Program blocks that communicate across networks use shared secrets, so that a module on computer A knows that it is talking to the corresponding module on computer B and not some different module in the same program.
If each individual library/module has a unique decryption key, then local copies of data are encrypted differently. This doesn't necessarily add overhead for us because the encryption and decryption are done at bus-level and we don't require these operations to match. This could be done in one of two ways - transfer the whole data across each time, OR decode in the context of where the data currently is where this cannot be determined solely by knowing the context of the code accessing it.
The idea is that if the data is in object A but object B references it, the key used is that for object A, since that is where the data is. Object B does not know which segment the data is in, so does not know which key will be used. So if the data moves to a segment controlled by object B, object B's key is now used but object B is totally unaware of the move or key change.
(So if you dlopen a dozen modules, each module will have its own independent encryption scheme.)
6. The application is also encrypted on disk, so having access to the disk copy isn't good enough.
7. Your virtual OS is something like Plan9/9Front/Inferno, running as a "federated" virtual computer. Each machine is running different encryption keys. Knowing the process is not enough, you have to know which instance it is running on. Reason for this is that it keeps garbage collection relatively simple.
8. The physical computer uses some form of responsive tamper resistance.
9. Security kernels in ALL of the OS' used must meet an adequate level of assurance of correctness. Proof is ideal. You don't need to prove the OS correct, if using proofs, only the security kernel.
In principle, this means that the client computer knows it is talking to the correct process in program A, running in the correct security label, running on the correct virtual machine, running on the correct physical machine, where the physical machine has provided evidence it is running the hardware it is supposed to be, on the correct computer network, where the certificates used to vouch for the virtual machine, physical machine, and network are of a level where there has been multiple pieces of physical documentary evidence provided in person to the certifying agency that the owner is who they say they are, that they are the owner of the equipment for which the certification is being issued, and that they own the business the equipment is used it.
Class 3 is, here, used in the strong sense of high-assurance organisational/device certificates with in-person identity/equipment/corporation validation. It should not be taken to mean anything that any CA happens to feel should merit this designation. The trusted CA keyring would have to reflect that.
The network/session key is bound to: peer certificate, security label, VM identity, process/binary measurement, handler-library measurement, and hardware. This means that you need access to information that is NOT readily available, even with physical access to the machine.
Does this provide a hard guarantee? Not quite. What it provides is that no layer trusts any other layer completely, and that there is a blend of shared secrets and double-ended authentication such that neither breaking into the code NOR breaking into the network will independently provide sufficient information.
Is this scheme workable? No idea. The question is not workability, or whether it even meets the strict criteria of genuinely confidential computing, but whether this sort of scheme is sufficient to provide an outline that is robust enough that a researcher could extend the ideas and thence construct a formal proof of whether confidential computing is achievable.
Re: (Score:2)
The DoD is known for viruses transporting payloads across airgaps onto Internet-connected machines. One thing it isn't is "so secure".
But, to the extent that it IS secure, it uses pretty much what I outlined. They use Class 3 certs for all users and all machines, and have done since about 2001. The US Navy got to trial run thei system to shake down the defects in the design, before they rolled it out to everyone. Beyond that, they use segregated networks (in principle, physical separation rather than logica