
Breaking Deniability in Signal with SGX [pdf] - Cortuld1935
https://aaltodoc.aalto.fi/bitstream/handle/123456789/33674/master_Vieitez_Parra_Ricardo_2018.pdf
======
repolfx
Deniability is a popular feature to add to cryptographic protocols and it
seems in vogue to complicate protocols significantly to get it. But does
anyone really care?

I'm struggling to think of a single case, ever, where someone embroiled in a
public dispute denied the contents of conversation logs, even in cases where
it'd be trivial to do so because the logs were just screenshots of WhatsApp or
copy/pasted emails. People _have_ deniable communications already in so many
cases and yet nobody cares, nobody actually ever claims "I didn't send that".

To take the Bezos case, he _could_ have just let them leak some dick pics and
then said, "not my cock, not my problem". How would anyone have known
otherwise?

The only case I can think of where cryptographic proof was used to prevent
deniability were some Wikileaks email dumps where there was some very small
amount of skepticism that all the emails were real, that maybe some forged
emails had been put amongst the real set. The messages were all DKIM signed
though, which proved it wasn't true. Which in this case would appear to have
been beneficial - the leaks revealed various political shenanigans that were
of a public interest nature. But I don't think DKIM ever made it to public
consciousness: journalists don't know about or don't care about cryptographic
proof.

Now maybe none of that matters, maybe deniability is near-free to implement so
why not? But this paper suggests it's more complex than it looks. Any
auditable generic computing infrastructure can be used to break deniability.
In the unlikely event that disclaiming screenshot-strength evidence becomes a
widespread tactic, anyone who wants to defeat it can just use a TPM and
trusted boot. Getting deniability back may either seriously complicate already
complex implementations (which is the enemy of correctness), or just fail
entirely.

Moreover it seems to me that most people, given the chance, would rather than
_undeniability_ , as that would be useful in all kinds of regular situations
like contract disputes. It'd make casual verbal-but-over-internet-chat type
contracts meaningfully useful, along with other interesting capabilities.

Perhaps in the end this protocol feature is a bad tradeoff.

~~~
kuzehanka
Just because you can't understand the value of deniability does not mean it
has none. As for trade-offs, there don't seem to be any according to this
paper.

From TFA:

"We then present an practical attack that can be used to compromise
deniability in the Signal messaging protocol, and introduce some possible
countermeasures that restore deniability

[...]

Deploying the attack presented in this thesis requires not only having access
to a TEE but also compromising one of the parties to a communication."

Deniability is a powerful tool which one would rather have and not need than
need and not have. Let research run its course for the betterment of
protections available to us all.

~~~
repolfx
_Deploying the attack presented in this thesis requires not only having access
to a TEE but also compromising one of the parties to a communication_

Essentially everyone with a PC has access to TEEs: beyond Intel SGX there's
also the traditional static root of trust mechanism, which suffices for this,
and also voids the paper's proposed solution; indeed the paper recognises that
given a certain kind of TEE there appear to be no solutions.

As for 'compromising one the parties', the point of deniability implemented
cryptographically is that your counterparty in the conversation could encrypt
messages such that you can't tell who encrypted them, i.e. an encrypted chat
log could have been forged. So the adversary is the person you're talking to:
they're already 'compromised'.

------
galadran
It's very neat and well worked out, but in hindsight it seems kind of obvious.
If the "judge" trusts an "uncorruptible" witness then deniability can't hold.

Now if only Intel could actually build a secure TPM! :P

~~~
hedora
And also get rid of the Visa hardware debugging block, apparently.

------
hedora
Tl;dr: From skimming the document, you only need to run one side of the
conversation in a trusted execution environment to break deniability for both
sides of the communication.

Clever!

