Set the Encryption Algorithm and Key

Starting with v8.0, the default encryption method is AES-256. If the encryption setting is commented out in the settings file, AES-256 encryption is used. Prior to v8.0, the default encryption method was DES.

Two parameters to consider when selecting an encryption algorithm are the block and key sizes. The larger an algorithm’s block size, the more efficient it is. If an algorithm has multiple key sizes, then the larger the key, the more secure the algorithm.

A key must be generated for the use of encryption. The key must be the same on all the machines that are using the encryption. If the key is changed, then all of the encrypted files are no longer readable. Likewise, if the encryption algorithm is changed, any encrypted files are no longer readable.

As computing power and mathematical and algorithmic knowledge improves, so must encryption standards improve to keep data secure. Starting with v8.5, to move forward with new encryption standards, and to give the customer better control over their encryption standards, new configuration has been added. These improvements are the first phase of enhancements designed to ultimately make Privilege Management for Unix and Linux compliant with new government encryption standards such as FIPS 140-2.

Starting with v8.5, the settings file has been enhanced to incorporate the new keyword enforcehighsecurity<yes/no>.

The iolog and eventlog files are encrypted by their writers and are decrypted by their readers. Policy files must be encrypted manually and are decrypted by their readers. The default is none (no files encrypted).

The settings files must be encrypted manually. An unencrypted copy of the settings file should be kept offline because Privilege Management for Unix and Linux does not provide a decryption program for the settings file. The installation suite does not work correctly if the settings file is encrypted. The unencrypted file needs to be restored before performing an upgrade, or before running pbmakeremotetar or pbuninstall.

For more information, please see the following:

enforcehighsecurity

  • Version 8.0 and earlier: enforcehighsecurity setting not available.
  • Version 8.5 and later: enforcehighsecurity setting available.

This enforces the use of more secure configuration, including using SSL for communications, FIPS 140-2 compliant symmetric encryption algorithms, an enhanced Pseudo Random Number Generator, and the use of the enhanced pb.key format.

Only encryption algorithms that are accredited by FIPS 140-2 can be used for network and file encryption (for example, AES- 128, AES-192, AES-256 and tripledes). All others are deprecated.

Once this has been enabled the following pb.settings need to be configured:

  • ssl yes
  • ssloptions requiressl sslfirst sslverbose
  • sslengine
  • sslservercertfile /etc/pbssl.pem
  • sslcountrycode US
  • sslprovince AZ
  • ssllocality Phoenix
  • sslorgunit Security
  • sslorganization BeyondTrust

You also need to generate a new key using pbkey -F.

enforcehighsecurity yes
enforcehighsecurity yes
  • Policy server hosts
  • Submit hosts
  • Run hosts

sslcountrycode

  • Version 8.5.0 and earlier: sslcountrycode setting not available.
  • Version 9.0.0 and later: sslcountrycode setting available.

Country code to use when creating x509 SSL client certificates. Used by Client Registration.

sslcountrycode US
sslcountrycode US

All hosts

sslprovince

  • Version 8.5.0 and earlier: sslprovince setting not available.
  • Version 9.0.0 and later: sslprovince setting available.

Province to use when creating x509 SSL client certificates. Used by Client Registration.

sslprovince AZ
sslprovince AZ

All hosts

ssllocality

  • Version 8.5.0 and earlier: ssllocality setting not available.
  • Version 9.0.0 and later: ssllocality setting available.

Locality to use when creating x509 SSL client certificates. Used by Client Registration.

ssllocality Phoenix
ssllocality Phoenix

All hosts

sslorgunit

  • Version 8.5.0 and earlier: sslorgunit setting not available.
  • Version 9.0.0 and later: sslorgunit setting available.

Organization unit to use when creating x509 SSL client certificates. Used by Client Registration.

sslorgunit Security
sslorgunit Security

All hosts

sslorganization

  • Version 8.5.0 and earlier: sslorganization setting not available.
  • Version 9.0.0 and later: sslorganization setting available.

Organization to use when creating x509 SSL client certificates. Used by Client Registration.

sslorgunit BeyondTrust
sslorgunit BeyondTrust

All hosts

