#  RansomClave: Ransomware Key Management using SGX

Alpesh Bhudia  Information Security Group
Royal Holloway, University of London
<EMAIL_ADDRESS>,  Daniel O’Keeffe  Royal Holloway,
University of London
<EMAIL_ADDRESS>,  Daniele Sgandurra  Information Security Group
Royal Holloway, University of London
<EMAIL_ADDRESS>and  Darren Hurley-Smith  Information Security
Group
Royal Holloway, University of London
<EMAIL_ADDRESS>
###### Abstract.

Modern ransomware often generate and manage cryptographic keys on the victim’s
machine, giving defenders an opportunity to capture exposed keys and recover
encrypted data without paying the ransom. However, recent work has raised the
possibility of future _enclave-enhanced_ malware that could avoid such
mitigations using emerging support for hardware-enforced secure enclaves in
commodity CPUs. Nonetheless, the practicality of such enclave-enhanced malware
and its potential impact on all phases of the ransomware lifecyle remain
unclear. Given the demonstrated capacity of ransomware authors to innovate in
order to better extort their victims (e.g. through the adoption of untraceable
virtual currencies and anonymity networks), it is important to better
understand the risks involved and identify potential mitigations.

As a basis for comprehensive security and performance analysis of enclave-
enhanced ransomware, we present RansomClave, a family of ransomware that
securely manage their cryptographic keys using an enclave. We use RansomClave
to explore the implications of enclave-enhanced ransomware for the key
generation, encryption and key release phases of the ransomware lifecycle, and
to identify potential limitations and mitigations.

We propose two plausible victim models and analyse, from an attacker’s
perspective, how RansomClave can protect cryptographic keys from each type of
victim. We find that some existing mitigations are likely to be effective
during the key generation and encryption phases, but that RansomClave enables
new _trustless_ key release schemes that could potentially improve attacker’s
profitability and, by extension, make enclaves an attractive target for future
attackers.

##  1\. Introduction

Over the last decade, ransomware has become one of the more prominent cyber-
security threats against individuals and organisations (Keshavarzi and
Ghaffary, 2020). Ransomware is a malware that either renders a victim’s
computer resources (_locker-ransomware_) or valuable data (_crypto-
ransomware_) unusable (Luo and Liao, 2007). Crypto-ransomware is currently the
most common of the two, and is especially difficult to defend against since
victims are required to obtain the corresponding decryption key to access
their data (assuming no backup is available).

A typical ransomware attack lifecycle goes through four main phases:
installation, unique public/private key generation, encryption (with symmetric
keys), and extortion/private key release. For a successful operation, the
private key created in the second phase needs to be securely stored and only
released in the last phase once the victim has paid the ransom (Liska and
Gallo, 2016; Al-rimy et al., 2018). Previous work has shown several weaknesses
in existing ransomware cryptographic key management systems (Berrueta et al.,
2019; Davies et al., 2020; Bajpai et al., 2018; Halderman et al., 2009). For
example, many ransomware variants (e.g., DMA Locker, Locky, Cerber, WannaCry,
NotPetya, and BadRabbit) generate and store cryptographic keys (both
asymmetric and symmetric ones) in untrusted memory on the victim’s machine
before permanently deleting them. Fortunately, victims can exploit such
weaknesses to extract the generated keys using memory forensics techniques
(Maartmann-Moe et al., 2009) and tools like Dumpit, RAMCapturer and FTK imager
(Villalba et al., 2018). Additionally, researchers have developed techniques,
e.g. PayBreak (Kolodenker et al., 2017), to capture keys generated at run-
time.

Unfortunately, emerging technology could render some of these mitigations
ineffective. As recent work has observed (Marschalek, 2018), ransomware
authors share many of the challenges faced by _confidential cloud computing_
(Sabt et al., 2015), which seeks to protect applications deployed on remote
cloud infrastructure from a malicious cloud provider. To solve these
challenges, confidential cloud computing leverages emerging support on
commodity hardware for trusted execution environments (TEEs), such as Intel
SGX (Costan and Devadas, 2016; Mofrad et al., 2018). SGX TEEs, commonly known
as _enclaves_ , allow parts of an application to be executed securely
irrespective of the rest of the system (Sabt et al., 2015). As has been shown,
it is also possible for malware to hide malicious activities within enclaves
to evade anti-virus systems (Marschalek, 2018). However, previous studies have
not considered the impact of enclaves on the complete lifecycle of ransomware
cryptographic key management, and the practicality and performance overhead of
such a ransomware variant is unclear. Given the damage ransomware causes, it
is important to understand what new advantages such ransomware might provide
to attackers, whether anti-malware mechanisms in existing enclave technology
are robust against them, and whether additional anti-ransomware mitigations
might be required.

We perform an in-depth study of the potential implications of enclave-enabled
ransomware using RansomClave, a proof-of-concept family of ransomware variants
that leverages SGX to manage ransomware cryptographic keys on a victim’s
machine. RansomClave, once executed, creates an enclave that it uses to
securely generate asymmetric key pairs. RansomClave releases the private key
only when a ransom payment transaction from the Bitcoin blockchain is verified
by the enclave.

In contrast to previous work, we analyse the security and practicality of
RansomClave with respect to all phases of the ransomware lifecycle. During the
key generation and encryption phases, we show that there is a design-space
whereby to avoid triggering network monitoring software a ransomware author
may skip SGX remote attestation and avoid command and control (C2) server
communication before encryption completes, but that this prevents dynamic
loading of encrypted ransomware code to the enclave. Similarly, during the key
release phase, we use RansomClave to show that enclaves open up a design-space
of new key release schemes, each with different trade-offs for the attacker
between security, reliability, and operational overhead. Of particular concern
are fully autonomous or _trustless_ key release schemes, which do not require
the victim to trust the attacker to release the decryption key after a ransom
is paid. This guarantee could increase a victim’s willingness to pay a ransom
and by extension attacker profitability.

Contributions. In summary, this paper makes the following contributions:

  1. (1)

We analyse key management schemes of existing ransomware variants and, based
on our findings, derive requirements for a successful attack (§3).

  2. (2)

We introduce RansomClave, a proof-of-concept SGX-based ransomware that
generates keys in an enclave to protect them from disclosure (§5), and analyse
its performance.

  3. (3)

We propose three blockchain-based RansomClave key release schemes and show how
avoiding interaction with the attacker post-infection could potentially make
the ransomware operation more profitable for attackers (§6).

  4. (4)

We analyse mitigations to defend against SGX-based ransomware attacks (§8).

##  2\. Background

This section provides background on ransomware encryption mechanisms, and a
summary of relevant features of Intel SGX.

Ransomware Encryption Schemes. Modern ransomware are often classified into
three types based on the type of encryption employed. _Symmetric encryption
ransomware_ uses one key for both encryption and decryption and allows faster
file encryption, resulting in shorter time to complete the attack. This also
reduces the chances of the attack being discovered by requiring less
processing power for computations. _Asymmetric encryption ransomware_ uses
asymmetric cryptography, with the public key used to encrypt files and the
associated private master key to decrypt them. The encryption process is a
resource-intensive task and slower in comparison to symmetric key encryption
due to the overhead of public-key encryption. However, it is more secure since
the encryption process can be completed using only the public key thus
allowing the private key to be kept secret. Finally, _hybrid encryption
ransomware_ incorporates both symmetric encryption and asymmetric encryption.
It uses symmetric encryption to encrypt the user files quickly. The symmetric
key is then encrypted using asymmetric encryption. Hybrid encryption is often
used by newer strains of ransomware, and reaps the benefits of both symmetric
encryption (speed) and asymmetric encryption (security) (Bhardwaj, 2017; Kok
et al., 2019).

Intel SGX. Intel SGX is a security enhancement to recent Intel CPUs that
provides a trusted execution environment (TEE). SGX TEEs, known as _enclaves_
, protect the integrity and confidentiality of applications handling sensitive
data such as cryptographic keys. The SGX architecture enables an application
to instantiate one or more enclaves such that enclave code and data is
protected from the OS and hypervisor (Costan and Devadas, 2016; Sinha et al.,
2015), and even from an attacker with physical access to the victim’s computer
(McKeen et al., 2013).

Enclave code must execute in user space, and is not able to execute system
calls or access secure peripherals. As such, applications are divided into two
parts, a protected enclave (trusted code) and an unprotected part (untrusted
code) which handles communication between the OS and enclave. The processor
transparently encrypts and integrity protects enclave data whenever it leaves
the CPU. The Intel SGX SDK provides a function call-like abstraction for
entering and exiting an enclave. Calls into the enclave are referred to as
ECALLs (enclave entry call), and calls from the enclave to outside as OCALLs
(outside call) (McKeen et al., 2013; Costan et al., 2017; Shepherd et al.,
2017).

