3 ms·

Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attesta

Ah, neat. I did something like Caution a few years ago but for Intel SGX, called Conclave. It made it much easier to deploy apps to enclaves, get remote attestations and communicate with them securely. Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on. Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure. Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.

lrvick 1mo ago
> It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on. Those things all exist now in several forms. You were just too early! (I know the feeling from past companies). SGX is a giant pile of design flaws I abandoned pretty early, but _TDX_ is what SGX should have been, and AMD sev-snp is wildly ahead allowing hardware memory encryption between different nested protection rings. Back before these nice things, I co-designed custom hardware security modules, which was my "do things that dont scale" period. > Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure. None of that is required anymore. With our design it is no harder than using Heroku. Bring the code you already wrote. Enclaves run hardened Linux kernels. If it can run in a container it can run on Caution. > Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. And if people on macs stuck to media work, we would have no issues. My rage comes from most sysadmins in silicon valley using homebrew/macos to ssh to production machines full of user data, and sometimes with billions of dollars in value attached. That is when I go into BOFH mode and start revoking access credentials.
- mike_hearn 1mo ago
  Now I'm curious, how do TDX enclaves get secure time and prevent rollback attacks on the VM? NTPS? Where's the secure counter you'd need to stop the disk image being rolled back? A lot of the attacks I discovered on SGX (the concept, not the implementation) were to do with the adversarial operator being able to roll back and replay inputs to the enclave. For example, you couldn't use a password to protect anything, because the enclave couldn't detect brute force attacks as it had no reliable forward sense of time.
  - lrvick 1mo ago
    Sorry just saw this reply. Absolutely agreed that downgrade attacks are a real problem, though TPMs can easily mitigate this by using their monotonic counter functions. Still, secure time is useful for many things. There are a lot of network protocol approaches to secure time, but for applications where it really matters where you cannot trust GPS, atomic clock PCI cards are in the low thousands of dollars now.

lrvick 1mo ago

> It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on. Those things all exist now in several forms. You were just too early! (I know the feeling from past companies). SGX is a giant pile of design flaws I abandoned pretty early, but _TDX_ is what SGX should have been, and AMD sev-snp is wildly ahead allowing hardware memory encryption between different nested protection rings. Back before these nice things, I co-designed custom hardware security modules, which was my "do things that dont scale" period. > Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure. None of that is required anymore. With our design it is no harder than using Heroku. Bring the code you already wrote. Enclaves run hardened Linux kernels. If it can run in a container it can run on Caution. > Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. And if people on macs stuck to media work, we would have no issues. My rage comes from most sysadmins in silicon valley using homebrew/macos to ssh to production machines full of user data, and sometimes with billions of dollars in value attached. That is when I go into BOFH mode and start revoking access credentials.

mike_hearn 1mo ago
Now I'm curious, how do TDX enclaves get secure time and prevent rollback attacks on the VM? NTPS? Where's the secure counter you'd need to stop the disk image being rolled back? A lot of the attacks I discovered on SGX (the concept, not the implementation) were to do with the adversarial operator being able to roll back and replay inputs to the enclave. For example, you couldn't use a password to protect anything, because the enclave couldn't detect brute force attacks as it had no reliable forward sense of time.
- lrvick 1mo ago
  Sorry just saw this reply. Absolutely agreed that downgrade attacks are a real problem, though TPMs can easily mitigate this by using their monotonic counter functions. Still, secure time is useful for many things. There are a lot of network protocol approaches to secure time, but for applications where it really matters where you cannot trust GPS, atomic clock PCI cards are in the low thousands of dollars now.