Skip to Content
Author's profile photo Former Member

Data Encryption Comparison between HANA 1.0 and HANA 2.0

Recently, I was dealing with the challenge whether I should implement server-side data encryption (with focus on data and logs) on our SAP HANA 1.0 SPS 12 system or I should wait with the implementation until the upgrade to latest release of SAP HANA, which is currently HANA 2.0 SPS 00.

For this purpose, I was analyzing the question what is possible to implement in SAP HANA 1.0 and HANA 2.0, regarded from a data and log encryption perspective. As many others might be exploring this, I wanted to share my findings with you.

In general, SAP HANA copies data from memory to disk at regular savepoints and additionally captures all data changes in redo log entries. This ensures that the database can be restored to its most recent committed state after failure. However, this data remains unencrypted on disk of the HANA server and should be saved from unauthorized access at OS level from a security perspective. This is when encryption comes into play.

The following table gives an overview of a direct comparison between SAP HANA 1.0 and SAP HANA 2.0 SPS 00 and will be used as reference in the following:

HANA 1.0 SPS12 HANA 2.0
Cryptographic Service Provider required Yes Yes
Data Volume Encryption Yes Yes
Encryption Keys stored in SSFS Yes Yes
Renewal of (Page) Encryption Keys recommended Yes Yes
Redo Log Encryption No Yes (since SPS 00)
Memory Encryption No No
Backup Encryption No Yes (since SPS 01)
Database Trace Encryption No No
Root Key Backup possible/required No Yes
Password for Root Key Backup possible No Yes
Import of root key e.g. after disaster recovery No Yes


Similarities between SAP HANA 1.0 and SAP HANA 2.0:

As a prerequisite for encrypting the data volume SAP HANA requires the availability of a cryptographic service provider. This is by default and recommended the CommonCryptoLib. The encryption of the data volume is possible for both. In this case, a persistence root encryption key must be created. This key is used to encrypt the page encryption key and is stored in SSFS and automatically retrieved from there. For instance, this ensures that no administrator action is needed for startup.

Once changes to data are moved from memory to disk, the relevant pages are automatically encrypted during the write operation. These pages are encrypted by using a 256-bit “page encryption key”. From a security point of view this page encryption key (and encryption keys in general) should be renewed periodically.

Both SAP HANA 1.0 and SAP HANA 2.0 do not support the encryption of database traces. In addition, SAP HANA 1.0 and SAP HANA 2.0 SPS 00 do not support the encryption of data backups (supported with SAP HANA 2.0 SPS 01): For encrypting data backups a suitable third-party tool must be used with the backint interface. Same applies to the database trace, which are not encrypted either. A general recommendation is to avoid large tracing files on OS level.


Differences between SAP HANA 1.0 and SAP HANA 2.0:

Finally, Since SAP HANA 2.0 SPS 00 redo log encryption is possible. Once it is activated log entries are encrypted using an 256-bit long root key. Consider that this encryption key is another key than for data volume encryption and must be maintained separately.

Since SAP HANA 2.0 SPS 01 backup encryption is supported natively and can be enabled for all kinds of backup types. Same applies to the key as mentioned above, it is an additional one and must be maintained separately.

There is the possibility/need to backup the encryption root keys with HANA 2.0 e.g. for redo log encryption (since SPS 00), backup encryption (since SPS 01). In a disaster scenario, it may be necessary to provide these encryption root key backups for recovery. Having lost the encryption root key backups may lead to an unrecoverable situation. Therefore, performing an encryption root key backup is highly recommended. As a consequence, each time changing an encryption root key requires a new root key backup. In addition, the root key backup is secured by a password. This password must be set before the actual root key backup is performed.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Puneet Dhote
      Puneet Dhote

      Good One ...Thanks for sharing !!!

      Author's profile photo Martin Kittel
      Martin Kittel

      Hi Sebastian,

      this is a very nice overview. Thanks for taking the time to put this together!

      Maybe just two things for clarification: 'Root Key Password possible' should probably better read 'Password for Root Key Backup possible' to be more precise. The root encryption keys in the SSFS have always been protected by the SSFS master key and the new functionality in HANA 2 is specific to the new root key backup.

      As you correctly wrote with the possibility to change root encryption keys in HANA 2 it has become necessary to back up the root encryption keys in the SSFS separately. In SPS12 (and lower) there is no need for such a backup.

      Best wishes,



      Author's profile photo Former Member
      Former Member
      Blog Post Author


      Hi Martin,

      thanks for the rewording hint. I updated the blog with the preciser wording.

      Thanks and best