The type of repository to use when verifying the authentication credentials of a requester. Options supported by SAKA are:

• DB—for the internal database of SAKA

• LDAP—for an LDAP-based directory server either in or outside SAKA

• BOTH—when sites choose to use both types of repositories—DB and LDAP

All requesters of cryptographic services must be defined in the SAKA database or LDAP before they start requesting services.

DB

The Entropy web service allows encryption users to gather true random numbers from the TRSM. This property determines whether SAKA auto-fills a bytebuffer to increase the speed in which random numbers can be returned.

false

The bytebuffer stores true random numbers to be consumed by the Entropy Web service. This property determines how many bytes to recover from the TRSM each time SAKA populates the bytebuffer.

64

Once the cache primer engages, this property determines what is the total number of keys that it may decrypt per domain (in earliest to oldest order).

365

The CryptoCard Service (CCS) Servlet offers two different response types—json and xml. This property determines which response type the web service will use.

json

The default behavior of the CCS getCardCaptureData is to encrypt the credit card data and return a token back to the calling application. By setting this property to true, the plaintext credit card number will also be returned along side the token. When this property is set to true, the getCardCaptureData web service user must have both encryption privilege and decryption privilege.

false

When processing a credit card through CCS, there are a number of tracks available in the card swipe. By default we only process track1 data. By setting this property to true, we will process the swipe's track3 data.

false

The type of cryptographic Hardware Security Module (HSM) used in the SAKA when it is configured with an HSM. The values currently supported by the SAKA are CRYPTOKI—for the HSM from Eracom (now SafeNet) and CryptoServer—for the HSM from Utimaco (now Sophos). This property is superfluous when SAKA is configured to use the TPM.

CryptoServer

When SAKA is configured with a CryptoServer HSM from Utimaco, this property identifies the device address of the HSM with which the SAKA software will communicate. Before the HSM can be used, the device must already be configured using the tools supplied with SAKA. This property is neither used by the SafeNet HSM nor the TPM.

/dev/cs2

When SAKA is configured with a CryptoServer HSM from Utimaco, this property identifies the number of milliseconds to wait before timing out for a connection to the HSM. This property is neither used by the SafeNet HSM nor the TPM.

5000

When SAKA is configured with a CryptoServer HSM from Utimaco, this property identifies the username on the HSM authorized to access cryptographic keys and perform cryptographic functions. Before the HSM can be used, the credentials must already be configured using the tools supplied with SAKA. This property is neither used by the SafeNet HSM nor the TPM.

strongauth

The type of cryptographic hardware module used by SAKA. The appliance supports tpm—when using the Trusted Platform Module and hsm—when using a Hardware Security Module. A SAKA server may only use one type of cryptographic module—it cannot combine the TPM and the HSM within its operations. The choice of the cryptographic module is made during installation and must not be changed. Migrating from the TPM to the HSM, or vice versa, is not currently supported.

tpm

In order to aid debugging, this property allows the application to log parameters as it traverses through different modules. Tracking changes to these parameters as they are processed aids in the debugging process. However, even when this property is set to true, SAKA does not log plaintext sensitive data to log files.

false

The default manufacturer ID used by the CCS. This property was introduced to ease the transition when MFR was added to the web service. Valid values are 0 (for IDTECH), 1 (for UIC), 2 (for MAGTEK), and 3 (for INFINITE).

0

When authenticating a requester within the LDAP directory, the web service application needs to know whether to search for the requester's identity based on the Common Name or the UserID of the requester's LDAP DN. This property defines how SAKA should authenticate requesters within the LDAP directory. Valid values for this property are:

• cn=(the default)

• uid=

NOTE: The value MUST be followed by an equals (“=”) sign for it to be valid.

cn=

The size of the symmetric encryption cryptographic key used to encrypt sensitive data. SAKA currently supports only the AES algorithm with the following sizes:

• 128 bits

• 192 bits

• 256 bits (the default)

This property goes into effect only when a new symmetric key is generated (which may be the next day, week, month, or year depending on the key duration policy in effect in this encryption-domain); existing keys remain unmodified.

256

Time unit for the strongkeylite.cfg.property.encryptionrequestremovaljob.cutoff property. Valid options are days, hours, minutes, and seconds. Relevant only if the strongkeylite.cfg.property.encryptionreqestremovaljob.run property is set to true.

days

The prefix used for reports generated by the SAKA when encryption requests are deleted. The report's name is appended with the date and time of the run and stored in the STRONGKEYLITE_HOME/log directory. This property is referenced only if the strongkeylite.cfg.property.encryptionreqestremovaljob.run property is set to true.

DeletedEncryptionRequests-

