Migration from 1.10.x to 2.0.0

Database Changes

For convenience, you can use liquibase for your database migration.

For manual changes use SQL scripts:

• PostgreSQL script
• Oracle script
• MSSQL script

Added new columns for cryptography protocol version 4

Following columns were added for keys used in cryptography protocol version 4:

• A new column device_public_keys has been added to the pa_activation table to store device public keys for new cryptography algorithms.
• A new column server_private_keys has been added to the pa_activation table to store server private keys for new cryptography algorithms.
• A new column server_private_keys_encryption has been added to the pa_activation table to configure encryption of private keys.
• A new column server_public_keys has been added to the pa_activation table to store server public keys for new cryptography algorithms.
• A new column shared_secret has been added to the pa_activation table to store share secret for new cryptography algorithms.
• A new column shared_secret_encryption has been added to the pa_activation table to configure encryption of shared secret values.
• A new column master_private_keys has been added to the pa_master_keypair table to store master private keys for new cryptography algorithms.
• A new column master_public_keys has been added to the pa_master_keypair table to store master public keys for new cryptography algorithms.

Following columns were added for dynamic keys used in cryptography protocol version 4:

• A new column biometric_factor_enabled has been added to the pa_activation table to track whether biometric factor is enabled.
• A new column biometric_factor_key has been added to the pa_activation table to store current biometric factor key.
• A new column biometric_factor_key_next has been added to the pa_activation table to store next biometric factor key.
• A new column knowledge_factor_key has been added to the pa_activation table to store current knowledge factor key.
• A new column knowledge_factor_key_next has been added to the pa_activation table to store next knowledge factor key.

Updated Package Names

Package names in Java code have been updated from historical io.getlime to com.wultra. Please update package imports in your source code which uses any io.getlime packages from PowerAuth server.

REST API Changes

Updated Validations in REST API

We have unified validations in PowerAuth server REST API. The error code returned for failed request validations is always ERR0024. As a side effect, the error code ERR0002 used for case when no application ID was set in request is no longer returned.

The validation of requests is now stricter and more complete to ensure data integrity. In case you get the ERR0024 error in your integration with PowerAuth server, please make sure the requests contain all parameters, as seen in REST API documentation available at http[s]://[hostname]:[port]/powerauth-java-server/swagger-ui/index.html.

Removed Recovery Code Functionality

The recovery code feature has been removed from the REST API and services due to its insufficient protection against social engineering attacks.

Following error codes are no longer used:

Error Code	Error Message	Note
ERR0025	Recovery code already exists.	Could not generate recovery code because a valid recovery code already exists.
ERR0026	Too many failed attempts to generate recovery code.	In order to uniquely identify a recovery code, a random recovery code (4x5 characters in Base32 encoding) is generated. In a very unlikely case of a collision, server attempts to generate a new one, at most 10 times. When the new recovery code generation fails 10 times, this error is returned.
ERR0027	Recovery code was not found.	An action was attempted on a recovery code which does not exist.
ERR0028	Invalid recovery code.	Used combination of recovery code and PUK is invalid.
ERR0029	Invalid recovery configuration.	Recovery code configuration is missing or incomplete.

Following endpoints are no longer available:

• POST /rest/v3/recovery/revoke
• POST /rest/v3/recovery/lookup
• POST /rest/v3/recovery/create
• POST /rest/v3/recovery/confirm
• POST /rest/v3/recovery/config/update
• POST /rest/v3/recovery/config/detail
• POST /rest/v3/activation/recovery/create

Updated Operation Data

Callback property signatureType name was changed to authenticationCodeType for operation callbacks. Please check that services processing operation callbacks do not rely on this property, otherwise update the property name.

Audit records for operation callbacks have also been updated to reflect the property change from signatureType to authenticationCodeType.

Configuration Updates

Following property names were changed:

• powerauth.service.crypto.signatureMaxFailedAttempts is now powerauth.service.crypto.authenticationCodeMaxFailedAttempts
• powerauth.service.crypto.signatureValidationLookahead is now powerauth.service.crypto.authenticationCodeValidationLookahead
• powerauth.service.crypto.offlineSignatureComponentLength is now powerauth.service.crypto.offlineAuthenticationCodeComponentLength

Usually there is no reason to change these configuration properties, default values are used in most of the deployments. Please double-check if this change affects existing deployments.

Updated MAC Token Request Timestamp Validations

We have unified validations in PowerAuth server REST API. The error code returned for failed MAC token request timestamp validation is always ERR0024. As a side effect, error codes ERR0030 and ERR0044 used for the case when MAC token request timestamp validation fails are no longer returned.