Property

skfs.cfg.property.db.keyhandle.encrypt

Explanation

The SKFS database stores a KeyHandle object for every user's registered key in the fido_keys table. A site can choose to additionally encrypt and tokenize this value using the Key Management (KM) module (if available). This property determines whether the FIDO2 Server encrypts the KeyHandle or not.

Default Value

false

Property

skfs.cfg.property.db.keyhandle.encrypt.saka.domainid

Explanation

If the skfs.cfg.property.db.keyhandle.encrypt property is set to true, then this property numerically identifies the KA domain which will be used to tokenize and store the KeyHandle for every registered FIDO key.

Default Value

1

Property

skfs.cfg.property.db.signature.rowlevel.add

Explanation

To protect the integrity of records in the SKFS database, the server generates a digital signature for every row and persists the signature with the row data. This signature is verified to check row data integrity each time this row is retrieved by SKFS. This property determines whether or not all database rows have a digital signature associated with them.

This feature distinguishes SKFS from other implementations. Because the FIDO protocols are designed to be “privacy protecting,” user information is not transmitted within the cryptographic messages of the protocols. The association (binding) of the registered key to a specific credential (username) within a FIDO server happens outside the cryptographic messages. This, unfortunately, may lead to attacks against a FIDO server implementation that go unnoticed by users and service providers (the operators of a website using FIDO protocols).

An attack that uses a structured query language (SQL) injection vulnerability in a web application, or an attack that compromises the Database Administrator (DBA) credential—or any database credential with write access to the database schema—may insert or update critical attributes of users' registered keys. For example, by overwriting a legitimate KeyHandle with the attacker’s own KeyHandle (previously registered on that site), the attacker not only locks out everybody from the site, but allows the themselves to authenticate to anybody's account on that site with his own FIDO Authenticator.

A more insidious attack is where the attacker adds his/her own KeyHandle as an additional registered key to every user's record in the database. This now enables the attacker to authenticate to any user's account on that site, and the legitimate user does not know her account has been compromised—unless she notices an additional “suspicious” looking registered key in their profile.

SKFS generates a digital signature on every record stored in the database at the time of insertion and stores the signature with the record. The server verifies the signature each time the record is retrieved to make sure the record has not been modified since its last use. Authorized updates to the record cause the FIDO2 Server to generate a new digital signature on the modified record and store the new signature with the updated record.

As a result, an attack on the database record in SKFS immediately highlights the compromise; in such a situation, besides writing warning messages in the server’s log, the server refuses to use the compromised record to authenticate the user. Applications may choose to have the user go through another authentication transaction, but this time the application may call on another FIDO2 Server in the cluster to determine if the user’s record is intact on that server. The probability of every cluster node being compromised is small, but is nonetheless possible for an insider attack.

By using a signing key protected by the cryptographic hardware module on the Tellaro, StrongKey ensures that an attacker cannot successfully authenticate into another legitimate user’s account with the attacker’s own registered keys on that site.

While this does reduce the number of transactions per second (TPS) the FIDO2 Server delivers, StrongKey believes that it is more important to be secure when attempting to use a strong authentication protocol lest companies be lulled into a false sense of security.

Default Value

true

Property

skfs.cfg.property.db.signature.rowlevel.verify

Explanation

This property determines whether or not the server will verify row-level signatures. It should only be set to true if the skfs.cfg.property.db.signature.rowlevel.add property is set to true. If the *signature.*.add property is set to false and the *signature.*.verify property is set to true, all authentication transactions will fail since the server will be unable to find a digital signature for the user in her record.

Default Value

true

Property

skfs.cfg.property.db.signature.includecounter

Explanation

When this property is set to true, the SKFS will include FIDO key's counter when generating the signature to be stored in the database.

NOTE: This property must only be set during installation. If it is enabled or disabled in an existing SKFS, signature verification for all current signatures in the database will fail.

Default Value

false

FIDO Server

Property

skfs.cfg.property.fido2.user.sendfakeKH

Explanation

Determines whether fake keyhandles should be sent back to the calling application when they request preauthentication for unregistered users.
Accepted Values: true | false

Default Value

false 

Property

skfs.cfg.property.entropylength

Explanation

SKFS is responsible to generate a challenge (nonce) for all registration and authentication requests. This property determines the length of entropy to be used for generating these challenges.

Default Value

512

Property

skfs.cfg.property.fido2.user.settings.version

Explanation

This property determines the version settings for FIDO2 key registration. This property is present for future-proofing the code.

It is not recommended that this value be changed in this version.

Default Value

1

Property

skfs.cfg.property.fidokeys.flush.cutofftime.seconds

Explanation

To speed up FIDO2 transaction processing, the server temporarily caches registered keys in memory. This property determines the maximum number of seconds a key can remain cached in memory. The longer a key is cached in memory, the more memory is required within the Tellaro. Please keep in mind that once a user has authenticated to SKFS, they are not likely to need the key again for awhile. The default value is useful when a user registers a new key with the server and immediately attempts to authenticate with that key. In that situation, this property is useful to speed up the authentication transaction.

Default Value

30

Property