In a cluster, an object may have been encrypted by one appliance, but might come into another node again for encryption. To determine if the object already exists, the appliance must HMAC the incoming object against all HMAC keys of the cluster nodes to search for them. This property indicates if the code should generate one HMAC at a time, then search the DB, or generate all HMACs at once and search the DB for each one. Performance will vary depending on node count per cluster, load on the machines, and number of objects encrypted in the cluster. Sites may try both strategies to see if performance improves. Valid values for this property are:

• one—checks HMACs using one node's HMAC key at a time (the default).

• all—checks HMACs after generating HMACs using HMAC keys of all nodes.

one

Size of the symmetric HMAC key used to generate HMACs of sensitive data. SAKA currently only supports the following sizes:

• 224 bits

• 256 bits(the default)

• 384 bits

• 512 bits

Changes to the default values MUST have a corresponding change in the strongkeylite.cfg.property.hmackeyalgorithm and strongkeylite.cfg.property.hmactransform properties.

256

When executing one of the key rotation jobs (Rotate HMACs or Rotate Symmetric Keys), SAKA uses JDBC to communicate with the database instead of JPA. This vastly improves performance and memory utilization for very large databases. To further improve performance of the jobs, updated transactions are batched before being committed.

The strongkeylite.cfg.property.jdbc.dbcommitsize property indicates how many records should be batched before being committed to the database. The fewer the records batched, the lower the risk of having to repeat the entire job again should anything go wrong. However, lower dbcommitsize numbers increase the time taken to complete the job. Depending on the database size and the stability of the environment, consider increasing this number to complete the jobs marginally faster.

NOTE: This value may not be less than1. The application must commit at least one record per batched transaction. Enormous numbers will consume more memory and increase risk of a transaction rollback if something goes awry.

200

When executing one of the key-rotation jobs (Rotate HMACs), SAKA uses JDBC to communicate with the database instead of JPA. This vastly improves performance and memory utilization for very large databases.

The strongkeylite.cfg.property.jdbc.dbprocesssize indicates how many records should be processed by the job in an iteration. The fewer the records fetched, the lower the consumption of memory, but the longer it takes to complete the entire job. However, a very large number will not only increase memory usage, but can increase the risk of a transaction rollback should there be a problem. However, the ultimate performance is determined by number of records encrypted by the specific key being rotated and how frequently the appliance must decrypt the key hierarchy to process the records.

NOTE: This value may not be less than 1. The application must commit at least one record per batched transaction.

10000

The duration in seconds that must pass before SAKA removes symmetric encryption keys from its internal cache.

Since symmetric keys on SAKA are encrypted under multiple layers of asymmetric keys when stored on disk, decrypting them requires the movement of multiple keys into cryptographic hardware modules and expensive cryptographic operations. Therefore, when a key is decrypted by SAKA, it holds the key in an internal cache for the duration of cutoff seconds before deleting them from the cache. Should the symmetric key be required before the cutoff duration has expired, there will be dramatic improvements to performance since the entire chain of keys need not be decrypted again.

The lower the strongkeylite.cfg.property.keyremovaljob.cutoff value, the more secure the environment since keys are cached for a shorter duration. However, too short a duration can impact performance since a key that is flushed from its cache must be decrypted again. Know business transaction characteristics is important for realistically setting this value to balance performance and security. The default value of 300 (5 minutes) leans towards more security.

86400

The frequency in seconds at which the thread executes that removes symmetric encryption keys from cache.

The lower the strongkeylite.cfg.property.keyremovaljob.runfrequency value, the more secure the environment since keys are cached for a shorter duration. Do not set the value less than half of strongkeylite.cfg.property.keyremovaljob.cutoff. For example, if the cutoff property value is 300 seconds (the default), setting the property value of runfrequency to be less than 150 seconds only wastes computing resources as there will be instances when the job will do nothing.

300

When SAKA is configured to use an LDAP-based directory server for managing access control to SAKA services, this property identifies the LDAP group authorized to request decryption services from SAKA. The members of this group must have valid LDAP credentials within the same directory server that can be verified by SAKA.

While SAKA can use any group container in the directory, it is recommended using the value specified here as it will ensure better support. Sites must create this LDAP group container hierarchy before using the web service application.

NOTE: An LDAP user's membership in this group does not authorize them to request encryption or deletion services from SAKA; that requires separate membership in the groups identified in the strongkeylite.cfg.property.ldapencryptiongroup and strongkeylite.cfg.property.ldapdeletiongroup properties, respectively.

cn=DecryptionAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=strongauth,dc=com

When SAKA is configured to use an LDAP-based directory server for managing access control to SAKA services, this property identifies the LDAP group authorized to request encryption services from SAKA. The members of this group must have valid LDAP credentials within the same directory server that can be verified by SAKA.

