d-inference

[fix: remove hardcoded API_KEYS ](https://github.com/Layr-Labs/d-inference/pull/39/changes)

Looking at their paper at [1], there's a gaping hole: there's no actual way to verify the contents of the running binaries. The binary hash they include in their signatures is self-reported, and can be modified. That's simply game over. [1] https://github.com/Layr-Labs/d-inference/blob/master/papers/...

They use the TEE to check that the model and code is untampered with. That's a good, valid approach and should work (I've done similar things on AWS with their TEE) The key question here is how they avoid the outside computer being able to view the memory of the internal process: > An in-process inference design that embeds the in- ference engine directly in a hardened process, elimi- nating all inter-process communication channels that could be observed, with optional hypervisor mem- ory isolation that extends protection from software- enforced to hardware-enforced via ARM Stage 2 page tables at zero performance cost.[1] I was under the impression this wasn't possible if you are using the GPU. I could be misled on this though. [1] https://github.com/Layr-Labs/d-inference/blob/master/papers/...

From the paper: https://github.com/Layr-Labs/d-inference/blob/master/papers/... > Apple’s attestation servers will only generate the FreshnessCode for a genuine device that checks in via APNs. A software-only adversary cannot forge the MDA certificate chain (Assumption 3). Com- bined with SIP enforcement (preventing binary replace- ment) and Secure Boot (preventing bootloader tampering), this provides strong evidence that the signing key resides in genuine Apple hardware.