networkencryption

  • Version 5.1 and earlier: networkencryption setting not available.
  • Version 5.2 and later: networkencryption setting available.

The networkencryption setting specifies one or more encryption settings for encrypting network traffic between hosts. The networkencryption setting uses the following syntax:

networkencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
	<algorithm-2>:<keyfile=/fullpath/data-file-2>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

For successful communications between Privilege Management hosts, each host must use the same encryption algorithm and data file, from which the encryption key is generated. To prevent service interruptions, you can specify multiple algorithms and keys on each host. The hosts resolve discrepancies as follows:

When one Privilege Management program attempts to communicate with another, it uses the first valid algorithm/key pair (encryption algorithm type and encryption key derived from the data file) in the networkencryption setting. The receiving host then attempts to find the correct algorithm/key pair from its networkencryption setting.

Servers attempt to connect the first valid algorithm/data-file pair and, if that fails, the servers then attempt to use other valid algorithm/data-file pairs that are defined in the networkencryption entry in the settings file. We strongly recommend placing the best and newest algorithm/data-file pair as the first entry in the settings file in all servers. Also, the algorithm/data-file pairs must be listed in the same order for all servers.

A client that is not upgraded to the newest algorithm/data-file pair continues to be supported by the policy server host as long as the client’s algorithm/data-file pair is listed as a valid entry in the networkencryption setting. These clients continue to use the settings that are defined by the encryption keyword in the settings file, and the same initial algorithm/data-file pair is used during the initial connection between the two hosts.

If an algorithm/data-file pair is deprecated in the policy server host and it is the first item in the clients’ list of supported algorithm/data-file pairs, then the new clients recognize this change and respond by automatically updating their setting files and backing up the previous settings files. Then the new clients reconnect to the policy server host using an algorithm/data-file pair that is common to both the policy server host and the client. However, if an algorithm/data-file pair is deprecated in the policy server host and the encryption that is used by the policy server host is not supported by the client, then the client’s list must be manually upgraded or the initial connection will fail.

The starting date and ending dates are optional and are applied as follows:

  • If the optional dates are used, then the algorithm/data-file pair is valid only during the specified time period.
  • If a starting date is specified, then the algorithm/data-file pair takes effect at the start of that day; otherwise, the algorithm/data-file pair is active immediately.
  • If an ending date is specified, the algorithm/data-file pair becomes inactive at the end of that date; otherwise, the algorithm/data-file pair never expires. The starting and ending dates are determined using Universal Coordinated Time (UTC) to eliminate ambiguity when the machines involved are in different time zones.
  • If the optional dates are used, then the algorithm/data-file pair is valid only during the specified time period.
  • If a starting date is specified, then the algorithm/data-file pair takes effect at the start of that day; otherwise, the algorithm/data-file pair is active immediately.
  • If an ending date is specified, the algorithm/data-file pair becomes inactive at the end of that date; otherwise, the algorithm/data-file pair never expires. The starting and ending dates are determined using Universal Coordinated Time (UTC) to eliminate ambiguity when the machines involved are in different time zones.

 

If the start and/or end date option is used, administrators must ensure that all hosts use the same validity period. Failure to do so will result in the hosts being unable to communicate with each other, or the hosts using other less desirable algorithm/data-file pairs that are common to both hosts, and the hosts must be synchronized. If all listed algorithms have expired (they have an end date and the end date has expired), then the default network algorithm (DES) is used unless one of the network encryptions is listed or the keyword none is specified with no end date.

This keyword supersedes the older encryption, keyfile, and encrypt keywords. The older settings are converted to the new standard when an upgrade installation occurs.

networkencryption des:keyfile=/etc/pb.key:enddate=2008/05/31 aes-256:keyfile=/etc/pb.key.aes

This example setting directs the new client to use the DES encryption algorithm with the data file /etc/pb.key until May 31, 2008 (UTC). After that date, the new client is to use the AES-256 encryption algorithm with the data file /etc/pb.key.aes.

The default encryption algorithm type is AES-256 and the default data file is typically /etc/pb.key.

  • Policy server hosts
  • Submit hosts
  • Run hosts
  • Log hosts
  • Log synchronization hosts

