ADSS Server v8.3.7
November 2024
This document provides information about Ascertia ADSS Server. Browse through the following topics to find out about new features, product enhancements, improvement, known issues, and limitations for this release.
For information related to tested 3rd party components such as operating systems, database servers, and Hardware Security Modules, please review Ascertia Platform Support, this can be found here: https://www.ascertia.com/product-documentation/platform-support/
Ascertia ADSS Server has successfully completed Common Criteria certification at the EAL4+ Assurance Level. For details, visit https://www.commoncriteriaportal.org/products/index.cfm, under Key Management Systems.
New Features
- TSA Support for additional ISO/IEC Standards (ADSS-18126)
The ADSS TSA Server has been enhanced to comply with the ISO/IEC 18014-1 and ISO/IEC 18014-2 standards for the generation and verification of timestamp tokens. To enable this functionality, users are required to activate the 'ENABLE_ISO_IEC_18014_COMPLIANT_TSA' property within the Advanced Settings section under the TSA module, located in the Global Settings submodule.
- ADSS Server CSP Service (ASAC-1734)
The Ascertia Unity in ADSS Server introduces new modules such as CSP Service, with plans for updating additional services in forthcoming releases. Operators can seamlessly switch between the ADSS Server Classic console and Unity console with a simple click.
Product Enhancements
- Allow ADSS Core to Delete SAM Signed ARQs Regardless of Expiry (ADSS-22862)
The ADSS SAM Service has been enhanced to ensure that Authorized Requests (ARQs) with a "SIGNED" status are deleted prior to their expiry. This improvement effectively reduces database size and enhances overall performance.
User Signing:
- In User Signing, an Authorized Request (ARQ) is used only once for signing, and the user must generate a new Signed Authorization Data (SAD) for each subsequent signing operation.
- The core thread is responsible for removing ARQs with the "SIGNED" status once they reach their expiry, ensuring that expired ARQs are properly cleaned up to maintain system performance.
E-Seal Signing:
In e-Seal Signing, users can extend a transaction by reusing an old SAD and obtaining a new one. The new SAD is linked to the previous one through TransactionID chaining.
- When a user sends the old SAD to extend the transaction, a new ARQ is inserted into the database. The previous ARQ status is updated to "SIGNED," enabling the core thread to identify and delete it once it expires.
- After a successful signature in the sign API, the ARQ request is updated with the "SIGNED" status. However, for E-Seal Signing, the status is updated to "SIGNED_EXT_ALLOWED," indicating that the transaction can be extended.
This approach ensures efficient handling of ARQ records, supports seamless transaction extensions in E-Seal Signing, and optimizes resource management by removing expired ARQs as needed.
- Support for Proxy Settings Across ADSS Server (ADSS-22886)
The ADSS Server now fully supports proxy settings across all modules that make HTTP calls to external resources. While proxy configurations were previously available in most parts of the server, this enhancement ensures that proxy settings are applied uniformly throughout. This update improves connectivity management and strengthens security by consistently routing all HTTP traffic through the configured proxy.
- Support for IAIK PQC v2.0 (ADSS-22341)
The ADSS Server has been upgraded from IAIK PQC v1.3 to the latest IAIK PQC v2.0, ensuring alignment with NIST’s FIPS-203/204 standards. This upgrade enhances cryptographic strength and ensures compliance with the latest post-quantum cryptography standards established by NIST.
- Transitioning from JKS Format to PKCS12 Format (ADSS-18713)
This feature introduces a KeyStore format migration across the ADSS Server, Client SDK, Go>Sign Desktop, Test Tool, AFP, and OCSP Client Tool, moving from the JKS (Java KeyStore) format to the PKCS12 format. PKCS12, a standardized format based on Public-Key Cryptography Standards, enhances compatibility with non-Java applications and provides stronger cryptographic support.
This transition improves security by leveraging the advanced cryptographic algorithms available in PKCS12, which surpass those in JKS. As a result, PKCS12 is now set as the default KeyStore type for ADSS Server, Client SDK, Go>Sign Desktop, Test Tool, AFP, and OCSP Client Tool.
- Support for Multiple Crypto Sources in ADSS SAM Service (ADSS-20858)
This enhancement introduces the ability for operators to configure multiple crypto sources within a single ADSS SAM Service instance, providing load-sharing for user key generation and signing operations. A new configuration option in the ADSS SAM Service profile enables load-sharing for user key generation and signing operations across multiple crypto sources.
- Operators can configure multiple crypto sources within a single ADSS SAM Service profile, allowing for efficient load distribution.
- All configured crypto profiles must be of the same type to ensure compatibility and maintain operational consistency.
- Configured crypto profiles must share the same Master Backup Key to support secure, seamless key management across sources.
- Load distribution across crypto sources enhances the speed and reliability of key generation and signing operations.
- This feature enables scaling cryptographic services through multiple sources without the need to deploy additional ADSS SAM Service instances.
Improvements
- Enhanced APIs in RAS Service and Unity Service (ADSS-22411/ ADSS-22199)
The ADSS RAS Service and ADSS Unity Service have been enhanced to provide greater flexibility, allowing users to receive OTPs through their preferred communication channels. This enhancement improves efficiency and user experience for the Recover Password, Change Email, and Change Mobile Number APIs. Business applications can now dynamically determine whether to send OTPs via SMS, email, or both.
Security Improvements
- Migration from Apache Oltu to Nimbus (ADSS-22393)
ADSS has successfully migrated from Apache Oltu to Nimbus (JOSE + JWT) and OIDC SDK. This migration was essential as Apache Oltu is no longer supported and contains multiple security vulnerabilities. Nimbus offers a more robust, secure, and up-to-date solution for handling JSON Object Signing and Encryption (JOSE), JSON Web Tokens (JWT), and OpenID Connect (OIDC). The transition to Nimbus ensures better security, improved performance, and continued compatibility with modern standards for authentication and encryption in ADSS services.
- 3rd party updates (ADSS-22888)
Third party products supplied as part of ADSS Server have been upgraded.
- Apache Tomcat version upgrade (ADSS-22887)
Apache Tomcat has been upgraded to version from 10.1.25 to 10.1.28.