Show TOC

Choosing Your Own KeyLocate this document in the navigation structure

Use

The secure storage uses a default key to encrypt the data. This key is constructed internally from system-dependent data. Other systems cannot read the data. The default key therefore provides sufficient security for most applications.

Recommendation

Due to the risks associated with using your own key, we recommend that you use your own key only if you have explicitly determined a particular need for protection.

There is a separate key for the secure storage (also referred to as the “global key” in the system documentation) in a key file. The storage location of the file is defined in profile parameter rsec/securestorage/keyfile.

The key file is a text file, the first line of which consists of a 24 byte hexadecimal value. This is therefore 48 characters from the range of the digits 0-9 and the letters A-F. No spaces are permissible between the characters, and the line must be ended with a line feed. You can generate a valid key with the report RSECKEYGEN.

Example

Example of the permissible content of a key file:

4F93FB349EFA6B5AD82BC3903C39B384AD453E3F34AA341B<line feed>

Procedure

  1. Generate your own key from a pass phrase with the report RSECKEYGEN.

    1. To do this, enter the same text of your choice, of up to 60 characters, in the fields Pass Phrase and Confirm Pass Phrase.

    2. Choose Execute.

  2. Specify the path to the file containing the generated key in the profile parameter rsec/securestorage/keyfile. If you do not use a path prefix, the system looks for the file in the working directory of the application server.

    The profile parameter is dynamically switchable. When you change the value for the profile parameter, the system checks whether the specified key file can be used.

    As soon as a key file is specified, the system uses the key contained in it for new entries to be created. If entries that were created with the default key already exist, the system automatically re-encrypts these at the first read access.

  3. To re-encrypt all existing records, choose the Check Entries tab page in transaction SECSTORE and then Execute.

    When you do this, all entries are accessed to be read, meaning that they are re-encrypted. The message list of transaction SECSTORE does not contain any separate message about this process.

  4. If the SAP system consists of multiple application servers, set the key file identically on all servers. Otherwise, an application server with a set key file could re-encrypt an entry that another application server without a key file is to read.

Recommendations for the Key File

  • Store the key file in a way that all application servers can access it.

  • Use access authorizations to protect the key file at operating system level, so that only the system can read the file.

  • Enter the storage location of the key file in the profile.

  • Perform dynamic changes on all application servers within a short space of time (for example, using the function Switch on all servers).

  • Keep a copy of the key file in a secure location. If you lose the key file, you can no longer access the entries saved in the secure storage with the key.

For performance reasons, the system does not read the key file for every access to the secure storage. If you change the content of the key file, it can take up to 60 seconds before the change takes effect. The dynamic switch of the profile parameter to another key file, on the other hand, takes effect immediately.