you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 6 days ago* (last edited 6 days ago) (4 children)

Attesting is very different from protecting

The binary performing the inference isn't running in the TEE, because the TEE runs on a weaker processor. The TEE is validating that the binary running on the main processors hasn't been tampered with

That's decent, but doesn't match the statement that inference is happening in the TEE

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 6 days ago (3 children)

    I think the phrase "running in the TEE" is the idiomatic way to describe a program running on the main CPU, attested by the TEE processor, and protected/isolated from other processes on the system (modulo exploits, lol). I'm vaguely familiar with AMD's SEV-SNP, mainly from reading security papers rather than any hands-on experience. I make no claims about Apple's Secure Enclave, though.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 6 days ago (2 children)

    I very much disagree with

    think the phrase "running in the TEE" is the idiomatic way to describe a program running on the main CPU

    In the Confidentiality/Integrity/Availability triangle, a secondary process running in another operating system gives you integrity, but not confidentiality

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 6 days ago (1 child)

    You both should just read the docs

    https://docs.darkbloom.dev/security/overview

    They lay out all the protections they have in place to ensure private prompt execution. The TEE is used to validate the integrity of the binary, and they use other protections like E2EE, SEV-SNP on the coordinator, MacOS security protections (hardened runtime, SIP, kernel protections, etc), plus (from what i can tell an optional enrollment from providers) in Apple's MDM which makes Apple verify the integrity of the system.

  • source
  • parent
  • hideshow 1 child comment