In reply to @beardog:amorgan.xyz
It's always in the name of protecting children.

In reply to @sarahjamielewis:matrix.org
My prediction is that sometime in 2022 there will be a new attack impacting SGX and that the paper will draw a direct line between the viability of the attack and a consensus attack on mobilecoin. In response mobilecoin will invoke some fuzzy notions of centralised trust anchors dressed up in the language of the "decentralized quorums" as reasons for why such an attack would fail in practice but ultimately provide vague plans to remove SGX from their system, probably replacing it with some other secure enclave. This cycle will repeat endlessly because there is a subset of people who will always believe secure enclaves are an actual thing that can exist rather than a cute notion they invoke in their papers to make their scheme secure.

In reply to @sarahjamielewis:matrix.org
My prediction is that sometime in 2022 there will be a new attack impacting SGX and that the paper will draw a direct line between the viability of the attack and a consensus attack on mobilecoin. In response mobilecoin will invoke some fuzzy notions of centralised trust anchors dressed up in the language of the "decentralized quorums" as reasons for why such an attack would fail in practice but ultimately provide vague plans to remove SGX from their system, probably replacing it with some other secure enclave. This cycle will repeat endlessly because there is a subset of people who will always believe secure enclaves are an actual thing that can exist rather than a cute notion they invoke in their papers to make their scheme secure.

In reply to @sarahjamielewis:matrix.org
There are a couple of levels worth considering for nuance:

SGX as implemented right now on most systems is fundamentally broken, many times over. There are several CPU bugs where patch rates are questionable and many others that are outright unpatchable (i.e. Load Value Injection). Last I checked Intels official response to this was "as long as you trust the OS to mitigate things properly it's not exploitable in the real world) which might be fine under some threat models, but is definitely not under ones we care about for something like Signal.

So anything that invokes SGX in its threat model is likely broken in practice, if not in theory. Invoking the "well I'm sure Signal patched their server OS" doesn't resolve the brokenness because it forces you to accept a trust assumption. (if you are willing to invoke that trust assumption then you don't need to bother with SGX at all - just trust signal to run the source code they say they run (which they sometimes don't publish for a year...but that's another thing entirely))

But, because the entire point of invoking a secure enclave is to protect your users from yourself then it's not just a case of auditing the source code, but also the entire operating system stack, continually - because the moment you take your eyes away from it it can be swapped out with something that makes it vulnerable.

In any case, as far as government agencies are concerned there is a spectrum from a targeted hack to an explicit backdoor. If a government could force Signals cooperation then there are likely far easier places to put a backdoor (like the client software, via a targeted poisoned appstore "upgrade"), so in terms of realistic exploits on the SGX side I'd be more concerned with a targeted hack (probably from states outside of jurisdictions where Signal operates).

thank you! I admit my knowledge of SGX is extremely limited, so I wasn't aware that there would be so many ways to get it wrong

speaking of Signal specifically, the threat model I'm thinking of is a pure metadata compromise, where you can reconstruct who's talking with whom, without necessarily knowing what they're saying ("we kill people based on metadata"). besides timing analysis, to me the easiest way seems to be compromising the contact list server: it gives you a "god mode" view over the entire network, it's completely opaque to researchers, you can turn it on and off any time, and Whisper Systems can plausibly deny they knew anything about it. there's a certain degree of secrecy around the Signal servers dictated by anti-censorship considerations that helps here

personally, I'm not too worried about the rogue update attack: it leaves permanent evidence all over the place, it's much harder to plausibly deny, and it would destroy the reputation of Signal and WhisperSystems if it were discovered. easier to compromise the extremely opaque servers (lots of places to hide bad code in a server, too: think SMM, or SGX itself), identify the target through traditional techniques and/or metadata analysis and then phish them with a targeted attack, IMHO. wrt the client I think the most realistic attack is a vulnerability in a third party codec or the VoIP stack, especially on iOS where only iMessage has the privilege to put sensitive code in separate sandboxed processes

In reply to @joepie91:pixie.town
still not totally sure what magic trick Intel pulled to convince the skeptics

In reply to @sarahjamielewis:matrix.org
There are a couple of levels worth considering for nuance:

SGX as implemented right now on most systems is fundamentally broken, many times over. There are several CPU bugs where patch rates are questionable and many others that are outright unpatchable (i.e. Load Value Injection). Last I checked Intels official response to this was "as long as you trust the OS to mitigate things properly it's not exploitable in the real world) which might be fine under some threat models, but is definitely not under ones we care about for something like Signal.

So anything that invokes SGX in its threat model is likely broken in practice, if not in theory. Invoking the "well I'm sure Signal patched their server OS" doesn't resolve the brokenness because it forces you to accept a trust assumption. (if you are willing to invoke that trust assumption then you don't need to bother with SGX at all - just trust signal to run the source code they say they run (which they sometimes don't publish for a year...but that's another thing entirely))

But, because the entire point of invoking a secure enclave is to protect your users from yourself then it's not just a case of auditing the source code, but also the entire operating system stack, continually - because the moment you take your eyes away from it it can be swapped out with something that makes it vulnerable.

In any case, as far as government agencies are concerned there is a spectrum from a targeted hack to an explicit backdoor. If a government could force Signals cooperation then there are likely far easier places to put a backdoor (like the client software, via a targeted poisoned appstore "upgrade"), so in terms of realistic exploits on the SGX side I'd be more concerned with a targeted hack (probably from states outside of jurisdictions where Signal operates).

thank you! I admit my knowledge of SGX is extremely limited, so I wasn't aware that there would be so many ways to get it wrong

speaking of Signal specifically, the threat model I'm thinking of is a pure metadata compromise, where you can reconstruct who's talking with whom, without necessarily knowing what they're saying ("we kill people based on metadata"). besides timing analysis, to me the easiest way seems to be compromising the contact list server: it gives you a "god mode" view over the entire network, it's completely opaque to researchers, you can turn it on and off any time, and Whisper Systems can plausibly deny they knew anything about it. there's a certain degree of secrecy around the Signal servers dictated by anti-censorship considerations that helps here

personally, I'm not too worried about the rogue update attack: it leaves permanent evidence all over the place, it's much harder to plausibly deny, and it would destroy the reputation of Signal and Open Whisper Systems if it were discovered. easier to compromise the extremely opaque servers (lots of places to hide bad code in a server, too: think SMM, or SGX itself), identify the target through traditional techniques and/or metadata analysis and then phish them with a targeted attack, IMHO. wrt the client I think the most realistic attack is a vulnerability in a third party codec or the VoIP stack, especially on iOS where only iMessage has the privilege to put sensitive code in separate sandboxed processes