A complete backup can be useless in an emergency if the necessary cryptographic keys are missing. A functioning backup concept therefore requires not only the backup of application or database data, but also structured key management. System changes or migrations in particular demonstrate how closely the recoverability of data is linked to existing keys.

Incomplete backups due to missing key components

In practice, it is often assumed that a complete system backup, for example using Backint, Veeam or classic file system methods, automatically includes all components required for recovery.

However, this often fails to take into account that cryptographic keys are not necessarily part of such backups. In many cases, they are stored separately from the actual data, for example in dedicated key files (such as the Secure Store File System – SSFS – in SAP HANA), in Trusted Platform Modules (TPM) on the motherboard or in hardware security modules (HSM). The loss of these key files means that existing backups are formally complete but practically useless.

Case study: HANA database cannot be restored due to missing SSFS key

In a specific use case, an SAP HANA database tenant had to be restored from a backint backup on new hardware. The original tenant had already been deleted as part of decommissioning, the new hardware had been provided, and the backup was complete. Nevertheless, the database could not be restored. The cause lay in the Secure Store File System (SSFS): The associated key file had been overwritten on the source system after the tenant was deleted. There was no copy of this file, and it did not exist on the new system. This meant that the backup could not be decrypted – a restore was impossible.

Special features of SSFS in SAP systems

SSFS is a centrally managed key file with a binary structure that is used in SAP environments for the management of communication certificates, backup keys and application accesses, among other things. Within HANA or ABAP systems, it also stores the keys required to decrypt individual tenants. Even if global encryption has been deactivated in the system, it may still be active due to security updates or configurations at tenant level. The fact that a file such as the SSFS is not automatically versioned or copied leads to complete data loss in the event of an emergency, even though the application data is technically available.

Technical reconstruction through reverse engineering

Since neither snapshots, operating system backups nor alternative SSFS copies existed, conventional recovery was not possible. Only through reverse engineering was it possible to reconstruct the keys. To do this, SAP trace files were analysed, the file structure of the SSFS was evaluated (see pysap.readthedocs.io) and the metadata contained therein was interpreted. On this basis, the original keys could be identified and manually recreated. Only then was it possible to completely restore the database.

Relevance of key management in IT security

The example described illustrates the security significance of cryptographic keys in the context of backup and recovery processes. A backup without the corresponding key is functionally useless – comparable to a safe whose combination has been lost. Therefore, the management and backup of cryptographic keys must be considered equally important as data backup.

Organisational recommendations for operation

• Key files should be backed up regularly, versioned and stored separately from application data.
• The encryption techniques used and the locations where keys are stored must be documented.
• Key files should be treated in the same way as productive data in terms of protection and redundancy.
• Backup validation processes should not only include the data inventory, but also key availability.

A holistic approach to backup management takes into account both the data and the cryptographic keys required for it. Only an integrated security concept can guarantee the availability of systems and data in an emergency.