Digital signature library for Android

Digital Signatures can be considered as the electronic equivalent of a physical signature with ink on paper. However an electronic signature also provides certain advantages over an ink-and-paper signature. It can secure and protect a digital document by creating a signing fingerprint uniquely identifying a sender. The recipient of the document and signature confidence of the sender's identity validates that the document has not been altered by anyone else since it was signed.

Some of these main advantages are:

Authentication A digital signature allows precise identification of who created/signed a document. It can be safely assumed that when a signature is valid, you know who signed it.

Integrity A digital signature allows users to easily validate whether the contents of a document were changed after it was signed.

Non-repudiation A digital signature ensures that the signer cannot deny that they signed the document.

Apryse SDK benefits include:

• Import signature fields via XFDF/FDF
• Export signature data via XFDF/FDF
• Built-in support for PKI signing (and PFX digital certificates)
• Support for custom signature handlers
• Sign with images, ink annotations, or entirely custom appearances

A digital signature will generate a unique value (hash / digest) from the combination of the document data and private key. During verification, the document data and public key is used to generate the exact same unique value (hash / digest). If these unique values match then we can say the data has not been altered and the digital signature is valid.

An e-signature is an annotation that appears in the document but has no additional identifiable information about the creator other than an author field which can be altered.

A digital signature on the other hand uses a cryptographic algorithm to uniquely identify the author and any alterations to the document including the annotations or e-signature would result in an invalid digital signature validation.

A cryptographic digital signature can use a certificate authority (CA) to act as a trusted third party between a sender and other parties.

The CA will issue a digital certificate which contains a public key and the identity of the owner. A matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to check this information. In essence, the certificate authority is responsible for saying "yes, this person is who they say they are, and we, the CA, certify that".

For security and legal purposes, a public key owner must be verifiable and it is common to use a public key infrastructure (PKI) where the public key owner is validated by a CA. Since a public key is used to validate a cryptographic signature then a digital signature and a CA work together to authenticate the owner and the data.

No. The CA is required in use cases where a third party entity needs to be involved between a sender and other parties. If a CA is not used then a digital signature can instead use a self-signed certificate as shown in our digital signature sample or webviewer digital signature demo for example. Apryse does not provide CA services so it is the responsibility of users creating a digital signature workflow to use a CA if it is required for your use cases.

A document that has been signed using a certificate without any additional features (such as Document Timestamping (DTS) or Long Term Validation (LTV)) will result in the signature eventually expiring, as every certificate has an expiry date when they are generated.

This is different from when Certificate Revocation occurs, a process by which a certificate is deemed invalid before the end of its lifecycle. The revocation can occur for one of many reasons, as outlined in RFC 5280 Section 5.3.1. When revocation of a certificate occurs, it is placed on a Certificate Revocation List (CRL).

This behavior of expiration and revocation ensures that digital signatures placed on documents are only valid for a set period of time, either prior to the expiration date of the signature(s), or if the signature(s) have not been revoked at the time the document is viewed

Should the validity of the signature(s) need to be maintained outside of the certificate expiration timeframe and/or even if the certificates have been revoked, then Document Timestamping will ensure any applications that validate the signatures will check if the certificate was valid at the secure time (i.e. timestamp) of the certificate as certified by a third party trust provider (i.e. Certificate Authority).

Should the signature(s) need to be validated for an extended period of time for archival purposes, then Long Term Validation (LTV) should be applied to the signature to ensure that even if a CAs CRL responder is no longer active, an application can still validate the signature(s) based on the time they were applied.

It is worth noting that DTS is often applied alongside LTV, but note that they are two separate features.