The SGX architecture includes a sealing capability, which allows data to be
stored on persistent storage in an encrypted form. The sealing key is
generated using a Key Derivation Function (KDF) (Costan et al., 2017) from the
embedded base data seal key, which is fused into each processor during
manufacturing by Intel. The sealing key is provided by the processor to the
enclave, and only the enclave that sealed the data can later unseal it. SGX
also supports remote attestation to allow a remote party to verify an enclave
and establish a secure channel to it. To launch a production enclave in SGX
version 1 (SGXv1), SGX required either the enclave binary or its author to be
registered with Intel. In SGXv2, Intel added a flexible launch control
capability, allowing the platform owner to bypass Intel as an intermediary in
the enclave launch process (Schwarz et al., 2019; Intel, 2020c).

##  3\. Ransomware Key Management

In this section, we discuss how ransomware key management schemes have evolved
over the years. We then analyse the weaknesses of existing schemes in the face
of modern anti-ransomware techniques, and propose five requirements of an
attacker for a ransomware design. Notation used in our analysis and the
remainder of the paper is as follows: (i) $\mathit{AK_{prv}}$ (attacker’s
private key); (ii) $\mathit{AK_{pub}}$ (attacker’s public key); (iii)
$\mathit{VK_{prv}}$ (victim specific private key); (iv) $\mathit{VK_{pub}}$
(victim specific public key); (v) $\mathit{EK_{v(f)}}$/$\mathit{EK_{v}}$
(symmetric key for victim $\mathit{v}$’s file $\mathit{f}$ — index
$\mathit{f}$ omitted where not relevant); (vi) $\mathit{nonce}$ (pseudo-random
number).

###  3.1. The Evolution of Ransomware Key Management

At the heart of any ransomware operation lies key management: if poorly
implemented, it can potentially leak encryption keys to the victim and
threaten the entire campaign (Conti et al., 2018). Table 1 summarises our
analysis of key management schemes in some of the most prevalent ransomware
families. Our analysis extends several previous analyses (Wyke and Ajjan,
2015; Berrueta et al., 2019; Halderman et al., 2009), in particular, we also
show existing core ransomware functionalities and match them against a set of
requirements (formally defined in §3.2) that must be met by ransomware
variants.

Table 1. Ransomware key management requirements

Encryption Method |  Families |  Release | Ransomware RQ (§3.2)
---|---|---|---
RQ1 |  RQ2 |  RQ3 |  RQ4 |  RQ5
|  Apocalypse |  2016 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  Jigsaw |  2016 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
Symmetric |  Razy |  2016 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  CryptoLocker |  2014 |  ✓ |  ✓ |  ✗ |  ✗ |  ✗
|  CBT-Locker |  2014 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  CryptoDefense |  2015 |  ✗ |  ✓ |  ✗ |  ✗ |  ✗
Asymmetric |  PetrWrap |  2016 |  ✓ |  ✗ |  ✗ |  ✓ |  ✗
|  Unlock92 |  2016 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  CryptoWall |  2014 |  ✓ |  ✓ |  ✗ |  ✗ |  ✗
|  TorrentLocker |  2014 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  TeslaCrypt |  2015 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  Cerber |  2016 |  ✗ |  ✓ |  ✗ |  ✓ |  ✗
|  Locky |  2016 |  ✓ |  ✓ |  ✗ |  ✗ |  ✗
Hybrid |  Petya |  2016 |  ✓ |  ✓ |  ✗ |  ✗ |  ✗
|  RYUK |  2017 |  ✓ |  ✗ |  ✗ |  ✗ |  ✗
|  WannaCry |  2018 |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
|  EKING |  2020 |  ✓ |  ✗ |  ✗ |  ✓ |  ✗
TEE |  RansomClave |  2021 |  ✓ |  ✓ |  ✓* |  ✓ |  ✓

* Only in proactive variant

Figure 1. Current key management process of a typical ransomware

Our research shows that the majority (60%) of ransomware variants rely on an
active Internet connection on the victim’s machine to exchange keys with a
command-and-control (C2) server (Bajpai et al., 2018; Berrueta et al., 2019).
Additionally, 40% of ransomware variants (e.g., WannaCry) generate keys on a
victim’s untrusted machine, thus leaving them exposed and vulnerable to
recovery (Berrueta et al., 2019; Halderman et al., 2009). Older strains of
ransomware, such as Apocalypse and CryptoLocker, use either symmetric key or
asymmetric key encryption. Newer strains, such as CryptoWall, TeslaCrypt,
WannaCry and RYUK often opt for a hybrid encryption method. As Figure 1 shows,
there are three variants,  V1,  V2, and  V3 for key generation. In  V1,
ransomware, once executed (\small1⃝), generates $\mathit{VK_{prv}}$ and
$\mathit{VK_{pub}}$ locally on the victim’s machine while sending the
$\mathit{VK_{prv}}$ to the attacker’s C2 server. In  V2, the ransomware
generates the key pair on the C2 server, sending the $\mathit{VK_{pub}}$ to
the victim’s machine while safely storing the $\mathit{VK_{prv}}$. A unique
$\mathit{EK_{v}}$ is generated for each victim file to be encrypted
(\small2⃝), and all $\mathit{EK_{v}}$ are then encrypted with the
$\mathit{VK_{pub}}$ (\small3⃝).

###  3.2. Ransomware Key Management Requirements

We define a set of desirable requirements from an attacker’s perspective that
modern ransomware must fulfil to achieve its primary goal successfully, i.e.
encrypt victim’s data, secure the $\mathit{VK_{prv}}$ and hold the data
hostage until the ransom is paid. As we will see however, some of these
requirements are potentially in conflict with each other.

RQ1: Secure asymmetric key generation. Ransomware must ensure that the
$\mathit{VK_{prv}}$ needed to decrypt individual $\mathit{EK{v}}$ is not
exposed to the victim at any point before the ransom is paid. Many attackers
prefer setting up their own trusted C2 server to generate, distribute and
securely store $\mathit{VK_{prv}}$ as it provides some measure of protection
against the arbitrary key recovery. However, this setup requires an outbound
connection before beginning the encryption process (Dargahi et al., 2019;
Bajpai et al., 2018), which could be blocked/inspected by network monitoring
tools (Morato et al., 2018; Cusack et al., 2018). In addition, if the server’s
location is compromised, it could potentially be taken down by law enforcement
(Ransom, 2021), thus exposing $\mathit{VK_{prv}}$ (Mims, 2017).

RQ2: Unique key per victim. Ransomware must generate a unique
$\mathit{VK_{prv}}$ for each victim to maximise the ransom payment received
from victims. Some attackers deploy ransomware  V3, such as IEncrypt, with an
embedded $\mathit{VK_{pub}}$ to eliminate outbound connections. However, using
one global $\mathit{VK_{prv}}$ could lead to victims collaborating and sharing
the master key (Orman, 2016).

RQ3: Secure symmetric key generation. Ransomware in a hybrid encryption
setting must ensure that the unique $\mathit{EK_{v}}$ used to encrypt each
victim file are not exposed to the victim at any point.

RQ4: No post-exploitation connections. To evade network monitoring software,
Ransomware must avoid outbound connections to a C2 to retrieve the private
keys or payload, or to an attestation service, until the victim’s files have
been encrypted.

RQ5: Trustworthy key release. Ransomware must employ a secure and reliable key
release scheme post-attack to incentivise victims to co-operate and pay the
requested ransom (Cartwright et al., 2019). The scheme should also avoid
unnecessary operational overhead for the attacker (e.g. to maintain an online
presence, or manage large numbers of decryption keys). Some attackers request
victims to send the encrypted $\mathit{VK_{prv}}$ along with the ransom
payment to avoid exposing the $\mathit{AK_{prv}}$. However, keys are still
generated on the victim’s machine leaving them vulnerable.

##  4\. Threat Model

In our threat model we assume the malware distribution and installation stages
have been successfully performed. We assume the ransomware has the appropriate
privilege to start enclaves and issue syscalls. We assume that the victim’s
machine supports Intel SGX and the SGX feature is enabled. We revisit the
plausibility of these assumptions in our discussion of mitigations in §8.

We consider two different types of target systems: (i) standard system
equipped with an AV, however, lacking any specific anti-ransomware
functionality; (ii) advanced system equipped with an up-to-date AV that also
includes an anti-ransomware module and can also capture cryptographic keys
generated locally (e.g., PayBreak). In all cases, we assume that a victim
cannot break the hardware-enforced security of SGX to obtain enclave-specific
keys (e.g., sealing keys). We also assume that Intel would not release the key
embedded into each processor during the manufacturing of the SGX-capable CPU
(Anati et al., 2013).

##  5\. RansomClave Key Generation and Encryption

