Securing Cryptographic Components ​

Overview ​

AlphaTrust e-Sign™ relies on Microsoft's CryptoAPI 2.0 libraries, as implemented on Windows Server, for low-level cryptographic operations. AlphaTrust e-Sign™ uses a server-side digital certificate / private key set for its server digital signature operations. The use of client side digital certificates / private key sets for client side digital signing is also supported in addition to the normal server side signing. Note: signing, in this case, refers to digital signature operations, which are not visible to the user, and does not refer to the electronic signature which is visible to the user.

AlphaTrust e-Sign™ can use any industry standard RSA X.509v3 digital certificate / private key pair. By default, licensed AlphaTrust e-Sign™ installations are issued a key set by AlphaTrust. This key set is typically installed into the localMachine\MY CryptoAPI store, much like an SSL key set. AlphaTrust e-Sign™ is capable of using key sets stored in the localMachine\My store, the <service account>\MY store or directly from a PFX (PKCS#12) file. You may use a key set issued by any certification authority as long as the full CA certificate chain is installed to the proper localMachine or service account certificate stores. The public key should be an RSA 1024 bit or higher key. Details on configuring AlphaTrust e-Sign™ to use a particular issuer's certificate or a particular individual certificate are located in the ProntoConfig.ini file.

A second key set may be used for creating embedded PDF digital signatures that can be verified by stand alone Adobe Reader® or Adobe Acrobat®. Please see the Developers Guide for more information on using this feature. AlphaTrust, in partnership with Adobe, enable as an option, the embedded of secure, trusted, time-stamped digital signature within PDF documents. AlphaTrust participates in the Adobe Certified Document Service system and can embed secure, time-stamped, trusted digital signatures. This embedded digital signature serves to authenticate the origin of the document as well at the data integrity of the document. PDF documents with embedded CDS digital signatures can be verified on a stand alone basis using Adobe Acrobat or Adobe Reader, even decades into the future. The use of CDS digital signatures requires the use of a supported Hardware Security Module, such as the SafeNet Luna SA, and the use of a CDS-issued private-public key set. Please contact AlphaTrust for more details on implementation of this capability. These CDS digital signatures are compliant with EU PAdES and ETSI standards for long-term document validation (LTV enabled).

For maximum security and performance, you may wish to use a hardware security module (HSM). You should use an HSM that is capable full CryptoAPI 2.0 support. Your private key may be generated on-board the HSM and the certificate request may be submitted to the certification authority of your choice. Once the signed certificate is installed in the HSM, you should configure AlphaTrust e-Sign™ to use it (see ProntoConfig.ini). Since this key is used by AlphaTrust e-Sign™ only for digital signature operations and not data encryption, it is not necessary to have a private key backup. An approved HSM is required for embedded CDS digital signatures (see above).

Revocation Checking ​

AlphaTrust e-Sign™ supports five levels of certificate revocation checking. Revocation checking is only applied to client-side digital certificates, as the server certificate is assumed to be trusted. Therefore, these settings (configured in ProntoConfig.ini) only apply when using client-side digital signing:

• 0 - No trust or revocation checking is done at all.

• 1 - Check trust and revocation on the client certificate only. If no revocation pointer is in the certificate, then treat the certificate as not revoked.

• 2 - Check trust and revocation on the client certificate only. A valid CRL must be available locally or the revocation information must be retrievable online from information in the certificate.

• 3 - Same as 1 but checks all certs in the chain up to but not including the root cert. The root cert is always assumed to be trusted.

• 4 - Same as 2 but checks all certs in the chain up to but not including the root. WARNING: all subordinate CA certs in the chain must have local valid CRLs or retrievable revocation information or the check will fail.