[BreachExchange] A Few Thoughts on Cryptographic Engineering

[Audrey McNeil]

https://blog.cryptographyengineering.com/2017/02/28/the-future-of-
ransomware/

This is kind of a funny post for me to write, since it involves speculating
about a very destructive type of software — and possibly offering some
(very impractical) suggestions on how it might be improved in the future.
It goes without saying that there are some real downsides to this kind of
speculation. Nonetheless, I’m going ahead on the theory that it’s usually
better to talk and think about the bad things that might happen to you —
before you meet them on the street and they steal your lunch money.

On the other hand, just as there’s a part of every karate master that
secretly wants to go out and beat up a bar full of people, there’s a part
of every security professional that looks at our current generation of
attackers and thinks: why can’t you people just be a bit more imaginative?!
And wonders whether, if our attackers were just a little more creative,
people would actually pay attention to securing their system before the bad
stuff happens.

And ransomware is definitely a bad thing. According to the FBI it sucks up
$1 billion/year in payments alone, and some unimaginably larger amount in
remediation costs. This despite the fact that many ransomware packages
truly suck, and individual ransomware developers get routinely pwned due to
making stupid cryptographic errors. If this strategy is working so well
today, the question  we should be asking ourselves is: how much worse could
it get?

So that’s what I’m going to muse about now. A few (cryptographic) ways that
it might.

Some of these ideas are the result of collaboration with my students Ian
Miers, Gabe Kaptchuk and Christina Garman. They range from the obvious to
the foolish to the whimsical, and I would be utterly amazed if any of them
really do happen. So please don’t take this post too seriously. It’s all
just fun.

Quick background: ransomware today

The amazing thing about ransomware is that something so simple could turn
out to be such a problem. Modern ransomware consists of malware that
infects your computer and then goes about doing something nasty: it
encrypts every file it can get its hands on. This typically includes local
files as well as network shares that can be reached from the infected
machine.

Once your data has been encrypted, your options aren’t great. If you’re
lucky enough to have a recent backup, you can purge the infected machine
and restore. Otherwise you’re faced with a devil’s bargain: learn top live
without that data, or pay the bastards.If you choose to pay up, there are
all sorts of different procedures. However most break down into the
following three steps:

When the ransomware encrypts your files, it generates a secret key file and
stores it on your computer.
You upload that file (or data string) to your attackers along with a
Bitcoin payment.
They process the result with their secrets and send you a decryption key.

If you’re lucky, and your attackers are still paying attention (or haven’t
screwed up the crypto beyond recognition) you get back a decryption key or
a tool you can use to undo the encryption on your files. The whole thing is
very businesslike. Indeed, recent platforms will allegedly offer you a
discount if you infect recommend it to your friends — just like Lyft!

The problem of course, is that nothing in this process guarantees that your
attacker will give you that decryption key. They might be scammers. They
might not have the secret anymore. They might get tracked down and
arrested. Or they might get nervous and bail, taking your precious data and
your payment with them. This uncertainty makes ransomware payments
inherently risky — and worse, it’s the victims who mostly suffer for it.

Perhaps it would be nice if we could make that work better.

Verifiable key delivery using smart contracts

Most modern ransomware employs a cryptocurrency like Bitcoin to enable the
payments that make the ransom possible. This is perhaps not the strongest
argument for systems like Bitcoin — and yet it seems unlikely that Bitcoin
is going away anytime soon. If we can’t solve the problem of Bitcoin, maybe
it’s possible to use Bitcoin to make “more reliable” ransomware.

Recall that following a ransomware infection, there’s a possibility that
you’ll pay the ransom and get nothing in return. Fundamentally there’s very
little you can do about this. A conscientious ransomware developer might in
theory offer a “proof of life” — that is, offer to decrypt a few files at
random in order to prove their bonafides. But even if they bother with all
the risk and interaction of doing this, there’s still no guarantee that
they’ll bother to deliver the hostage alive.