As a basis for security and performance analysis of enclave-enhanced
ransomware, we present RansomClave, a family of ransomware that securely
manage their cryptographic keys using an enclave. In this section we describe
RansomClave’s key generation and encryption phase, and how conflicts between
the requirements introduced in §3.2 motivate two different RansomClave
variants. We defer detailed discussion of trustworthy key release (RQ5) to §6.

Figure 2. Key management and execution flow of RansomClave (steps
\small7⃝-\small8⃝ shown for reactive RansomClave)

RansomClave’s key generation and encryption can be split into two stages. The
first stage, asymmetric key generation (Figure 2, steps \small1⃝-\small5⃝), is
common to both RansomClave variants. The second stage, symmetric key
generation and encryption, differs between variants (Figure 2, steps
\small7⃝-\small8⃝).

###  5.1. Asymmetric Key Generation

As shown in Figure 2, the RansomClave malware consists of both untrusted code
(host application) and trusted code (enclave). RansomClave asymmetric key
generation happens primarily inside the enclave. Once the malicious payload is
executed, RansomClave’s untrusted code creates the enclave \small1⃝. The
untrusted code then performs an ECALL to enter the enclave and initiate key
generation and encryption \small2⃝. On entering the enclave for the first
time, RansomClave generates a victim specific asymmetric key pair
$\mathit{(}VK_{prv},VK_{pub})$ \small3⃝. RansomClave then creates an enclave-
specific seal key using the EGETKEY instruction, and seals $\mathit{VK_{prv}}$
using the seal key \small4⃝. Finally, the enclave performs an OCALL to send
the unique $\mathit{VK_{pub}}$ and sealed $\mathit{VK_{prv}}$ to untrusted
code \small5⃝. Both keys are then stored outside the enclave on the victim’s
system.

###  5.2. Symmetric Key Generation and Encryption

RansomClave’s symmetric key generation and encryption stage is similar to
other modern ransomware that use a hybrid scheme for improved performance.
However, we introduce two different RansomClave variants for managing
symmetric keys, reactive and proactive, each focused on the capabilities of
the target system.

Reactive RansomClave: This variant generates symmetric keys and encrypts the
victim’s files _outside_ the enclave. It targets a reactive victim who is
unlikely to detect the ransomware and capture symmetric keys exposed in
untrusted memory (RQ3) before encryption completes. However, encrypting files
outside the enclave avoids additional data movement overheads, allowing
encryption to complete more quickly and thus serving as a baseline for
performance comparison with other variants.

Figure 2 shows the untrusted code generating a unique 256-bit AES symmetric
key ($\mathit{EK_{v(f)}}$) for each file $\mathit{f}$ before the encryption
process starts (\small7⃝). After encryption of file $\mathit{f}$ completes,
each $\mathit{EK_{v(f)}}$ is encrypted using $\mathit{VK_{pub}}$ (\small8⃝)
and then the plaintext $\mathit{EK_{v(f)}}$ is deleted. Only the encrypted
version of $\mathit{EK_{v(f)}}$ remains after the encryption process. Steps
(\small7⃝) and (\small8⃝) repeat until all the victim files have been
encrypted. The benefit of using per-file symmetric encryption keys is that the
$\mathit{EK_{v(f)}}$ for files already encrypted will not be recoverable
(since the original $\mathit{EK_{v}}$ is deleted after encrypting each file)
even if the ransomware attack is discovered and stopped mid-execution.

Proactive RansomClave: This variant assumes a proactive victim who is vigilant
and potentially able to start capturing cryptographic keys soon after the
ransomware is executed (Davies et al., 2020) It generates $\mathit{VK_{prv}}$,
$\mathit{VK_{pub}}$ and each $\mathit{EK_{v(f)}}$ inside the enclave. In
addition, the ransomware also encrypts each victim file inside the enclave. By
generating the $\mathit{EK_{v}}$ and encrypting files inside an enclave, the
proactive variant mitigates some of the security weaknesses of the reactive
variant, i.e. exposure of the $\mathit{EK_{v}}$ in memory (RQ3)

Although the proactive variant comes closer to meeting RQ3, we note that by
default SGX does not provide confidentiality to enclave code. As a result, a
proactive victim with sufficiently advanced AV could inspect the malware code
and detect RansomClave given an appropriate signature. Although an additional
RansomClave variant with private dynamic code loading is possible (Silva et
al., 2017), it would need to communicate with a C2 server to download an
encrypted malicious payload (violating RQ4). For similar reasons, we do not
consider using remote attestation to verify the enclave.

Another potential drawback of the proactive variant is its performance, since
it must transfer victim files to the enclave from the host file system.
Performing file related system calls from the enclave requires additional
costly enclave transitions, potentially slowing the overall encryption process
and jeopardising the attacker’s primary goal of holding the victim’s data
hostage quickly. However, previous work has shown that asynchronous system
calls can be used to mask much of this overhead (Arnautov et al., 2016). We
evaluate the overhead of the proactive variant with this optimization in §7.

##  6\. RansomClave Key Release

Once RansomClave has successfully encrypted the victim’s files and presented
the victim with a ransom note, the next phase of its operation is key release.
As discussed in §3.1, existing key release schemes introduce additional
security risks and operational overhead for the attacker. Furthermore, they
require the victim to trust the attacker to release the decryption key after a
ransom is paid.

In this section we show how RansomClave enables more robust key release
schemes in comparison to existing ransomware. We next explore three
alternative RansomClave key release schemes, each providing different trade-
offs between the security of the scheme, the operational overhead of the
attacker for managing decryption keys, and the likelihood the victim will pay
the ransom111In all these schemes, for simplicity, we assume that, once the
private key has been released, the victim is able to decrypt the files
autonomously, e.g. by using a decryptor that takes as input the private key
and that is part of RansomClave or provided by the attacker independently..

###  6.1. Blockchain with Online Attacker

Our first RansomClave key release scheme leverages a public blockchain (e.g.
Bitcoin) and digital signatures to exchange metadata such that RansomClave
will only unseal $\mathit{VK_{prv}}$ after the ransom has been paid.

Security. From the attacker’s perspective, the advantage of this approach is
its security, since the attacker can independently check a ransom payment
exists on the blockchain. The disadvantages are that it requires the attacker
to maintain an online presence to monitor the blockchain, increasing
operational overhead, and it requires the victim to actually trust the
attacker to release the key after a payment has been made (as with current
ransomware). We note that, unlike the next two schemes proposed later in this
section, a variant of this scheme could potentially be used in combination
with existing (non SGX-based) hybrid encryption ransomware.

Overview. In this scheme, the victim is required to first make a ransom
payment on the Blockchain that contains the following metadata in the
transaction: $\mathit{AK_{pub}}$, $\mathit{VK_{pub}}$, and a $\mathit{nonce}$.
Additionally, RansomClave derives a bitcoin wallet address based on the
$\mathit{AK_{pub}}$ embedded in it and generates a random $\mathit{nonce}$
unique to the RansomClave enclave with high probability. The $\mathit{nonce}$
is used as input to a cryptographic hash function digitally signed later on
the attacker’s machine once the attacker notices the ransom payment.
($\mathit{AK_{prv}}$, $\mathit{AK_{pub}}$) key pair is generated/stored on the
attacker’s machine while ($\mathit{VK_{pub}}$, $\mathit{VK_{prv}}$) is
generated inside an enclave and stored ($\mathit{VK_{prv}}$ as sealed) on the
victim’s machine. The victim next makes a ransom payment through Bitcoin (Li
et al., 2017). Once the attacker notices a new payment is on the blockchain,
he creates a new Bitcoin transaction providing some uniquely identifiable
piece of metadata, such as the $\mathit{nonce}$ signed using
($\mathit{AK_{prv}}$). RansomClave validates the authenticity and integrity of
this data using the embedded $\mathit{AK_{pub}}$. If the verification is
successful, the encrypted $\mathit{VK_{prv}}$ is unsealed and released to the
victim.

Key Release Steps. The blockchain and digital signature payment verification
scheme is illustrated in Figure 3. We next describe the steps involved in
detail:

Figure 3. Key Release Scheme #1: Blockchain with Online Attacker Payment
Verification Diagram

  * •

The victim follows the payment instructions (\small1⃝) found on the ransom
note (which also contains the bitcoin wallet address and the $\mathit{nonce}$)
and deposits the requested amount of bitcoin into the newly generated wallet
address (\small2⃝). The victim also includes additional metadata consisting of
the $\mathit{AK_{pub}}$, $\mathit{VK_{pub}}$, and $\mathit{nonce}$ into the
blockchain transaction using an OP_RETURN opcode (\small3⃝)222We assume the
victim is provided with detailed instructions to do so or uses an automated
tool to perform the necessary payment steps autonomously and easily.. The
$\mathit{nonce}$ is generated and used along with $\mathit{VK_{pub}}$ to give
the attack a unique identification number. This is essential as it ensures
another victim cannot use a previously obtained signed message hash from the
attacker to trick the enclave into unsealing the $\mathit{AK_{prv}}$.
OP_RETURN is an instruction in the Bitcoin scripting language that allows
users to attach metadata to a transaction and save it on the blockchain. It is
used to allow the victim and the attacker to exchange metadata required to
instruct the enclave to unseal the $\mathit{VK_{prv}}$.

  * •

