ADSS LTANS Evidence Server

Features

ADSS LTANS Evidence Server complies with IETF Long-Term Archive & Notary Service (LTANS) specifications, in particular the XML Evidence Record Syntax as defined in RFC 6283. It also supports the Long-Term Archive Protocol (LTAP) which defines the request/response messages for accessing the web service. This interface is implemented in the ADSS Client SDK and therefore available to business appplications for integration using high-level Java and .NET API calls.

ADSS LTANS Evidence Server has been implemented fully in Java EE for multi-platform support, performance and high-availability. ADSS LTANS Evidence Server is the marketing name for ADSS Server when licensed for LTANS services only.

The following highlights just some of its main features.

LTANS specific features

  • Multiple LTANS profiles
    Multiple archive profiles can be configured and assigned to business applications to meet specific business and archiving requirements. The Archive Profiles include:

    • The archive retention period - how long the object will be saved in the archive
    • Is the archive object to be deleted once the retention period is reached
    • Is the archive object to be Notary Signed before archiving and if so which digital signature key/certificate is to be used
    • When to renew the timestamp evidence which protects the archive object from untraceable manipulation (e.g. fixed interval, before expiry of current timestamp or upon operator action)
    • From which Time Stamp Authorities (TSAs) to request timestamps
    • Whether to verify any pre-existing signatures
    • Where to save the archive data object (e.g. DB, file system, online resource, return to business application etc.)

  • Optional signature verification
    As part of the archive process ADSS LTAN Evidence Server can optionally verify any pre-existing signatures (PAdES, CAdES, XAdES) prior to archiving and provide detailed OASIS DSS-X verification reports including PEPPOL signature quality ratings.
  • Optional notary signing
    As part of the archive process ADSS LTANS Evidence Server can optionally notarise and sign the archive object to attest to the processing of the data. Long-term signatures are likely to be applied in a format that suits the ERS structure.
  • Data storage flexibility
    ADSS LTANS Evidence Server can either store Archive Data Objects and ERS Data within its own database or it can return Archive Meta Data and ERS Data to the calling business application for local storage. It can also store the archive object on a local file system or publish to an online URL.
  • Works with multiple TSAs
    ADSS LTANS Evidence Server can interface with one or more TSA for creating the timestamped evidence records. This is configurable on a per archive profile basis. The use of multiple TSA addresses ensures no single point of failure. ADSS TSA Server can be used as an internal TSA server, or any RFC3161 compliant external TSA service can be used.

Performance & resilience

  • Large file handling
    The sending of very large data files for evidence archiving over a web service interface can impact performance due to the overheads of the XML/SOAP encoding. To avoid this, ADSS LTANS Evidence Server allows business applications to included a fully qualified reference to the data file in their API calls to the ADSS LTANS Evidence Server. The ADSS Server then reads the file directly from the identified location avoiding the need to receive it in the request message.
  • High speed operation
    ADSS Server is built using Java EE architecture to provide high performance and scalability. It supports virtualised environments, where CPU and memory can be increased for performance gains.
  • Clustering for high availability
    Multiple ADSS Servers can be used in load-balanced mode to maximise availability across one or more live sites (also use DB replication/clustering and HSM replication for complete infrastructure resilience).

TSA service reporting

  • Service usage reporting
    ADSS LTANS Evidence Service comes with its own management reporting module. This provides the ability to create graphic and tabular reporting on all service requests within a particular date period. The management reports show the number of transactions processed, their results, who the main LTANS clients are, which LTANS profiles were used the most etc. Reports can be exported in PDF and CSV format.
  • Human-readable transaction viewers
    All LTANS request/response transactions are securely logged in the ADSS LTANS Evidence Server database. To support administrator’s review of these transactions, viewers are provided which allow easy analysis of reported trust issues or interoperability checking.

Security & management

  • Hardware Security Module (HSM) support
    FIPS and Common Criteria certified HSMs from SafeNet, Thales and Utimaco can be used to stored and protect all cryptographic keys. Support for other PKCS#11 compliant HSMs can also be provided if required. HSMs can be network, PCIe or USB connected. One or more HSMs, smart cards or USB tokens can be connected to ADSS Server. Another key feature of ADSS Server is the sophisticated auto-reconnect feature that prevents a network issue requiring operator intervention to reconnect a network HSM!
  • Strong crypto algorithm support
    Support for the common cryptographic algorithms is provided including SHA1, SHA-2 (SHA-256, SHA-384, SHA-512), RSA keys up to 4096 bits and ECDSA up to 521 bits.
  • Strong operator authentication
    ADSS Server operators are authenticated using certificates over a mutually authenticated TLS/SSL sessions. The operator's private key and certificates can be on a hardware token for strong multi-factor authentication. ADSS Server performs full certificate validation, including revocation checking, before allowing operators to login to the console.
  • Role based access control
    ADSS Server enables multiple operator roles to be defined. Each operator registered within the system is assigned a role. The role-based access control system enables very fine control over specific service modules that an operator can see and whether they have read, write, edit or delete capability for specific areas of functionality.
  • Dual control
    ADSS Server implements dual control in a flexible and practical way, i.e. dual control can be applied selectively to the important aspects of functionality that are considered most sensitive (such as key generation, policy change etc). When used, an operator's actions are queued for a Security Officer role-holder to review and then approve or reject the action.
  • Business application client authentication and separation
    Business applications are authenticated using TLS/SSL client certificates that are pre-registered in ADSS Server. The application’s access to specific profiles and/or keys is checked as part of the ADSS Server authorisation process when service requests are received.
  • Secure logging with automatic integrity checking
    Cryptographic tamper-resistant logs are provided for all service transaction logs that contain details of requests and responses, all operator activity logs and all system event logs. Advanced reporting, reviewing including searching and filtering of log records is provided. All database log records are cryptographically protected to prevent record modification, deletions or additions.
  • Automatic system integrity checking
    All ADSS Server configurations and settings held in the database are cryptographically protected to prevent record modification, deletion or addition. The system automatically checks these records at pre-defined intervals or on demand to ensure system integrity. A detailed report is produced for any issues that are found.
  • Operator and system management alerting
    Selected system operators can be alerted when certain event conditions occur using email or SMS messages. Management systems can be alerted using SNMP messages or via Syslog (log4j) messages.
  • Easy to install, manage and upgrade
    ADSS Server is feature rich to minimise IT operations time. The simple installation wizard, the automatic checking of system integrity and auto-archiving and alerting ensure the system runs without daily operator involvement. The detailed transaction logs and detailed request/response viewers reduce support desk time in resolving operational issues. ADSS CA Server is also able to run an automatic upgrade process for its settings and data to run the latest version of software.
  • Auto archiving
    To prevent database bloating ADSS Server can be configured to automatically archive database log records. As the archive log files are created and written to disk, they are digitally signed to provide authentication and integrity. The archived files can later be imported, verified and viewed within the transaction log viewer.
  • NTP time monitoring
    ADSS Server features an optional NTP Time Monitor service that regularly checks the operating system time and compares this with one or more configured NTP time servers to detect unacceptable time drift or IT operational errors. Configured time thresholds allow ADSS Server operators to be alerted to time issues and ultimately all trust services can also be stopped automatically.

Request Info

Submit

Sales Inquiries:
+44 (0)800 772 0 442

15

+
Years of Digital Signature
Innovation