General Data Protection and Encryption

Input and Data Validation

To protect the application from malicious attacks, DigitalPersona uses the following input and data validation techniques:

  1. All development assumes that any input may be malicious. Therefore, all input data is constrained and sanitized, validating the input type, length, format, and expected range of values.

  2. All messages which are to be sent over a communication channel are signed. The signature is then verified on the other side of the communication channel to check the message integrity.

  3. All stored data is also signed. The signature is verified to ensure the data integrity of the stored data before using it.

Securing Communication Channels

DigitalPersona secures communication channels in order to assure confidentiality and the integrity of the transmitted data. The three communication channels are each secured by different mechanisms.

Client Application -> Client Authentication Service

Communications in this channel use Microsoft Remote Procedure Calls (RPCs), and the ncalrpc protocol sequence with the RPC_C_AUTHN_LEVEL_PKT_PRIVACY flag set, to ensure the confidentiality and integrity of the transmitted data.

For more about RPC, see http://msdn2.microsoft.com/en-us/library/ms950395.aspx

Client Authentication Service <- -> Server

For this channel, DigitalPersona uses the Distributed DigitalPersona Confidential Information Component Object Model (DCOM) with Kerberos Mutual Authentication and the RPC_C_AUTHN_LEVEL_PKT_PRIVACY flag set.

For more about DCOM Architecture see http://msdn2.microsoft.com/en-us/library/ms809311.aspx

Server Biometric Authentication Service <- ->AD or AD LDS Database

This communication channel uses the Microsoft Active Directory Service Interfaces (ADSI).

For more about ADSI, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/ adsi/ active_directory_service_interfaces_adsi.asp

Sensitive Data

DigitalPersona practices rigid adherence to the following rules in order to protect sensitive data such as user credentials and secrets (protected resources).

Protecting Sensitive Data in Process Memory

  • Sensitive data is never kept in memory unless it cannot be avoided.

  • When it is necessary to write sensitive data into memory, it is always obfuscated with a proprietary implementation of XTEA (Extended Tiny Encryption Algorithm) with a per-process generated 128-bit key.

  • Sensitive data is also obfuscated with the XTEA algorithm whenever it leaves DigitalPersona's binary (dll) border.

Protecting Sensitive Data in Communication Channels

Messages that include sensitive data are always encrypted and signed before sending them over any communication channel. The signature is verified on the other end of the channel before the data is used.

Protecting Sensitive Data in Persistent Storage

  • Encryption is used on all sensitive data before storing it in persistent storage to assure data confidentiality.

  • Sensitive data is always signed before storing it in persistent storage and the signature is verified before it is used to assure data integrity.

Protecting Fingerprint Data in Persistent Storage

  1. A DigitalPersona Server Key is randomly generated when DigitalPersona Server is installed and stored on a platform in such a way it can be accessed by the DigitalPersona Server only.

  2. Fingerprint data is encrypted using the DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage; (Active Directory for an AD deployment or an LDS database for an LDS deployment).

  3. Fingerprint data is signed with the user identity utilizing the DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage (Active Directory in case of AD deployment or LDS database in case of LDS deployment). This signature is verified before fingerprint data is used to assure data integrity.

  4. The attribute where fingerprint data is stored in Active Directory or LDS database is marked as confidential. This means only Domain Administrators can read encrypted data from this attribute.

    For more about confidential attributes, see https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential

  5. A DigitalPersona Client Service Key is randomly generated when DigitalPersona Client software is installed and stored on a platform in such a way it can be accessed by DigitalPersona Client Service. DigitalPersona Client Service Key is not exportable.

  6. Fingerprint data is encrypted using the DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on the Client computer (registry).

  7. Fingerprint data is signed with the user identity utilizing the DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on the Client computer (registry). This signature is verified before the fingerprint data is used to assure data integrity.

  8. The registry where fingerprint data is stored has ACL so only Local SYSTEM account has read access to it. This means only Local Administrators can read encrypted fingerprint data from the registry.

  9. The administrator has the ability to disable Local Caching over GPO, ensuring that fingerprint data won't be stored on the local computer.