The attacker periodically monitors the blockchain ledger for the
$\mathit{AK_{pub}}$ in transaction metadata using a payment verification
program. This program searches for the OP_RETURNS opcode in an output’s
scriptPubKey333A locking mechanism placed on an output to prevent others from
spending the bitcoin. (\small4⃝).

  * •

When a transaction containing $\mathit{AK_{pub}}$ is found and the payment is
verified, the attacker employs a cryptography library to create a message hash
using the SHA-256 hash of the metadata provided by the victim (\small5⃝). The
hash is then encrypted with $\mathit{AK_{prv}}$ (\small6⃝) using the standard
RSA signature algorithm to obtain the signature (the RSA encrypted message
hash). This process cryptographically binds the signed hash with the
$\mathit{AK_{prv}}$, thus allowing RansomClave to verify the signature using
the embedded $\mathit{AK_{pub}}$. A new transaction is uploaded on to the
blockchain containing the signed hash and $\mathit{VK_{pub}}$ (\small7⃝).

  * •

The victim periodically searches for new transactions containing the
$\mathit{VK_{pub}}$ (e.g. on blockchain explorer websites, such as
blockchain.com) as per instructions provided in the ransom note. Once a
transaction is found, the victim downloads the signed hash and submits it to
RansomClave along with the original metadata consisting of
$\mathit{AK_{pub}}$, $\mathit{VK_{pub}}$ and $nonce$ (\small8⃝).

  * •

RansomClave performs an ECALL (\small9⃝) to enter the enclave which computes a
hash of the original metadata. The algorithm then decrypts the message
signature with the public key exponent of $\mathit{AK_{pub}}$ to obtain the
hash computed by the attacker. The two hashes are compared and if they match,
RansomClave considers the signature valid. RansomClave then unseals and
releases $\mathit{VK_{prv}}$ to the victim.

###  6.2. Enclave SPV Client

To eliminate the attacker’s online presence, we next propose a fully
_autonomous_ and _offline attacker_ (_trustless_) solution that uses a
Simplified Payment Verification (SPV) client inside the enclave to verify
ransom payments on the blockchain. In this scheme, RansomClave is deployed
with a lightweight blockchain client embedded in it. This allows RansomClave
to successfully verify the victim’s payment on the blockchain and release
$\mathit{VK_{prv}}$ without inputs from the attacker.

Security. The main advantage of this scheme is that it is fully autonomous.
This reduces operational overhead for the attacker, who no longer needs to
maintain an online presence. More importantly, full autonomy means the victim
only needs to trust444We define trust as a utility function where we express
implicit trust by paying would be an expectation that the victim receives
something in return, i.e. the decryption key. the enclave code, whose
behaviour post-payment can be verified up front using attestation. This is a
very attractive property for the attacker potentially, since it can increase
the chances of infected victims paying the ransom. On the downside, this
scheme has arguably weaker security. In fact, enclave interactions with a
blockchain are potentially vulnerable to man-in-the-middle (MitM) attacks (Loe
and Quaglia, 2019). Since the victim has full control over the enclave’s
network connectivity, it can impersonate the blockchain to trick the enclave
into accepting fake blocks. However, mining plausible fake blocks still incurs
an economic cost for the victim555The estimated cost of mining a Bitcoin block
in 2018 was between $2k-$20k depending on the cost of electricity, e.g. see:
https://www.marketwatch.com/story/heres-how-much-it-costs-to-mine-a-single-
bitcoin-in-your-country-2018-03-06.. As we will show, in many cases it is
practical for the attacker to increase this cost such that it is cheaper for
the victim to pay the ransom.

Overview. Currently, there are two primary methods of validating the
blockchain as a client: full nodes and SPV clients. A full node stores a copy
of the entire blockchain with all the transactions, from the genesis block to
the most recently discovered block. In contrast, SPV clients can check if
particular transactions are included in a block through block headers only (80
bytes per block) and a Merkle tree rather than downloading the entire block
(Bünz et al., 2020; Antonopoulos, 2014).

Our second RansomClave key release scheme embeds an SPV Client inside the
enclave, together with an embedded hash of the most recent stable block at the
time the attacker creates the malware. The SPV client inside the enclave then
requests full nodes to supply it with the headers of all blocks since the
block corresponding to the embedded hash, in addition to a Merkle path for the
transaction containing the ransom payment. Once the SPV client is satisfied
the payment has been made, the enclave releases $\mathit{VK_{prv}}$ to the
victim. Although full nodes usually give stronger security than SPV clients,
for RansomClave this is not the case. Since the victim has full control over
the attacker’s network connectivity, it can mine a new block on top of the
current longest Bitcoin chain with a fake transaction containing a supposed
ransom payment. The victim must simply execute the standard Bitcoin proof-of-
work mining algorithm to find a suitable nonce value. Even if the malware
contains a full node, the hash of the genesis block, and the most recent block
at the time the malware is created, the enclave cannot distinguish subsequent
blocks mined by the victim from blocks on the real Bitcoin blockchain.
RansomClave therefore avoids the additional storage and synchronisation
overhead of a full node using an SPV client.

Depending on the size of the ransom, it may be cheaper for the victim to mine
a fake block than pay the ransom. As a counter-measure, the attacker can
require the victim to provide a valid chain with $\mathit{n}$ additional
blocks mined on top of the block containing the ransom payment transaction.
The victim would then need to mine a fake _chain_ of length $\mathit{n}$,
linearly increasing the cost to fake a ransom payment. However, this
mitigation would also require “honest” victims to wait for $\mathit{n}$ blocks
after their payment has been made, and thus may not be practical for very
large ransoms if timely key release is important. In this strategy, the
attacker’s bitcoin address is embedded in the RansomClave binary.
Additionally, the victim must include the unique nonce generated by the
enclave into the bitcoin transaction. RansomClave will use this metadata to
verify the uniqueness of the transaction prior to unsealing the
$\mathit{AK_{prv}}$.

Key Release Steps. As shown in Figure 4, RansomClave executes the SPV client
inside an enclave which in turn connects to a full Bitcoin node. We next
describe the steps in detail: (i) after RansomClave receives the payment
transaction from the victim (\small1⃝), it loads the sealed victim’s wallet
address into enclave and establishes a TCP connection (\small2⃝) to the full
Bitcoin node. (ii) the SPV client sends a $\mathit{getblock}$ message
(\small3⃝) to request a list of blockchain headers from the current block
number and hash embedded in RansomClave when the attacker created it. (iii)
the full node checks transactions and sends a $\mathit{merkleblock}$ message
(\small4⃝), which comprises of block headers of the blocks and the Merkle path
of the matched transaction. (iv) the SPV client (\small5⃝) uses the
$\mathit{merkleblock}$ to verify that the ransom payment transaction is
included in the blockchain and has more than six confirmations. If the
verification is successful, then the $\mathit{VK_{prv}}$ is unsealed and
released.

Figure 4. Key Release Scheme #2: Enclave SPV Payment Client Verification
Diagram (a revised version from (Gervais et al., 2014))

###  6.3. Blockchain Explorer Client

To further improve the security of the SPV client scheme, we propose an
alternative autonomous key release scheme that uses a third-party _blockchain
explorer service_ 666For example, Blockchain.com provides an explorer API at
https://www.blockchain.com/api.. Blockchain explorer services allow clients to
retrieve transaction(s) relating to a particular bitcoin address over a secure
HTTPS channel.

Security. This approach provides security against straightforward MitM
attacks. To subvert it, the victim must convince the blockchain explorer
service to provide fake data to the enclave (or pressure law enforcement to
force them). Even if this is possible, the attacker can combine this scheme
with the previous SPV client scheme such that the victim must still pay the
cost required to mine plausible fake blocks. One downside of this approach is
that it introduces an additional dependency on a third party service. If this
becomes unavailable for any reason post-infection, even an “honest” victim
will no longer be able to retrieve the decryption key $\mathit{VK_{prv}}$ from
the enclave.