An obvious approach to this problem is to make ransomware payments
conditional. Rather than sending off your payment and hoping for the best,
victims could use cryptocurrency features to ensure that ransomware
operators can’t get paid unless they deliver a key. Specifically, a
ransomware developer could easily perform payment via a smart contract
script (in a system like Ethereum) that guarantees the following property:

"This payment will be delivered to the ransomware operator if and only if
the ransomware author unlocks it — by posting the ransomware decryption key
to the same blockchain."

There are various ways to do this. The decryption key itself could be a
pre-image k for some public value K that the ransomware generates and
leaves on your system. It’s relatively easy to imagine a smart contract
that allows payment if and only if the payee can post the input k such that
K=SHA256(k). This could easily be written in Ethereum, and almost certainly
has an analog for Bitcoin script.

The challenge here, of course, is to prove that k is actually a decryption
key for your files, and that the files contain valid data. There are a
handful of different ways to tackle this problem. One is to use complex
zero-knowledge proof techniques (like zkSNARKs or ZKBoo) to make the
necessary proofs non-interactively. But this is painful, and frankly above
the level of most ransomware developers — who are still struggling with
basic RSA.

An alternative approach is to use several such K challenges in combination
with the “proof of life” idea. The ransomware operator would prove her
bonafides by decrypting a small, randomly selected subset of files before
the issuer issued payment. The operator could still “fake” the encryption —
or lose the decryption key — but she would be exposed with reasonable
probability before money changed hands.

“Autonomous” ransomware

Of course, the problem with “verifiable” ransomware is: what ransomware
developer would bother with this nonsense?

While the ability to verify decryption might conceivably improve customer
satisfaction, it’s not clear that it would really offer that much value to
ransomware deverlopers. At the same time, it would definitely add a lot of
nasty complexity to their software.

Instead of pursuing ideas that offer developers no obvious upside,
ransomware designers presumably will pursue ideas that offer them some real
benefits. And that brings us to an idea time whose time has (hopefully) not
quite come yet. The idea itself is simple:

Make ransomware that doesn’t require operators.

Recall that in the final step of the ransom process, the ransomware
operator must deliver a decryption key to the victim. This step is the most
fraught for operators, since it requires them to manage keys and respond to
queries on the Internet. Wouldn’t it be better for operators if they could
eliminate this step altogether?

Of course, to accomplish this seems to require a trustworthy third party —
or better, a form of ransomware that can decrypt itself when the victim
makes a Bitcoin payment. Of course this last idea seems fundamentally
contradictory. The decryption keys would have to live on the victim’s
device, and the victim owns that device. If you tried that, then victim
could presumably just hack the secrets out and decrypt the ransomware
without paying.

But what if the victim couldn’t hack their own machine?

This isn’t a crazy idea. In fact, it’s exactly the premise that’s
envisioned by a new class of trusted execution environments, including
Intel’s SGX and ARM TrustZone. These systems — which are built into the
latest generation of many processors — allow users to instantiate “secure
enclaves”: software environments that can’t be accessed by outside parties.
SGX also isolates enclaves from other enclaves, which means the secrets
they hold are hard to pry out.

Hypothetically, after infecting your computer a piece of ransomware could
generate and store its decryption key inside of a secure enclave. This
enclave could be programmed to release the key only on presentation of a
valid Bitcoin payment to a designated address.

The beauty of this approach is that no third party even needs to verify the
payment. Bitcoin payments themselves consist of a publicly-verifiable
transaction embedded in a series of “blocks”, each containing an expensive
computational “proof of work“. In principle, after paying the ransom the
victim could present the SGX enclave with a fragment of a blockchain all by
itself — freeing the ransomware of the need to interact with third parties.
If the blockchain fragment exhibited sufficient hashpower along with a
valid payment to a specific address, the enclave would release the
decryption key.*