skfs.cfg.property.fidokeys.flush.frequency.seconds

Explanation

To speed up FIDO2 transaction processing, the server temporarily caches registered keys in memory. This property determines the frequency at which a server thread responsible for flushing keys out of memory wakes up to perform its work.

Default Value

5

Property

skfs.cfg.property.fido.userid.length

Explanation

Determines the maximum allowed length for a credential’s username for a user account. When changing it, never reduce the size once users have started registering themselves. Either reduce it before users start registering, or consider using a different cryptographic domain for different applications that have different needs.

Default Value

32

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

MDS Properties

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

Default Value

Property

Explanation

This property determines the path to MDS file for the FIDO alliance. If the SKFS appliance is operating without internet connection, the MDS file and the ROOT CA certificate that signed the MDS should be downloaded and copied over to each SKFS appliance under /usr/local/strongauth directory.

The blob.jwt file can be downloaded from here

Default Value

Property

Explanation

Default Value

Property

Explanation

This property determines the path to the root certificate that signed the MDS for Fido Alliance. This should be copied to each appliance under the /usr/local/strongauth directory.

The root-r3.crt file can be downloaded from here. 

Default Value

Property

Explanation

The following properties add the ability to provide private digitally signed mds blobs. This property helps define the number of private MDS files you want to add

Default Value

Property

Explanation

This property allows one to assign a unique name to each private MDS file. The count will increase with the addition of more private MDS files. The <name> must be distinct for each private MDS file and is limited to 20 alphanumeric characters.

Example: skfs.cfg.property.mds.private.source.1=test

Default Value

Property

Explanation

This property determines how the private MDS file is loaded. Ensure that the "<name>" matches the value of the property skfs.cfg.property.mds.private.source.<count>=<name>. Accepted Values: url | local. Example:

skfs.cfg.property.mds.private.test.loadmethod=url

Default Value

Property

Explanation

Default Value

Property

Explanation

This property determines the location of the private MDS file if a local option is specified.Example:

skfs.cfg.property.mds.private.test.loadmethod.local= /usr/local/strongauth/skfs/mds/private/mds.txt

Default Value

Property

Explanation

The private MDS files must be been digitally signed in order for the SKFS to use them and the SKFS needs the certificate (public key) to verify the signature before the file can be accepted.

This property determines the location of the truststore that contains the required certificates. When adding the certificate to the truststore, the certificate alias needs to match the <name> identified for a specific private MDS file.

Default Value

Property

Explanation

Default Value

Property

skfs.cfg.property.return.MDS

Explanation

Default Value

Property

skfs.cfg.property.return.MDS.webservices

Explanation

Default Value

Property

skfs.cfg.property.mds.mechanism [deprecated in 4.12]

Explanation

When the value is set to "file", it will try reading the MDSBlob from the location specified in the "skfs.cfg.property.mds.url" and the root ca certificate from the location specified in the "skfs.cfg.property.mds.rootca.url"

Default Value

Property

skfs.cfg.property.apple.rootca.url

Explanation

Default Value

/usr/local/strongkey/skfs/applerootca.crt

Replication

Property

skfs.cfg.property.messaging.blpsleeptime

Explanation

Before an object is replicated to other appliances, the source appliance saves the object metadata in the 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 number of seconds specified in this parameter before checking the replication table again to publish objects.

Default Value

60

Property

skfs.cfg.property.messaging.timediff

Explanation

ZeroMQ normally replicates most objects to all appliances when they are created. However, there are occasions when some leftover objects might remain in the replication table that were either not acknowledged by recipients, or the publisher did not receive the acknowledgment as it was too busy. In these situations, the BLP attempts to replicate the object again as part of the clean up processor. The timediff property is the amount of seconds a record must be in the replication table before the BLP attempts to resend it to other appliances.

Default Value

60

TrustStore/Attestation

Property

skfs.cfg.property.pkix.validate.default.truststore.password

Explanation

Indicates the default password used by the server for its TrustStore containing the root certificates for validating the attestations provided by FIDO registrations.

Default Value

changeit

Property

skfs.cfg.property.pkix.validate.default.truststore

Explanation

Indicates the default TrustStore used for Public Key Infrastructure (X.509) (PKIX) validation.

Default Value

/usr/local/strongkey/skfs/etc/pkix-truststore.jceks

Property

skfs.cfg.property.pkix.validate.method

Explanation

The default mechanism of validating attestation certificates.

Default Value

TrustStore

Property

skfs.cfg.property.pkix.validate

Explanation

This property indicates whether or not attestation certificates must be validated.

Release SKFS 4.12 checks to see if an MDS entry exists for the AAGUID provided in the attestation response and if it finds the chain of trust, it will perform PKIX validation. SKFS does not use the output of this check to determine the signature validity but returns this information to the calling application for it to make the final decision on whether to accept the response or not.

Default Value

true

Property

skfs.cfg.property.retrieve.tld

Explanation

FIDO U2F protocol has a concept of APPID-FACETID verification which involves checking Top Level Domains (TLD). This property indicates whether the TLD list should be fetched from an external URL. This property can only be true if the server can connect to the internet.