Key Release Steps. In this scheme, when RansomClave is executed, the enclave
initiates a TLS connection with the Blockchain explorer API server. We
describe the steps in detail: (i) Once the TLS Handshake is complete, the
server’s digital certificate is retrieved along with information about the
Certificate Authority (CA) that issued it. The digital certificate contains
the public key and the identity of the owner. Additionally, it is signed by
the CA using its private master key. This allows the enclave to use a pre-
seeded store of SSL certificates authorities’ public keys embedded in the
binary to verify integrity and authenticity of the retrieved certificate. (ii)
Once a secure channel has been established, the enclave makes an API call to
the Blockchain explorer API server for transactions and block data relating to
the attacker’s Bitcoin addresses. (iii) The server sends relevant data to the
enclave. If a valid transaction with a minimum of six confirmations is found,
then the enclave releases the $\mathit{VK_{prv}}$. Six confirmations is
generally accepted for most transactions as it represents enough security to
ensure the validity of the transaction.

##  7\. Implementation and Evaluation

We present a proof-of-concept implementation of RansomClave design. Our
prototype implementation operates similarly to WannaCry but executes inside an
Intel SGX enclave. The reactive variant of RansomClave is composed of 2,600
SLOC, while for the proactive variant, the SGX-LKL library OS is also needed
as well as code restructuring for symmetric key generation.

Result: Secret launchToken for the enclave, createEnclave and encryptFile

Input: $\mathit{enclaveId}$;

$\mathit{launchToken}\leftarrow\mathit{secretKey()}$;

if  _createEnclave(launchToken, enclaveId)_ then

$\mathit{VK_{prv}},\mathit{VK_{pub}}\leftarrow\mathit{enclaveGenKey()}$;

$\mathit{VK_{prv}}\leftarrow\mathit{seal(enclaveId},\mathit{VK_{prv}})$;

$\mathit{VK_{pub}}\leftarrow\mathit{save(enclaveId},\mathit{VK_{pub}})$;

else

$\mathit{abort()}$;

$\mathit{VK_{pub}}\leftarrow importKey()$;

for  _file $\mathit{f}$ in getImportantFiles()_ do

$\mathit{EK_{v(f)}}\leftarrow\mathit{generateSymKey()}$ ;

$\mathit{encrF}\leftarrow\mathit{encrypt(f},\mathit{EK_{v(f)}})$;

$\mathit{encrSymKey}\leftarrow\mathit{encrypt(EK_{v(f)}},\mathit{VK_{pub}})$;

$\mathit{fConcat}\leftarrow\mathit{append(encrSymKey,encrF)}$;

$\mathit{delete(f)}$;

$\mathit{save(fConcat)}$;

$\mathit{displayRansomNote()}$;

Algorithm 1 Setup and Execution of RansomClave

Experimental Setup.. All our experiments were performed on Intel® Dual-Core™
i5-7360U CPU with 4GB of RAM, and 3 CPU cores at 2.30GHz. Our system ran
Ubuntu 18.04.5 LTS 64-bit within VirtualBox 6.0. In addition, we performed our
tests using Intel SGX drivers (Intel, 2020b), the Intel SGX SDK (Intel,
2020a), and the open-source SGX-LKL library OS (LSDS Group, 2020).

RansomClave. Algorithm 1 describes the RansomClave program in reactive
variant. In detail, when the malware is executed, its first task is to
initiate the enclave using a launch token and get the buffer sizes required by
the untrusted code to store the $\mathit{VK_{pub}}$ and sealed
$\mathit{VK_{prv}}$. Once the memory is allocated, the untrusted code makes an
ECALL by calling the enclaveGenKey function to generate ($\mathit{VK_{prv}}$,
$\mathit{VK_{pub}}$) pair using 256-bit Elliptic Curve Cryptography (ECC). The
enclave seals $\mathit{VK_{prv}}$ using the data seal key and returns both
keys to the untrusted code. When the keys are in place, RansomClave initiates
the encryption process by calling the getImportanFiles function, which starts
searching for the victim’s files in specified targeted folders and encrypting
each file $\mathit{f}$ using a new $\mathit{EK_{v(f)}}$. Each
$\mathit{EK_{v(f)}}$ is then encrypted using $\mathit{VK_{pub}}$ before it is
permanently deleted. The encryption process is repeated until there are no new
files to encrypt. Finally, a ransom note is displayed to the victim containing
instructions on how to make the payment and unseal $\mathit{VK_{prv}}$ to
restore the files.

Result: Launch enclave, initiate TLS connection, get transaction data, verify
and unseal $\mathit{VK_{prv}}$

Input: $enclaveId$, $hostName$, $portNum$, $walletAddr$, $txId$;

$launchToken\leftarrow secretKey()$;

if  _loadEnclave(launchToken, enclaveId)_ then

$\mathit{SSL\\_Library\\_init()}$;

$\mathit{ctx}\leftarrow\mathit{initCTX()}$;

$\mathit{server}\leftarrow\mathit{openConnection(hostName,portNum)}$;

$\mathit{ssl}\leftarrow\mathit{sslNew(ctx)}$;

$sslSetFd(ssl,server)$;

if  _(sslConnect(ssl) == FAIL)_ then

$\mathit{abort()}$;

else

$\mathit{txResult}\leftarrow\mathit{getTx(hostName,walletAddr,txId)}$;

if  _( $\mathit{verify(txId)}$ == TRUE)_ then

$\mathit{{VK_{prv}}}\leftarrow\mathit{unseal(enclaveId,{VK_{prv}})}$;

$\mathit{release({VK_{prv}})}$;

else

$\mathit{print}$(”Verification failed”);

Algorithm 2 Enclave Launch and Key Release of RansomClave

Proactive RansomClave. We extend our proof-of-concept RansomClave to support
the proactive variant using the open-source SGX-LKL library OS (LSDS Group,
2020), which is designed to run existing unmodified Linux binaries inside
enclaves. SGX-LKL executes the ransomware sample to perform cryptographic
operations on sample victim data (provided as part of a Linux disk image)
inside an enclave. The in-enclave SGX-LKL library OS provides transparent
system calls (e.g. file and network I/O), user-level threading, and signal
handling. Reactive RansomClave is categorised as native since its
cryptographic operations are performed in user-space similar to traditional
ransomware operation.

Blockchain Explorer Client. Algorithm 2 describes the blockchain explorer
services with offline attacker scheme we have implemented within RansomClave.
When RansomClave is executed, the victim is asked to provide a bitcoin address
along with the transaction identifier (txId) of the ransom payment. An enclave
is then loaded using a launch token followed by an OCALL to initiate a TLS
handshake with the Blockchain API server. The getTx message is sent to the
server to request a data block linked to txId and wallet address (walletAddr)
along with number of confirmations. If a valid transaction with at least six
confirmations is received, then the enclave executes the unseal function to
unseal and release $\mathit{VK_{prv}}$.

Operational and Performance Evaluation. We have tested the proof-of-concept
RansomClave operational capabilities on four different SGX-enabled VMs, each
configured to store different types of files as to mimic user’s and
organizational scenarios. In each run, RansomClave encrypted 200 files whose
size ranged from few KB up to 250MB. After the encrypting operations, the user
was shown a ransom note requesting a symbolic sum, and we performed the
necessary steps to perform key release.

Figure 5. Cryptographic operation performance evaluation

Our performance evaluation compares the speed of cryptographic operations for
the two RansomClave variants proposed in this paper, reactive (native) and
proactive (enclave). Figure 5 shows the measurement of cryptographic
operations on files whose size ranges from 15MB to 250MB: we can see that
these operations in the enclave take longer to complete when compared to the
native ransomware. An average of 12.76% overhead for the encryption operation
and 34.05% in decryption operation is observed when the ransomware sample is
executed inside an enclave. Additionally, the results also revealed that the
decryption operation is slower for both the native and enclave ransomware.
This could be potentially due to the implementation of AES in Cipher Block
Chaining mode, which uses cipher in the inverse direction, thus resulting in
slower decryption timings (Rogaway, 2011). However, it is possible to achieve
faster decryption on a system that supports parallel decryption, although this
may result in using more memory due to loading multiple copies of the
encrypted block.

Key Capture. We tested RansomClave’s key management against popular memory
forensics tools and techniques, such as Dumpit, Volatility, and PayBreak
(Kolodenker et al., 2017). Our experiments confirm it is possible to extract
keys from memory for a reactive variant that generates symmetric keys outside
of an enclave. However, it is not feasible for the proactive variant as all
keys are generated inside an enclave.

##  8\. Discussion