Protecting OTP Data in Persistent Storage

  1. DigitalPersona Server Key is randomly generated when DigitalPersona Server is installed and stored on a platform in such a way it can be accessed by DigitalPersona Server only.

  2. OTP data (OTP SEEDs) is encrypted using the DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage (Active Directory in case of AD deployment or LDS database in case of LDS deployment).

  3. OTP data is signed with the user identity utilizing the DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage (Active Directory in case of an AD deployment or an LDS database in case of an LDS deployment). Signature is verified before OTP data is used to assure data integrity.

  4. The attribute where OTP data is stored in Active Directory or LDS database is marked as confidential. This means only Domain Administrators can read encrypted data from this attribute.

    For more about confidential attributes, see https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential

  5. DigitalPersona Client Service Key is randomly generated when DigitalPersona Client software is installed and stored on a platform in such a way it can be accessed by DigitalPersona Client Service. DigitalPersona Client Service Key is not exportable.

  6. OTP data is encrypted using DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on Client computer (registry).

  7. OTP data is signed with the user identity using the DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on the Client computer (registry). This signature is verified before OTP data is used to assure data integrity.

  8. The registry where OTP data is stored has ACL so only the Local SYSTEM account has read access to it. This means only Local Administrators can read encrypted OTP data from registry.

  9. The Administrator has the ability to disable Local Caching over GPO to ensure that OTP data won't be stored on the local computer.

Protecting Password Manager Data in Persistent Storage

On the Server

  1. A DigitalPersona Server Key is randomly generated when DigitalPersona Server is installed and stored on a platform in such a way it can be accessed by DigitalPersona Server only.

  2. Password Manager data is encrypted using Unified User Key (UUK, 2048-bit RSA key) before storing it in persistent storage.

  3. UUK is randomly generated per user and stored in persistent storage protected (encrypted) with user's Windows Password.

  4. Then Password Manager data is encrypted using the DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage (Active Directory in case of AD deployment or LDS database in case of LDS deployment).

  5. Password Manager data is signed with user identity using DigitalPersona Server Key (2048-bit RSA key) before storing it in persistent storage (Active Directory in case of an AD deployment or an LDS database in case of an LDS deployment). Signature is verified before OTP data is used to assure data integrity.

  6. The attribute where Password Manager data is stored in Active Directory or in the LDS database is marked as confidential. This means only Domain Administrators can read encrypted data from this attribute.

    For more about confidential attributes, see https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential

On the Client

  1. The DigitalPersona Client Service Key is randomly generated when DigitalPersona Client software is installed and stored on a platform in such a way it can be accessed by the DigitalPersona Client Service. The DigitalPersona Client Service Key is not exportable.

  2. Password Manager data is encrypted using Unified User Key (UUK, 2048-bit RSA key) before storing it in persistent storage on a Client computer (local cache in registry).

  3. A UUK is randomly generated per user and stored in persistent storage protected (encrypted) with user's Windows Password.

  4. Password Manager data is encrypted using the DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on the Client computer (local cache in registry).

  5. Password Manager data is signed with the user identity using the DigitalPersona Client Service Key (2048-bit RSA key) before storing it in persistent storage on the Client computer (registry). This signature is verified before Password Manager data is used to assure data integrity.

  6. The registry where Password Manager data is stored has ACL so only the Local SYSTEM account has read access to it. This means only Local Administrators can read encrypted PM data from the registry.

Encryption

DigitalPersona protects sensitive data using the Microsoft Crypto API and the Microsoft AES Cryptographic Provider v2.0.

For sensitive data protection in persistent storage, such as the AD or AD LDS database, we encrypt data using the AES algorithm with a 256-bit key length. The key is only accessible to the DigitalPersona Authentication Service.

Sensitive data in persistent storage is also signed with the owner user object GUID using the RSA Signature algorithm with a 2048-bit key length. The key pair is only accessible to the DigitalPersona Authentication Service.

For protecting and ensuring the integrity of sensitive data in messages sent over communication channels, DigitalPersona uses various algorithms depending on the communication channel as discussed in Securing Communication Channels.

Session Management

DigitalPersona uses transaction-based session management. The user provides credentials which are only considered valid during the current transaction.

Account Lockout

Account lockout is a feature of security (in DigitalPersona AD only) that disables a user account when a certain number of failed authentications occur within a preset time period. This prevents attackers from brute-force attempts to foil the authentication system.

When the specified number of failed authentications exceeds the Account Lockout Threshold, the account will be locked and any attempt to access protected resources for this account will be rejected. To unlock the user account, one has to be assigned the DigitalPersona Administrator role.

The Account Lockout Threshold, Account Lockout Duration and the Reset Interval can be modified by the Domain Administrator (or Active Directory delegated user) in the Group Policy Object governing a specified group of users.