Abstract

In order to provide forward security in Cardano, we are in the process of
implementing KES (Key Evolving Signatures).

This CPS describes the practical challenges that result from two conflicting
requirements: secure deletion of old keys ("secure forgetting"), and
reasonable availability of current KES keys in the case of process
restarts.

Problem

Key Evolving Signatures (KES)

Key Evolving Signature (KES) cryptography is a cryptographic signing scheme
where one verification key (VerKey) covers a series of signing keys (SignKey),
such that:

• Any signature created with any of the SignKeys can be verified with the same
  VerKey.
• Future SignKeys can be derived ("evolved") from past ones, but not the other
  way around, up to a maximum number of evolutions.

We use this in Cardano in order to achieve a degree of forward security:

Each individual SignKey is valid for a period of 36 hours ("KES Period"), after
which the SignKey is evolved into a new one, and the old one erased
("forgotten"). From this point onwards, only the new key can be leaked, and
anything signed earlier, with the forgotten key, will still be safe, thus
limiting the impact of a key leak to no more than the last 36 hours.

Secure Deletion

To provide forward security, it is essential that when we erase a KES sign key,
all copies of it disappear from the face of the Earth - only then do we gain
actual forward security, in the sense that, barring cryptographic weaknesses,
it becomes impossible for the key to ever be leaked. Modern mass storage media,
such as SSD, HDD, or CF, however, cannot guarantee secure deletion, and on a
modern OS, RAM is virtualized and may be swapped out to such mass storage media
as well, so KES keys stored in regular RAM may be written to disk even if we
never explicitly serialize them ourselves.

We are addressing this issue using mlocked RAM. Mlocking is a kernel feature
that allows us to mark a small amount of RAM as "not to be swapped out", thus
guaranteeing that the data in it will not be written to disk.

Key Availability

However, we also need some degree of persistence in order to meet the
availability requirement, because Node processes can restart themselves, and in
order to participate in block forging, they need a KES sign key.

Use Cases

Root Compromise

When a machine running a Node is compromised, an attacker will be able to
access all block storage devices, and thus potentially gain access to KES keys
that are, or at some point were, stored on the disk.

Forward security, if done correctly, will limit the impact to the KES sign key
currently in use, since all the older KES sign keys have been securely erased,
and only up to 36 hours worth of signatures have to be invalidated, while
any older signatures remain trustworthy.

Node Restart

A Node process may restart itself, unattended, and when it does, it needs a KES
sign key in order to start forging blocks. On first boot, an administrator will
generate a fresh KES key and sign it using a Cold Key stored on a sufficiently
secured (ideally, air-gapped) machine, and load it into the Node process. This
is not an option for an autonomous Node restart, though, because it always
requires manual intervention and access to the Cold Key.