While SAKA can use any group container in the directory, it is recommended using the value specified here as it will ensure better support. Sites must create this LDAP group container hierarchy before using the web service application.

NOTE: An LDAP user's membership in this group does not authorize them to request decryption or deletion services from SAKA; that requires separate membership in the groups identified in the strongkeylite.cfg.property.ldapdecryptiongroup and strongkeylite.cfg.property.ldapdeletiongroup properties, respectively.

cn=EncryptionAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=strongauth,dc=com

When SAKA is configured to use an LDAP-based directory server for managing access control to SAKA services, this property identifies the LDAP group authorized to request search services from SAKA. The members of this group must have valid LDAP credentials within the same directory server that can be verified by SAKA.

While SAKA can use any group container in the directory, it is recommended using the value specified here as it will ensure better support. Sites must create this LDAP group container hierarchy before using the web service application.

NOTE: An LDAP user's membership in this group does not authorize them to request encryption, decryption, or deletion services from SAKA; that requires separate membership in the groups identified in the strongkeylite.cfg.property.ldapencryptiongroup, strongkeylite.cfg.property.ldapdecryptiongroup, and the strongkeylite.cfg.property.ldapsearchgroup properties, respectively.

cn=SearchAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=strongauth,dc=com

When SAKA is configured to use an LDAP-based directory server for managing access control to SAKA services, this property defines the FQDN of the LDAP directory server, the LDAP service listening port, and the security mode of the LDAP protocol.Valid values of this property may look like:

ldaps://poseidon.strongauth.com:636

...where the ldaps indicates that directory server requires TLS, and is listening over the default LDAPS port (636).

This property MUST be overridden before SAKA is used successfully. If using LDAP, sites are strongly encouraged to use TLS for communications between SAKA and the directory server.

ldap://poseidon.strongauth.com:389

Before an object is replicated to other appliances, the source appliance saves the object metadata in a replication table, and then publishes the object to subscribers. Sometimes, the acknowledgment from subscribers may not reach the publisher. On such occasions, the publisher has a BacklogProcessor (BLP) that attempts to resend the object to subscribers who did not receive it. However, to ensure that the BLP does not get caught in an endless loop sending the objects continuously, it sleeps for the period of seconds specified in this parameter before checking the replication table again to publish objects.

60

When the BLP first wakes up, before it sends the bulk of backlog messages, it sends a small batch of records to test whether the subscribing node is available to send acknowledgments. If no acknowledgments are received from this test, the BLP gives up on this iteration. This property determines the quantity of records send in this test.

25

When a BLP is being started, stopped, other threads may call the messaging service to get an instance. This parameter tells the messaging service how long to wait while the service is undergoing a state change—such as when it might be starting or stopping.

15

An indicator that tells SAKA whether to run the thread that removes metadata objects from its internal cache. The default is to run the thread (true). The other acceptable value for this property is false, in which case objects are cached as long as the server is up and running and memory resources are available.

true

The cryptographic algorithm used for generating the symmetric key that will create HMACs of user-passwords. The key algorithm has a direct dependency on strongkeylite.cfg.property.pwdkeysize and strongkeylite.cfg.property.pwdtransform, so changes to any of these properties must be carried out in tandem. SAKA currently supports the following algorithms for the password HMAC generator:

• HmacSHA224—based on a 224-bit symmetric key

• HmacSHA256—based on a 256-bit symmetric key (the default)

• HmacSHA384—based on a 384-bit symmetric key

• HmacSHA512—based on a 512-bit symmetric key

HmacSHA256

The cryptographic algorithm used to generate HMACs of sensitive data. The transform algorithm has a direct dependency on the strongkeylite.cfg.property.pwdkeyalgorithm and the strongkeylite.cfg.property.pwdkeysize properties, so changes to these three properties must be carried out in tandem. SAKA currently supports the following algorithms:

• HmacSHA224—based on a 224-bit symmetric key

• HmacSHA256—based on a 256-bit symmetric key (the default)

• HmacSHA384—based on a 384-bit symmetric key

• HmacSHA512—based on a 512-bit symmetric key

HmacSHA256

Every authorized URL for the relay web service must be uniquely identified in its own property. The first URL will begin with the numeral 1, the second with 2, and so on. There is no limit to the number of URLs that can be configured. However, the total number of configured URLs must be specified in the property, strongkeylite.cfg.property.relay.authorizedurls.number. Having more URLs than the specified number will prevent the appliance from using any URL that exceeds strongkeylite.cfg.property.relay.authorizedurls.number. Having fewer than the specified number of URLs will cause NullPointerExceptions (NPE) to be thrown. Since DACTool does not provide the ability to add new properties per domain, the URL values must be added in the strongkeylite-configuration.properties file in the /usr/local/strongauth/strongkeylite/etc directory. Please note properties in that file apply to all encryption domains on the appliance.