RansomClave Pre-Infection Mitigations. Several methods can be applied to
reduce RansomClave’s attack surface. In particular, given that the main focus
of RansomClave is to provide robust key management, some existing mitigations
against ransomware based on static analysis or in-memory analysis techniques
(Berrueta et al., 2019; Moussaileb et al., 2018; Kharaz et al., 2016; Morato
et al., 2018; Kolodenker et al., 2017; Sinha et al., 2018; Cusack et al.,
2018; Bajpai and Enbody, 2020) can detect RansomClave. For instance, binary
inspection of an unknown program could detect cyptographic calls (Gröbert et
al., 2011) or file calls (Subedi et al., 2018). In addition, as shown in
(Bergeron et al., 2009; Schwarz et al., 2020), it is also possible to detect
unknown malicious code and functions in enclave binaries using existing static
analysis techniques, since SGX by default does not provide code
confidentiality. Furthermore, a malicious program can only issue system calls
through the host application: as such, software monitoring system calls could
stop the malware before it can take any destructive actions. A user could also
disable SGX functionality in the system BIOS when not in use, although this is
undesirable. Lastly, system privilege is needed to create an enclave. As such
a strict policy could be enforced on the end user machine to stop RansomClave
execution.

Launch Control. Intel SGX’s launch control whitelist provides a mechanism to
prevent wide-scale abuse of enclaves on systems where it is straightforward to
gain admin privileges. However it requires Intel to proactively monitor and
revoke whitelisted keys that have been compromised or abused, and for systems
to regularly update their local copy of the whitelist. We note however that
openness concerns around launch control have hindered upstream support for SGX
in the Linux kernel. The recent availability of Flexible Launch Control on
newer versions of SGX mitigates some of these openness concerns, but shifts
the burden for securely managing the whitelist to the system owner, and
potentially requires a secure-boot mechanism to protect the whitelist against
an attacker with admin privileges. To the best of our knowledge, other enclave
technologies (e.g. AMD SEV) do not have a hardware vendor-enforced launch
control whitelist.

RansomClave Post-Infection Mitigations. As shown by (Chen et al., 2019;
Nilsson et al., 2020), SGX is vulnerable to software-based side-channel
attacks that, according to Intel, can only be prevented by the developers
themselves777E.g., see:
https://software.intel.com/content/www/us/en/develop/articles/intel-sgx-and-
side-channels.html, i.e., Intel does not consider side channel attacks as part
of the SGX threat model. Hence, victims infected with RansomClave could
potentially extract ransomware’s keys from inside of an enclave via side-
channel attacks.

Extensions. We have considered RansomClave targeting multiple, distinct users.
In an enterprise scenario, rather than creating enclaves on multiple hosts,
RansomClave can set up a single internal SGX server to manage all the
cryptographic keys of the infected hosts on a local network. In this instance,
a clear advantage from an attacker’s perspective is that it simplifies the key
management, particularly if some hosts do not have SGX support. However,
relying on a single machine to generate all keys could impact untrusted code’s
ability to promptly encrypt victim’s files since the encryption key is not
immediately available. Additionally, it also leads to a single point of
failure for the attack.

Ethical Considerations. This research has ethical concerns of dual use
research as our findings could improve the key management of modern
ransomware. However, by commenting on the theoretical risks of future SGX-
based ransomware, we preemptively foster discussions on the possible risks of
SGX-empowered malware that might have been underestimated (Schwarz et al.,
2019). We also omit implementation details to develop a fully-fledged SGX-
based ransomware and key release scheme – this would require cyber-criminals
to perform a non-trivial integration task – and outline mitigation
improvements.

##  9\. Related Work

SGX Malware SGX-ROP is the first attack to enable an enclave malware to
stealthily control its host application independent of the enclave API
(Schwarz et al., 2019). SGX-ROP uses an Intel Transactional Synchronisation
Extensions-based technique to construct a write-anything-anywhere primitive
and a memory-disclosure primitive from inside an enclave. SGX-ROP can bypass
ASLR, stack canaries, and address sanitiser, to run ROP gadgets in the host
context, enabling practical enclave malware. However it does not evaluate the
implications for key release. Marshalek discusses the possibility of
ransomware running inside enclaves, but does not evaluate performance overhead
or the implications for key release(Marschalek, 2018).

Enclave Interaction with Blockchain. Authors (Goyal and Goyal, 2017) proposes
using blockchain to implement one-time programs via cryptographic obfuscation
techniques. (Kaptchuk et al., 2019) expands on this idea by proposing a
protocol that uses an enclave to facilitate secure state management for
randomised multi-step computations. It also introduces the concept of
combining the enclave with public ledgers to condition a program execution on
the publication of particular messages on the ledger, and describes a
practical set of applications leveraging this protocol. In contrast, our
research provides an in-depth analysis of the trade-off and security advantage
between different blockchain-enabled key release schemes.

SGX-based Key Management Frameworks. Some research efforts (Park et al., 2019;
Brenner et al., 2017) explore the application of SGX in a cloud environment to
minimise the disclosure of sensitive data to a third-party hosting and
providing the cloud services. Authors (Park et al., 2019) proposes key-
management frameworks for data-centric networking where an SGX-based key
server, which supports remote attestation and key sealing, generates and
manages data encryption and decryption keys. Neither work addresses the
implications of SGX for ransomware key management.

##  10\. Conclusion

Based on an analysis of key management schemes of existing ransomware, we
observe that most ransomware strains either generate keys on the victim’s
machine, thus leaving them vulnerable to memory key extraction techniques, or
require contact with a C2 server. However, recent work has raised the spectre
of future enclave-enhanced malware that can avoid such mitigations using
emerging support for hardware-enforced secure enclaves. Given the damage
ransomware causes, it is important to understand what new advantages such
ransomware might provide to attackers.

We implement a proof-of-concept called RansomClave to demonstrate the
practicality of such ransomware emerging in the near future. Our evaluation
shows that RansomClave can provide a practical key management solution with
minimal overhead to address known weaknesses in existing ransomware strains.
RansomClave also raises the possibility of autonomous blockchain-based key
release schemes that no longer require victims to trust the attacker to
release decryption keys or the attacker to maintain an online presence,
potentially increasing attacker profitability. We show however that a variety
of mitigation techniques are still possible for a security-aware victim.

###### Acknowledgements.

This research of Alpesh Bhudia is supported by the EPSRC and the UK government
as part of the Centre for Doctoral Training in Cyber Security at Royal
Holloway, University of London (EP/P009301/1).

