IMHO, the service provider is the last one that should ever be able to see the keys :-). It's them we want to keep sensitive data away from
Keys are injected into the HW with public-key encryption. This requires that the HW have keys that only the HW knows (it's secret key). This key is made by a weak PUF circuit, which is basically a circuit that measures silicon process variation. So the keys are born in the silicon fab, through the natural variability of the silicon fabrication process. I didn't invent this, it is an old idea. Intel SGX uses the same approach.
There's no back doors, but there's no integrity checking either, so a Mojo-V voting machine could take an encrypted vote and throw it away and add +1 to the attacker's
favorite candidate.
A computational integrity checking mechanism will appear soon that will add a concise proof to every encrypted Mojo-V value, that will prove to the data owner that their requested computation was faithfully performed. And the mechanism also supports safe disclosures, too.
This should give data owners strong controls over what can be done with their data
I agree that side channel and physical attacks are crucial to stop. The predecessor to Mojo-V (Agita Labs TrustForge) was red teamed for three months including differential physical measurement attacks, and the system was never penetrated. So where there is a will there is a way!
Mojo-V stops software, inst timing, microarchitectural, and ciphertext side channels. Vendors can stop analog attacks if they choose to, but the reference design, which I am building, is meant to be really simple to integrate into an existing RISC-V core. Adding Mojo-V only requires changes to the Instruction Decoder and the Load-Store Queue, regardless of the complexity of the microarchitecture.
Yes exactly, because it is a privacy tech, the key/control channel tunnels through all software into the Mojo-V trusted H/W.
In the spec, I've been working on new Appendices comparing Mojo-V to TEEs, FHE, CHERI, and other high security tech. Mojo-V is a new thing, so absorbing it will take a while! :-)
I see it as a new design point between TEEs and FHE but much closer to FHE. TEEs are fast but they are not good at establishing trust with untrustworthy service providers, FHE is the ultimate in zero trust as all trust is in the math. Mojo-V eliminates all software, programmer, IT staff, attacker, malware trust with trusted hardware, and it runs near native speed.
And yeah, my mission is to snuggle as close to FHE as hardware can get!
For me, I see Mojo-V more like FHE than a TEE, for three primary reasons: 1) Like FHE, the tech is applied to variables and computation that doesn't touch protected variables is not affected. TEEs protect processes. 2) Like FHE, Mojo-V lacks software, timing, and microarchitectural side channels. TEEs are riddled with side channels. 3) Like FHE, no trust is extended to software because it cannot see the data it is processing. TEEs require that clients trust that the attested software has their best interests in mind.
Public key signing is like SGX, the vendor signs the public to certify that it is from real Mojo-V hardware.
IMHO, the service provider is the last one that should ever be able to see the keys :-). It's them we want to keep sensitive data away from
Keys are injected into the HW with public-key encryption. This requires that the HW have keys that only the HW knows (it's secret key). This key is made by a weak PUF circuit, which is basically a circuit that measures silicon process variation. So the keys are born in the silicon fab, through the natural variability of the silicon fabrication process. I didn't invent this, it is an old idea. Intel SGX uses the same approach.