https://test.authorize.net

In order to relay transactions to payment gateways, the appliance needs to parse XML content that is passed in as a parameter to the web service. The appliance needs to know the number and namespaces of the XML schemas that define the structure of XML being passed in. If new XML schema namespaces are added/deleted to the relay capability, this number must be changed to reflect the actual number of namespaces the appliance must recognize.

6

The relay web service permits the relay of HTTP and SOAP based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of prefixes configured, but each must be unique and must have a corresponding .relay.namespaces.url.N property (see below).

ds

The relay web service permits the relay of HTTP and SOAP-based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of prefixes configured, but each must be unique and must have a corresponding .relay.namespaces.url.N property (see below).

skles

The relay web service permits the relay of HTTP and SOAP-based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of prefixes configured, but each must be unique and must have a corresponding .relay.namespaces.url.N property (see below).

xenc

The relay web service permits the relay of HTTP and SOAP-based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of namespace URLs configured, but each must be unique and must have a corresponding .relay.namespaces.prefix.N property (see above).

http://www.w3.org/2000/09/xmldsig#

The relay web service permits the relay of HTTP and SOAP-based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of namespace URLs configured, but each must be unique and must have a corresponding .relay.namespaces.prefix.N property (see above).

http://strongkey.strongauth.com/SKES201101

The relay web service permits the relay of HTTP and SOAP-based messages to external payment gateways. For SOAP messages to be validated correctly, the appliance must know all namespaces it must expect to process in the relay web service. There may be any number of namespace URLs configured, but each must be unique and must have a corresponding .relay.namespaces.prefix.N property (see above).

http://www.w3.org/2001/04/xmlenc#

By default, the appliance replicates all objects to other appliances in the cluster. However, some sites may choose to not replicate decryption and search requests to other appliances since the information is for audit purposes. Since the original responder server will have it in their database and application server logs, this may be sufficient for some sites. In those situations, setting this property to true will ensure that only essential objects are replicated to other appliances—which means, decryption and search requests are not replicated to other appliances.

The appliance supports two types of Random Number Generators: pseudo-RNG or true RNG. When this property has the value PRNG—the default—random bytes are extracted from the true RNG in cryptographic hardware when the application server is started; the TRNG bytes are used to seed a pseudo-RNG from which all future random bytes are generated. When the value of this property is TRNG, the appliance always uses the cryptographic hardware to generate random bytes. Using the PRNG is orders of magnitudes faster than using the TRNG. However, the appliance always uses the TRNG to generate random bytes for the cryptographic keys; initialization vectors and nonces for authentication are generated by the PRNG.

This property tells SAKA whether to run the key rotation job. If set to true, SAKA will also look at strongkeylite.cfg.property.rotatehmacsjob.runfrequency to determine how frequently to schedule the job. If set to false, the job is never scheduled. To schedule even the on-demand execution of this job (from the DACTool) just once, this property value must be set to true to execute the job.

true

The prefix used for reports generated by SAKA when symmetric keys are rotated and encrypted objects are thus re-encrypted with the new key. The report's name is appended with the date/time and stored in the STRONGKEYLITE_HOME/log directory.

Relevant only if the strongkeylite.cfg.property.rotatesymmetrickeysjob.run property is set to true.

ReencryptedObjects-

Tells SAKA whether to run the key rotation job for a range of records. This allows for smaller sets of records in the database to be re-encrypted ahead of schedule, thereby preventing a huge re-encryption job on the anniversary date of the symmetric key. If set to false, the job is never scheduled; even the on-demand execution of this job (from the DACTool) will fail if this property value is set to false.

true

When a client application requests encryption services from SAKA, the server returns a token to uniquely identify the sensitive data in its internal database. Depending on the value configured for this property, the returned token is either an HMAC of the sensitive data or a pseudo-number. The valid values for this property are hmac—an alphanumeric HMAC, and pseudonumber—a numeric pseudo-number configured per site requirements

Applications that currently store the HMAC in their database must convert that value to the assigned pseudo-number separately—SAKA does not provide any tools to do so other than the AddedPseudoNumbers- report that provides the assigned pseudo-number for a specific HMAC.

pseudonumber

This property defines whether SAKA will use PIN files for reading the Key Custodians' PINs to activate the cryptographic hardware module.

If a site chooses to use unattended SAKA reboots/restarts, this value must be true. If the value is set to false (the default), the KCs must use SetPIN Tool to set their PINs manually for activating the hardware module on the SAKA server. However, they can do this securely even from a remote location. The PINs must be either readable from files or set by the KCs after each SAKA restart/reboot.

Sites are strongly encouraged to leave this property at its default value (false) and use SetPIN Tool to activate the cryptographic module after restarts.

false