## References

  * (1)
  * Al-rimy et al. (2018) B. Al-rimy et al. 2018\.  Ransomware threat success factors, taxonomy, and countermeasures: A survey and research directions.  _Comput & Sec._ (2018).
  * Anati et al. (2013) Ittai Anati, Shay Gueron, Simon Johnson, and Vincent Scarlata. 2013\.  Innovative technology for CPU based attestation and sealing. In _HASP '13_.
  * Antonopoulos (2014) Andreas M Antonopoulos. 2014\.  _Mastering Bitcoin: unlocking digital cryptocurrencies_.  O’Reilly Media, Inc.
  * Arnautov et al. (2016) Sergei Arnautov, Bohdan Trach, Franz Gregor, et al. 2016\.  SCONE: Secure Linux Containers with Intel SGX. In _OSDI '16_.
  * Bajpai and Enbody (2020) P. Bajpai and R. Enbody. 2020.  Memory forensics against ransomware. In _Int. Conference on Cyber Security '20_.
  * Bajpai et al. (2018) P. Bajpai, A. K. Sood, and R. Enbody. 2018\.  A key-management-based taxonomy for ransomware. In _APWG eCrime '18_.
  * Bergeron et al. (2009) J. Bergeron, Mourad Debbabi, J. Desharnais, et al. 2009\.  Static Detection of Malicious Code in Executable Programs.  _Int. J. of Req. Eng_ (2009).
  * Berrueta et al. (2019) Eduardo Berrueta, Daniel Morato, Eduardo Magaña, et al. 2019\.  A Survey on Detection Techniques for Cryptographic Ransomware.  _IEEE Access_ 7 (2019).
  * Bhardwaj (2017) Akashdeep Bhardwaj. 2017\.  Ransomware: A rising threat of new age digital extortion.  In _Online Banking Security Measures and Data Protection_. IGI Global.
  * Brenner et al. (2017) Stefan Brenner, Tobias Hundt, Giovanni Mazzeo, et al. 2017\.  Secure Cloud Micro Services Using Intel SGX. In _DAIS '17_.
  * Bünz et al. (2020) B. Bünz, L. Kiffer, Loi Luu, et al. 2020\.  FlyClient: Super-Light Clients for Cryptocurrencies. In _IEEE Symposium on Security and Privacy (SP) '20_.
  * Cartwright et al. (2019) E. Cartwright, J. Hernandez-Castro, and A. Cartwright. 2019\.  To pay or not: game theoretic models of ransomware.  _J. of Cybersecurity._ (2019).
  * Chen et al. (2019) Guoxing Chen, Sanchuan Chen, Yuan Xiao, et al. 2019\.  Sgxpectre: Stealing Intel secrets from SGX enclaves via speculative execution. In _IEEE EuroS &P '19_.
  * Conti et al. (2018) M. Conti, A. Gangwal, and S. Ruj. 2018.  On the economic significance of ransomware campaigns: A Bitcoin transactions perspective.  _Comput. & Sec._ (2018).
  * Costan et al. (2017) V. Costan et al. 2017\.  Secure processors part II: Intel SGX security analysis and MIT sanctum architecture.  _Foundations and Trends in Electronic Design Automation_ (2017).
  * Costan and Devadas (2016) V. Costan and S. Devadas. 2016.  Intel SGX Explained.  _Cryptol. ePrint Arch._ (2016).
  * Cusack et al. (2018) Greg Cusack, Oliver Michel, and Eric Keller. 2018\.  Machine learning-based detection of ransomware using SDN. In _Int. Workshop on SDN-NFV Security '18_.
  * Dargahi et al. (2019) Tooska Dargahi et al. 2019\.  A Cyber Kill-Chain based taxonomy of crypto-ransomware features.  _J. Computer Virology and Hacking Techniques_ (2019).
  * Davies et al. (2020) Simon Davies et al. 2020\.  Evaluation of Live Forensic Techniques in Ransomware Attack Mitigation.  _Forensic Science International: Digital Investigation._ 33 (2020).
  * Gervais et al. (2014) Arthur Gervais, Srdjan Capkun, et al. 2014\.  On the privacy provisions of bloom filters in lightweight bitcoin clients. In _ACSAC '14_. 326–335.
  * Goyal and Goyal (2017) Rishab Goyal and Vipul Goyal. 2017.  Overcoming cryptographic impossibility results using blockchains. In _Theory of Cryptography Conference '17_.
  * Gröbert et al. (2011) Felix Gröbert, Carsten Willems, et al. 2011\.  Automated identification of cryptographic primitives in binary programs. In _Int. Workshop on RAID '11_.
  * Halderman et al. (2009) J Alex Halderman, Seth D Schoen, Nadia Heninger, et al. 2009\.  Lest we remember: cold-boot attacks on encryption keys.  _Commun. ACM_ 52, 5 (2009).
  * Intel (2020a) Intel. 2020a.  _Intel SGX for Linux_.  Retrieved 2020-09-04 from https://github.com/intel/linux-sgx
  * Intel (2020b) Intel. 2020b.  _Intel SGX Linux Driver_.  Retrieved 2020-12-15 from https://github.com/intel/linux-sgx-driver
  * Intel (2020c) Intel. 2020c.  Intel Software Guard Extensions (Intel SGX) Data Center Attestation Primitives: ECDSA Quote Library API.  (2020).
  * Kaptchuk et al. (2019) Gabriel Kaptchuk, Matthew Green, and Ian Miers. 2019.  Giving State to the Stateless: Augmenting Trustworthy Computation with Ledgers. In _NDSS '19_.
  * Keshavarzi and Ghaffary (2020) Masoudeh Keshavarzi and Hamid Reza Ghaffary. 2020.  I2CE3: A dedicated and separated attack chain for ransomware offenses as the most infamous cyber extortion.  _Computer Science Review_ (2020).
  * Kharaz et al. (2016) Amin Kharaz, Sajjad Arshad, Collin Mulliner, et al. 2016\.  UNVEIL: A large-scale, automated approach to detecting ransomware. In _USENIX Security '16_.
  * Kok et al. (2019) SH Kok, Azween Abdullah, NZ Jhanjhi, and Mahadevan Supramaniam. 2019\.  Ransomware, Threat and Detection Techniques: A Review.  _Int. J. CSNS_ (2019).
  * Kolodenker et al. (2017) Eugene Kolodenker, William Koch, Gianluca Stringhini, and Manuel Egele. 2017.  Paybreak: Defense against cryptographic ransomware. In _ASIA CCS '17_.
  * Li et al. (2017) Xiaoqi Li, Peng Jiang, Ting Chen, et al. 2017\.  A Survey on the Security of Blockchain Systems.  _Future Generation Computer Systems_ (2017).
  * Liska and Gallo (2016) Allan Liska and Timothy Gallo. 2016.  _Ransomware: Defending against digital extortion_.  O’Reilly Media, Inc.
  * Loe and Quaglia (2019) A. Loe and E. Quaglia. 2019\.  You Shall Not Join: A Measurement Study of Cryptocurrency Peer-to-Peer Bootstrapping Techniques. In _SIGSAG '19_.
  * LSDS Group (2020) LSDS Group. 2020\.  _SGX-LKL Library_.  Retrieved 2021-02-18 from https://github.com/lsds/sgx-lkl
  * Luo and Liao (2007) Robert Luo and Qinyu Liao. 2007.  Awareness Education as the Key to Ransomware Prevention.  _Information Systems Security_ (2007).
  * Maartmann-Moe et al. (2009) Carsten Maartmann-Moe et al. 2009\.  The persistence of memory: Forensic identification and extraction of cryptographic keys.  _Digital Investigation_ (2009).
  * Marschalek (2018) Marion Marschalek. 2018\.  The Wolf In SGX Clothing.  _Bluehat IL_ (2018).
  * McKeen et al. (2013) Frank McKeen, Ilya Alexandrovich, et al. 2013\.  Innovative Instructions and Software Model for Isolated Execution. In _Int. Workshop on HASP '13_.
  * Mims (2017) Nailah Mims. 2017\.  The Botnet Problem.  In _Comput. Info. Sec. Handbook_.
  * Mofrad et al. (2018) Saeid Mofrad, Fengwei Zhang, Shiyong Lu, and Weidong Shi. 2018\.  A comparison study of Intel SGX and AMD memory encryption technology. In _HASP '18_.
  * Morato et al. (2018) Daniel Morato, Eduardo Berrueta, Eduardo Magaña, et al. 2018\.  Ransomware early detection by the analysis of file sharing traffic.  _J. Netw. Comput. App._ (2018).
  * Moussaileb et al. (2018) Routa Moussaileb, Benjamin Bouget, Aurélien Palisse, et al. 2018\.  Ransomware’s early mitigation mechanisms. In _DIMVA '18_.
  * Nilsson et al. (2020) Alexander Nilsson, Pegah Nikbakht Bideh, and Joakim Brorsson. 2020.  A survey of published attacks on Intel SGX.  _ArXiv:2006.13598_ (2020).
  * Orman (2016) H. Orman. 2016\.  Evil Offspring - Ransomware and Crypto Technology.  _IEEE Internet Computing_ (2016).
  * Park et al. (2019) M. Park, J. Kim, Y. Kim, et al. 2019\.  An SGX-Based Key Management Framework for Data Centric Networking. In _Int. WISA '19_.
  * Ransom (2021) No More Ransom. 2021\.  _No More Ransom_.  Retrieved 2021-03-14 from https://www.nomoreransom.org
  * Rogaway (2011) Phillip Rogaway. 2011\.  Evaluation of some blockcipher modes of operation.  _CRYPTREC for the Government of Japan_ (2011).
  * Sabt et al. (2015) M. Sabt, M. Achemlal, and A. Bouabdallah. 2015.  Trusted Execution Environment: What It is, and What It is Not. In _2015 IEEE Trustcom/BigDataSE/ISPA_.
  * Schwarz et al. (2020) Michael Schwarz, Samuel Weiser, et al. 2020\.  Malware Guard Extension: abusing Intel SGX to conceal cache attacks.  _Cybersecurity_ (2020).
  * Schwarz et al. (2019) Michael Schwarz, Samuel Weiser, and Daniel Gruss. 2019\.  Practical enclave malware with Intel SGX. In _DIMVA '19_.
  * Shepherd et al. (2017) Carlton Shepherd et al. 2017\.  Establishing Mutually Trusted Channels for Remote Sensing Devices with Trusted Execution Environments. In _ARES '17_.
  * Silva et al. (2017) R. Silva, P. Barbosa, and A. Brito. 2017.  DynSGX: A Privacy Preserving Toolset for Dinamically Loading Functions into Intel SGX Enclaves. In _Cloudcom '17_.
  * Sinha et al. (2015) Rohit Sinha, Sriram Rajamani, Sanjit Seshia, and Kapil Vaswani. 2015.  Moat: Verifying confidentiality of enclave programs. In _ACM SIGSAC '15_.
  * Sinha et al. (2018) Sayan Sinha, Manaar Alam, Sarani Bhattacharya, et al. 2018\.  RAPPER: Ransomware Prevention via Performance Counters.
  * Subedi et al. (2018) K. P. Subedi et al. 2018\.  Forensic Analysis of Ransomware Families Using Static and Dynamic Analysis. In _IEEE Security and Privacy Workshops (SPW) '18_.
  * Villalba et al. (2018) Luis Javier García Villalba, Orozco, et al. 2018\.  Ransomware Automatic Data Acquisition Tool.  _IEEE Access_ (2018).
  * Wyke and Ajjan (2015) James Wyke and Anand Ajjan. 2015.  The current state of ransomware.  _SOPHOS. A SophosLabs Technical Paper_ (2015).