Default Value

false

Standalone SKFS

Property

skfs.cfg.property.standalone.fidoengine

Explanation

This property determines if SKFS has been deployed in a standalone setup or as a part of the Enterprise KA deployment.

Default Value

true (for the GitHub release) or false (for the Enterprise Server)

Property

skfs.cfg.property.standalone.signingkeystore.password

Explanation

If skfs.cfg.property.standalone.fidoengine has been set to true, the server may not have access to a hardware so it uses a keystore for storing database row level signing keys. This property indicates the default password used for this keystore.

Default Value

Abcd1234!

Session Controls

Property

skfs.cfg.property.usersession.flush.cutofftime.seconds

Explanation

To speed up FIDO transaction processing, the server caches user session information in memory temporarily. This property determines the maximum time any key can remain in memory.

Default Value

30

Property

skfs.cfg.property.usersession.flush.frequency.seconds

Explanation

To speed up FIDO transaction processing, the server caches user session information in memory temporarily. This property determines the frequency of execution for the FIDO keys clean up job.

Default Value

5

Property

skfs.cfg.property.allow.changeusername

Explanation

Enable users to maintain an authenticated state across domains using an already-authenticated FIDO security key, thereby eliminating the need for more interaction.

Default Value

false

Lightweight Directory Access Protocol (LDAP) Controls

Property

appl.cfg.property.service.ce.ldap.ldaptype

Explanation

Property that identifies what type of LDAP will be used for authenticating service credentials for the domain.
Acceptable values : LDAP | AD

Default Value

LDAP

Property

ldape.cfg.property.service.ce.ldap.ldapadmingroup

Explanation

Identifies the Common Name (CN) for the Administrator group in LDAP/AD.

Default Value

cn=AdminAuthorized 

Property

ldape.cfg.property.service.ce.ldap.ldapcloudmovegroup

Explanation

Identifies the CN for the CloudMoveAuthorized group in LDAP/AD. This property is only used by the file encryption module.

Default Value

cn=CloudMoveAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapdecryptiongroup

Explanation

Identifies the CN for the file DecryptionAuthorized group in LDAP/AD. This property is only used by the file encryption module.

Default Value

cn=DecryptionAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapdnprefix

Explanation

Identifies the Distinguished name (DN) prefix to be used for service credentials.

Default Value

cn=

Property

ldape.cfg.property.service.ce.ldap.ldapdnsuffix

Explanation

Identifies the user suffix to be appended to the user dn.

Default Value

,ou=users,ou=v2,ou=SKCE,ou=StrongAuth,ou=Applications,dc=strongauth,dc=com

Property

ldape.cfg.property.service.ce.ldap.ldapencryptiongroup

Explanation

Identifies the CN for the FileEncryptionAuthorized group in LDAP/AD. This property is only used by the file encryption module.

Default Value

cn=EncryptionAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapfidoadmingroup

Explanation

Identifies the CN for the FidoAdminAuthorized group in LDAP/AD. This property is only used by the FIDO server to perform admin (policy and configurations) operations.

Default Value

cn=FidoAdminAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapfidoauthzgroup

Explanation

Identifies the CN for the FIDO authorizations authorized group in LDAP/AD. This property is only used by the FIDO server to perform pre-authorize and authorize operations.

Default Value

cn=FidoAuthzAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapfidogroup

Explanation

Identifies the CN for the FIDO authorized group in LDAP/AD. This property is only used by the FIDO server to perform patch and delete operations.

Default Value

cn=FidoAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapfidoreggroup

Explanation

Identifies the CN for the FIDO registration authorized group in LDAP/AD. This property is only used by the FIDO server to perform pre-register and register operations.

Default Value

cn=FidoRegAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapfidosigngroup

Explanation

Identifies the CN for the FIDO assertion authorized group in LDAP/AD. This property is only used by the FIDO server to perform pre-authenticate and authenticate operations.

Default Value

cn=FidoSignAuthorized 

Property

ldape.cfg.property.service.ce.ldap.ldapgroupsuffix

Explanation

Identifies the groups suffix to be appended to the group dn.

Default Value

,ou=groups,ou=v2,ou=SKCE,ou=StrongAuth,ou=Applications,dc=strongauth,dc=com

Property

ldape.cfg.property.service.ce.ldap.ldaploadgroup

Explanation

Identifies the CN for the Key Load authorized group in LDAP/AD. This property is only used by the signing module.

Default Value

cn=LoadAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapremovegroup

Explanation

Identifies the CN for the Key remove authorized group in LDAP/AD.

Default Value

cn=RemoveAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapservicegroup

Explanation

Identifies the CN for the Services group in LDAP/AD.

Default Value

cn=Exampleeeee

Property

ldape.cfg.property.service.ce.ldap.ldapsigngroup

Explanation

Identifies the CN for the Sign authorized group in LDAP/AD. This property is only used by the signing module.

Default Value

cn=SignAuthorized

Property

ldape.cfg.property.service.ce.ldap.ldapurl

Explanation

Identifies the LDAP/AD URL for the authentication/authorization of service credentials.

Default Value

ldap://localhost:1389