CommonCryptoLib: Manage PSE files and SSO Credentials (cred_v2)

[JoeGoerlich]

The CommonCryptoLib (CCL) is used when managing the Personal Security Environment (PSE) files and the SSO credential (cred_v2) file.

PSE files are storing for example, a public and private key pair and trusted public key certificates.

The cred_v2 file is managing Single Sign-On for password protected PSE files for operating system users.

 

Please also read the other blogposts of this series:

CommonCryptoLib: TLS protocol versions and cipher suites
CommonCryptoLib: SNC protocol versions and cipher suites
CommonCryptoLib: Manage PSE files and SSO Credentials (cred_v2)
CommonCryptoLib: Certificate Revocation List validation

 

Updates:

---

Personal Security Environment (PSE) files

PSE files store the public and private key pair as well as X.509 certificates in a ASN.1 structure.

A highly detailed overview was given at the Trooper Conference 2018 by Martin Gallo, the slides are published at https://github.com/martingalloar/martingalloar/blob/master/presentations/2018-Troopers/TR18-Hunting-..., the talk is published at https://www.youtube.com/watch?v=N0hxwfkXZik.

Please note: When reading through that very interesting slides, please from page 37 onwards keep in mind that LPS protection with TPM is deprecated as of CCL 8.5.27.

 

PSE versions

There exist two versions for PSEs:

1. v2: stores the PSE's password encrypted,


2. v4: stores the PSE's password as HMAC.

v2 is may be considered more secure and is still the default when generating new PSE files.
However, a v4 PSE can be converted to v2 by running sapgenpse pseconv -2 -p <pse-file>.

 

PSE or PSE for verification (aka. Verify PSE)?

In some cases it is not necessary to store a key pair in a PSE, but only public certificates like the ones from Issuing CAs. For example, if the PSE is only used to validate a server certificate during the handshake a verify PSE could be used.

If a PSE does not contain a key pair it is labeled as a 'verify PSE'. In other words, a verify PSE contains only public information.

 

Adjust the cryptographic algorithms

The key derivation standard, the encryption algorithm and the hash algorithm used for encrypting the content in PSE files can be configured. At time of writing, the CCL uses PBES1-DES3-SHA1 by default which must be considered as weak.

This should be changed to the a more secure one by adjusting the CCL parameter to ccl/pse_encryption_algorithm = PBES2-AES256-SHA256.

Please note: PSE files managed via transaction STRUST are re-encrypted after a system restart. PSE files managed via sapgenpse are re-encrypted when a PSE file is re-created, e.g. during re-keying.

Please note: This is different from the key type, key strength, key length, and hash algorithm used for the certificate signing request. Those are typically adjusted either by the -a and -s attribute of sapgenpse or in the certification request wizard of transaction STRUST.

 

Adjust the number of iterations for hash functions

The number of iterations (how often a hash function is called) to calculate a MAC or a key affects the duration when running dictionary attacks against it. With CCL version 8.5.15 the default was increased from 2048 to 10.000. At time of writing 10.000 can be considered as a good trade off for security vs. a tolerable impact on the performance.

You may check if a different value is set in CCL parameter ccl/pse_encryption_iterations.

 

PIN/password protect all PSE files

Make sure all PSE files are protected by a strong password to prevent private keys from being exfiltrated. Even if the description still says 'PIN', a strong password shall be used instead.

A password can be set using sapgenpse seclogin -r -chpin or in transaction STRUST.

Please note: On ABAP systems credentials are not only stored in cred_v2 files, but also in the ABAP secure storage (transaction SECSTORE).

 

SSO Credential (cred_v2) file

The cred_v2 file stores the PIN/password to decrypt PSE files in a ASN.1 structure.

 

cred_v2 versions

There exist three versions for cred_v2:

1. v0: stores the PSE's password 3DES encrypted with a hardcoded string,


2. v1: stores it wither 3DES or AES256 encrypted with a hardcoded key,


3. v2: makes use of Local Protection Store (LPS), which protects PSE files on Windows from offline brute force attacks. At time of writing LPS provides only on windows systems any security benefit (please remember, LPS with TPM is deprecated).

To make sure at least v1 is used, the SSO credential file must be created with the CCL 8.5.15 or later.
Pysap from https://github.com/SecureAuthCorp/pysap may be used to display the cred_v2 file's current version.

 

Adjust the cryptographic algorithms used for cred_v2

The cred_v2 file is used to store credentials for PSEs which can be accessed by OS users without further authentication. The credentials in cred_v2 file are stored encrypted. By default 3DES is used which must be considered as weak.

The to-be-used encryption algorithm should be configured to a more secure one by CCL parameter ccl/credential_encryption_algorithm = AES256.

Please note: Credentials stored in cred_v2 files are re-encrypted whenever they are written to the cred_v2 file, e.g., by setting a new password for a PSE using transaction STRUST or sapgenpse seclogin -r.

 

Adjust method to determine OS user for SSO

On Linux and UNIX-based systems, the user for accessing PSE with credentials stored in the cred_v2 file can be determined either from the system variable $USER or via OS functions. Since the system variable is not safe from being tampered. By default, the system variable is used.

This should be switched to use the OS functions by the CCL parameter ccl/enable_credential_uid_from_os = 1.

 

 

---

<--Previous

Next -->