* [ADZ17b] Davide Ancona, Francesco Dagnino, and Elena Zucca.  Generalizing inference systems by coaxioms.  In Hongseok Yang, editor, Programming Languages and Systems - 26th European Symposium on Programming, ESOP 2017, volume 10201 of Lecture Notes in Computer Science, pages 29–55. Springer, 2017.  doi:10.1007/978-3-662-54434-1_2.
  * [AMV06] Jirí Adámek, Stefan Milius, and Jiri Velebil.  Iterative algebras at work.  Mathematical Structures in Computer Scienc, 16(6):1085–1131, 2006\.  doi:10.1017/S0960129506005706.
  * [AZ12] Davide Ancona and Elena Zucca.  Corecursive Featherweight Java.  In Wei-Ngan Chin and Aquinas Hobor, editors, Proceedings of the 14th Workshop on Formal Techniques for Java-like Programs, FTfJP 2012, pages 3–10. ACM Press, 2012.  doi:10.1145/2318202.
  * [BKL19] Henning Basold, Ekaterina Komendantskaya, and Yue Li.  Coinduction in uniform: Foundations for corecursive proof search with horn clauses.  In Luís Caires, editor, Programming Languages and Systems \- 28th European Symposium on Programming, ESOP 2019, volume 11423 of Lecture Notes in Computer Science, pages 783–813. Springer, 2019.  doi:10.1007/978-3-030-17184-1\\_28.
  * [BPPR17] Filippo Bonchi, Daniela Petrisan, Damien Pous, and Jurriaan Rot.  A general account of coinduction up-to.  Acta Informatica, 54(2):127–190, 2017.  doi:10.1007/s00236-016-0271-4.
  * [Bro05] James Brotherston.  Cyclic proofs for first-order logic with inductive definitions.  In Bernhard Beckert, editor, Automated Reasoning with Analytic Tableaux and Related Methods, International Conference, TABLEAUX 2005, volume 3702 of Lecture Notes in Computer Science, pages 78–92. Springer, 2005.  doi:10.1007/11554554\\_8.
  * [BS11] James Brotherston and Alex Simpson.  Sequent calculi for induction and infinite descent.  Journal of Logic and Computation, 21(6):1177–1216, 2011.  doi:10.1093/logcom/exq052.
  * [CC77] Patrick Cousot and Radhia Cousot.  Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints.  In Robert M. Graham, Michael A. Harrison, and Ravi Sethi, editors, The 4th ACM Symposium on Principles of Programming Languages, POPL ’77, pages 238–252. ACM, 1977.  doi:10.1145/512950.512973.
  * [Cou83] Bruno Courcelle.  Fundamental properties of infinite trees.  Theoretical Computer Science, 25:95–169, 1983.  doi:10.1016/0304-3975(83)90059-2.
  * [Dag17] Francesco Dagnino.  Generalizing inference systems by coaxioms.  Master’s thesis, DIBRIS, University of Genova, 2017.  Best italian master thesis in Theoretical Computer Science 2018.  URL: http://eatcs.org/images/it/theses/Dagnino_thesis.pdf.
  * [Dag19] Francesco Dagnino.  Coaxioms: flexible coinductive definitions by inference systems.  Logical Methods in Computer Science, 15(1), 2019.  doi:10.23638/LMCS-15(1:26)2019.
  * [DAZ20] Francesco Dagnino, Davide Ancona, and Elena Zucca.  Flexible coinductive logic programming.  Theory and Practice of Logic Programming, 20(6):818–833, 2020.  Issue for ICLP 2020.  doi:10.1017/S147106842000023X.
  * [Dou17] Amina Doumane.  On the infinitary proof theory of logics with fixed points. (Théorie de la démonstration infinitaire pour les logiques à points fixes).  PhD thesis, Paris Diderot University, France, 2017.  URL: https://tel.archives-ouvertes.fr/tel-01676953.
  * [DP02] Brian A. Davey and Hilary A. Priestley.  Introduction to Lattices and Order.  Cambridge University Press, 2 edition, 2002.  doi:10.1017/CBO9780511809088.
  * [FS13] Jérôme Fortier and Luigi Santocanale.  Cuts for circular proofs: semantics and cut-elimination.  In Simona Ronchi Della Rocca, editor, Computer Science Logic 2013, CSL 2013, volume 23 of LIPIcs, pages 248–262. Schloss Dagstuhl - Leibniz-Zentrum fuer Informatik, 2013.  doi:10.4230/LIPIcs.CSL.2013.248.
  * [HNDV13] Chung-Kil Hur, Georg Neis, Derek Dreyer, and Viktor Vafeiadis.  The power of parameterization in coinductive proof.  In Roberto Giacobazzi and Radhia Cousot, editors, The 40th Annual ACM Symposium on Principles of Programming Languages, POPL ’13, pages 193–206. ACM Press, 2013.  doi:10.1145/2429069.2429093.
  * [JKS13] Jean-Baptiste Jeannin, Dexter Kozen, and Alexandra Silva.  Language constructs for non-well-founded computation.  In Matthias Felleisen and Philippa Gardner, editors, Programming Languages and Systems - 22nd European Symposium on Programming, ESOP 2013, volume 7792 of Lecture Notes in Computer Science, pages 61–80. Springer, 2013.  doi:10.1007/978-3-642-37036-6_4.
  * [JKS17] Jean-Baptiste Jeannin, Dexter Kozen, and Alexandra Silva.  Cocaml: Functional programming with regular coinductive types.  Fundamenta Informaticae, 150(3-4):347–377, 2017.  doi:10.3233/FI-2017-1473.
  * [LG09] Xavier Leroy and Hervé Grall.  Coinductive big-step operational semantics.  Information and Computation, 207(2):284–304, 2009.  doi:10.1016/j.ic.2007.12.004.
  * [MPW16] Stefan Milius, Dirk Pattinson, and Thorsten Wißmann.  A new foundation for finitary corecursion - the locally finite fixpoint and its properties.  In Bart Jacobs and Christof Löding, editors, Foundations of Software Science and Computation Structures - 19th International Conference, FOSSACS 2016, volume 9634 of Lecture Notes in Computer Science, pages 107–125. Springer, 2016.  doi:10.1007/978-3-662-49630-5\\_7.
  * [MPW19] Stefan Milius, Dirk Pattinson, and Thorsten Wißmann.  A new foundation for finitary corecursion and iterative algebras.  Information and Computation, page 104456, 2019.  doi:10.1016/j.ic.2019.104456.
  * [San02] Luigi Santocanale.  A calculus of circular proofs and its categorical semantics.  In Mogens Nielsen and Uffe Engberg, editors, Foundations of Software Science and Computation Structures - 5th International Conference, FOSSACS 2002, volume 2303 of Lecture Notes in Computer Science, pages 357–371. Springer, 2002.  doi:10.1007/3-540-45931-6\\_25.
  * [San11] Davide Sangiorgi.  Introduction to Bisimulation and Coinduction.  Cambridge University Press, USA, 2011.
  * [SBMG07] Luke Simon, Ajay Bansal, Ajay Mallya, and Gopal Gupta.  Co-logic programming: Extending logic programming with coinduction.  In Lars Arge, Christian Cachin, Tomasz Jurdzinski, and Andrzej Tarlecki, editors, Automata, Languages and Programming, 34th International Colloquium, ICALP 2007, volume 4596 of Lecture Notes in Computer Science, pages 472–483. Springer, 2007.  doi:10.1007/978-3-540-73420-8_42.
  * [SMBG06] Luke Simon, Ajay Mallya, Ajay Bansal, and Gopal Gupta.  Coinductive logic programming.  In Sandro Etalle and Miroslaw Truszczynski, editors, Logic Programming, 22nd International Conference, ICLP 2006, volume 4079 of Lecture Notes in Computer Science, pages 330–345. Springer, 2006.  doi:10.1007/11799573_25.
  * [Spa16] Régis Spadotti.  A mechanized theory of regular trees in dependent type theory. (Une théorie mécanisée des arbres réguliers en théorie des types dépendants).  PhD thesis, Paul Sabatier University, Toulouse, France, 2016.  URL: https://tel.archives-ouvertes.fr/tel-01589656.
  * [Tar55] Alfred Tarski.  A lattice-theoretical fixpoint theorem and its applications.  Pacific Journal of Mathematics, 5(2):285–309, 1955.
  * [UV17] Tarmo Uustalu and Niccolò Veltri.  Finiteness and rational sequences, constructively.  Journal of Functional Programming, 27:e13, 2017.  doi:10.1017/S0956796817000041.