eventlogencryption

  • Version 5.1 and earlier: eventlogencryption setting not available.
  • Version 5.2 and later: eventlogencryption setting available.

The eventlogencryption setting specifies one or more encryption settings for encrypting event logs. The eventlogencryption setting uses the following syntax:

eventencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
	<algorithm-2>:<keyfile=/fullpath/data-file-2>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

 

When using multiple log servers, all log servers must use the same encryption algorithm and key. Otherwise, they cannot communicate with each other.

When a Privilege Management program attempts to write to an event log, it checks to determine if the event log uses the same algorithm/key pair (encryption algorithm and encryption key derived from the data file) as when the event log was created. If so, the event is written to the event log; otherwise, the old event log is archived and a new event log is started using the first available algorithm/key pair in the eventlogencryption setting. Algorithm/key pairs that are not active can still be used to read existing files.

The starting date and ending dates are optional and are applied as follows:

  • If the optional dates are used, then the algorithm/data-file pair is valid only for writing to files during the specified time period.
  • If a starting date is specified, then the algorithm/data-file pair takes effect at the start of that day; otherwise, the algorithm/data-file pair is active immediately.
  • If an ending date is specified, then the algorithm/data-file pair becomes inactive at the end of that date, otherwise, the algorithm/data-file pair never expires. The starting and ending dates are determined using Universal Coordinated Time (UTC) to eliminate ambiguity when the machines involved are in different time zones.

This keyword supersedes the older encryption, keyfile, and encrypts keywords. The older settings are converted to the new standard when an upgrade installation occurs.

eventlogencryption aes-256:keyfile=/etc/pb.key

This example uses AES-256 encryption algorithm type with the encryption data file that is located in /etc/pb.key.

The default is no encryption.

Log hosts

iologencryption

  • Version 5.1 and earlier: iologencryption setting not available.
  • Version 5.2 and later: iologencryption setting available.

The iologencryption setting specifies one or more encryption settings for encrypting I/O logs. The iologencryption setting uses the following syntax:

iologencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
	<algorithm-2>:<keyfile=/fullpath/data-file-2>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

 

Caution! When using multiple log servers, all log servers must use the same encryption algorithm and key. Otherwise, they cannot communicate with each other, and pbsync cannot merge partial I/O logs.

When a Privilege Management program tries to write to an I/O log, it uses the first valid algorithm/key pair (encryption algorithm type and encryption key derived from the data file) in the iologencryption setting.

However, if the end date is reached and a session is still in place, the same algorithm/key pair is used until the end of the I/O log. If a session is abruptly terminated, then any new partial I/O log that is started will use a new algorithm/key pair. Algorithm/key pairs that are not active can still be used to read existing files.

The starting date and ending dates are optional and are applied as follows:

  • If the optional dates are used, then the algorithm/data-file pair is only valid for writing to files during the specified time period.
  • If a starting date is specified, then the algorithm/data-file pair takes effect at the start of that day; otherwise, the algorithm/data-file pair is active immediately.
  • If an ending date is specified, then the algorithm becomes inactive at the end of that date, otherwise, the algorithm/data-file pair never expires.

The starting and ending dates are determined using Universal Coordinated Time (UTC). This eliminates ambiguity when the machines involved are in different time zones.

This keyword supersedes the older encryption, keyfile, and encrypts keywords. The older settings are converted to the new standard when an upgrade installation occurs.

When a Privilege Management program attempts to read an I/O log, it searches the list of algorithm/key pairs to find the one that corresponds to the target file.

iologencryption des:keyfile=/etc/pb.key/des

The default is no encryption.

Log hosts

reportencryption

  • Version 5.1 and earlier: reportencryption setting not available.
  • Version 5.2 and later: reportencryption setting available.

The reportencryption setting specifies one or more encryption settings for encrypting event log report control files. Each encryption setting consists of the encryption algorithm name, optional key file, optional starting date, and optional ending date using the following syntax:

reportencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>]
	<algorithm-2>:<keyfile=/fullpath/data-file-2>
	[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

When pbguid tries to write to a report control file it uses the first valid algorithm/key pair (encryption algorithm type and encryption key derived from the data file) in the reportencryption setting. When a Privilege Management for Unix and Linux program attempts to read a report control file it searches the list of algorithm/key pairs to find the one corresponding to the target file.

A list of algorithm/key pairs can be provided, but only the first valid entry is used for encryption purposes; all other entries are used as historical references to decrypt the report file. Algorithm/key pairs that are not active can still be used to read existing files.

The starting date and ending dates are optional and are applied as follows:

  • If the optional dates are used, then the algorithm/data-file pair is only valid for writing to files during the specified time period.
  • If a starting date is specified, then the algorithm/key data-file takes effect at the start of that day; otherwise, the algorithm/key data-file is active immediately.
  • If an ending date is specified, then the algorithm becomes inactive at the end of that date; otherwise, the algorithm/key data-file never expires.

The starting and ending dates are reckoned using Universal Coordinated Time (UTC). Doing so eliminates ambiguity when the machines are in different time zones.

This keyword supersedes the older encryption, keyfile, and encrypts keywords. The older settings are converted to the new standard when an upgrade installation occurs.

reportencryption saferplus-32:keyfile=/etc/pb.key.sp32

The default is no encryption.

Log hosts

policyencryption

  • Version 5.1 and earlier: policyencryption setting not available.
  • Version 5.2 and later: policyencryption setting available.

The policyencryption setting specifies one or more encryption settings for encrypting policy files. Each encryption setting consists of the encryption algorithm name, optional key file, optional starting date, and optional ending date using the following syntax:

policyencryption <algorithm>:<keyfile=/fullpath/data-file>

where:

  • algorithm is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.

When pbencode or pbguid attempts to write to a policy file, it uses the algorithm/key pair (encryption algorithm type and encryption key derived from the data file) in the policyencryption setting. When a Privilege Management program attempts to read a policy file, it also uses the algorithm/key pair in the policyencryption setting.

This keyword supersedes the older encryption, keyfile, and encrypts keywords. The older settings are converted to the new standard when an upgrade installation occurs.

policyencryption tripledes:keyfile=/etc/pb.key.3des

We recommend that you keep an unencrypted, offline copy of the policy file in the event you need to manually modify the file.

The default is no encryption.

Policy server hosts

settingsencryptiontype

  • Version 5.1 and earlier: settingsencryptiontype setting not available.
  • Version 5.2 and later: settingsencryptiontype setting available.

The pb.settings file can be encrypted using the encryption algorithm type that is specified in the settingsencryptiontype keyword in the pb.settings file, using the following syntax:

settingsencryptiontype <algorithm>

The settings file is encrypted and decrypted using the default encryption key which is derived from the data file that is located in /etc/<prefix>pb<suffix>.key, and the encryption algorithm type that is defined in the settingsencryption keyword.

 

We recommend you keep an unencrypted copy of the settings file in a secure location.

This keyword supersedes the older encryption, keyfile, and encrypts keywords. The older settings are converted to the new standard when an upgrade installation occurs.

settingsencryptiontype des

In this example, DES is the encryption algorithm type to be used to encrypt the pb.settings file.

The default is no encryption.

  • Policy server hosts
  • Submit hosts
  • Run hosts
  • Log hosts

dbencryption

  • Version 8.5 and earlier: dbencryption setting not available.
  • Version 9.0 and later: dbencryption setting available.

The dbencryption setting specifies the encryption for databases created by Privilege Management for Unix and Linux (e.g. clntregdb, eventdb, svccachedb, logarchivedb, et. al).

The dbencryption setting uses the following syntax:

dbencryption <algorithm-1>:<keyfile=/fullpath/data-file-1>[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] 
<algorithm-2>:<keyfile=/fullpath/data-file-2>[:<startdate=yyyy/mm/dd>:<enddate=yyyy/mm/dd>] ...

where:

  • algorithm-n is the name of the algorithm type.
  • /fullpath/data-file (optional) specifies the full path and file name of the data file, which is used to dynamically derive the encryption key.
  • startdate=yyyyy/mm/dd specifies the earliest date that this algorithm is to be used.
  • enddate=yyyy/mm/dd specifies the latest date that this algorithm is to be used.

Within each encryption setting, each component is separated by a colon (:). Multiple encryption settings are separated by a space.

none

All hosts