The good news is that Intel and ARM have devoted serious resources to
preventing this sort of unauthorized access. SGX developers must obtain a
code signing certificate from Intel before they can make production-ready
SGX enclaves, and it seems unlikely that Intel would partner up with a
ransomware operation. Thus a ransomware operator would likely have to (1)
steal a signing key from a legitimate Intel-certified developer, or (2)
find an exploitable vulnerability in another developer’s enclave.**, ***

This all seems sort of unlikely, and that appears to block most of the
threat — for now. Assuming companies like Intel and Qualcomm don’t screw
things up, and have a good plan for revoking enclaves (uh oh), this is not
very likely to be a big threat.

Of course, in the long run developers might not need Intel SGX at all. An
even more speculative concern is that developments in the field of
cryptographic obfuscation will provide a software-only alternative means to
implement this type of ransomware. This would eliminate the need for a
dependency like SGX altogether, allowing the ransomware to do its work with
no hardware at all.

At present such techniques are far north of practical, keep getting broken,
and might not work at all. But cryptographic researchers keep trying! I
guess the lesson is that it’s not all roses if they succeed.

Ransomware Skynet

Since I’m already this far into what reads like a Peyote-fueled rant, let’s
see if we can stretch the bounds of credibility just a little a bit
farther. If ransomware can become partially autonomous — i.e., do part of
its job without the need for human masters — what would it mean for it to
become fully autonomous? In other words, what if we got rid of the rest of
the human equation?

Ransomware with the ability to enforce payments would provide a potent
funding source for another type of autonomous agent: a Decentralized
Autonomous Organization, or (DAO). These systems are “corporations” that
consist entirely of code that runs on a consensus network like Ethereum.
They’re driven by rules, and are capable of both receiving and transmitting
funds without (direct) instruction from human beings.

At least in theory it might be possible to develop a DAO that’s funded
entirely by ransomware payments — and in turn mindlessly contracts real
human beings to develop better ransomware, deploy it against human targets,
and… rinse repeat. It’s unlikely that such a system would be stable in the
long run — humans are clever and good at destroying dumb things — but it
might get a good run. Who knows? Maybe this is how the Rampant Orphan
Botnet Ecologies get started.

(I hope it goes without saying that I’m mostly not being serious about this
part. Even though it would be totally awesome in a horrible sort of way.)

In conclusion

This hasn’t been a terribly serious post, although it was fun to write. The
truth is that as a defender, watching your attackers fiddle around is
pretty much the most depressing thing ever. Sometimes you have to break the
monotony a bit.

But insofar as there is a serious core to this post, it’s that ransomware
currently is using only a tiny fraction of the capabilities available to
it. Secure execution technologies in particular represent a giant footgun
just waiting to go off if manufacturers get things only a little bit wrong.

Hopefully they won’t, no matter how entertaining it might be.

Notes:

* This technique is similar to SPV verification. Of course, it would also
be possible for a victim to “forge” a blockchain fragment without paying
the ransom. However, the cost of this could easily be tuned to
significantly exceed the cost of paying the ransom. There are also many
issues I’m glossing over here like difficulty adjustments and the
possibility of amortizing the forgery over many different victims. But
thinking about that stuff is a drag, and this is all for fun, right?

** Of course, if malware can exploit such a vulnerability in another
developer’s enclave to achieve code execution for “ransomware”, then the
victim could presumably exploit the same vulnerability to make the
ransomware spit out its key without a payment. So this strategy seems
self-limiting — unless the ransomware developers find a bug that can be
“repaired” by changing some immutable state held by the enclave. That seems
like a long shot. And no, SGX does not allow you to “seal” data to the
current state of the enclave’s RAM image.

*** In theory, Intel or an ARM manufacturer could also revoke the enclave’s
signing certificate. However, the current SGX specification doesn’t explain
how such a revocation strategy should work. I assume this will be more
prominent in future specifications.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170302/8aa3cbca/attachment.html>