You'll remember me from those amazing episodes about PKI And Digital Signature. Part I: Digital Identity Management and PKI And Digital Signature. Part II: Digital Signature as a Service. Now, this is the last part about the validation of digital signatures according to the main standards in the sector and the European Union scope.
A Quick Recap
AdES or advanced electronic signature is an electronic signature that has met the requirements set forth under EU Regulation No 910/2014 (eIDAS-regulation) on electronic identification and trust services for electronic transactions in the European Single Market.For an electronic signature to be considered as advanced, it must meet several requirements:
- The signatory can be uniquely identified and linked to the signature
- The signatory must have sole control of the signature creation data (typically a private key) that was used to create the electronic signature
- The signature must be capable of identifying if its accompanying data has been tampered with after the message was signed
- In the event that the accompanying data has been changed, the signature must be invalidated
- XAdES, XML Advanced Electronic Signatures is a set of extensions to XML-DSig.
- PAdES, PDF Advanced Electronic Signatures is a set of restrictions and extensions to PDF and ISO 32000-1.
- CAdES, CMS Advanced Electronic Signatures is a set of extensions to Cryptographic Message Syntax (CMS).
- ASiC Baseline Profile. ASiC (Associated Signature Containers) specifies the use of container structures to bind together one or more signed objects.
Everything is about Qualified Signatures
A Qualified Electronic Signature is an Advanced Electronic Signature based on a qualified certificate. It is created by a Qualified Electronic Signature Creation Device (QSCD).The Qualified Electronic Signature (QES) includes all the secure features that an Advanced Electronic Signature (AdES) provides by:
- Having the ability to uniquely identify and link its signatory to the electronic signature.
- Allowing the signatory to have sole control of the keys used to create the electronic signature.
- Identifying if the data has been tampered with after its accompanying message has been signed.
- Invalidating the signature if signed data has been altered in any manner.
Simply put, the difference between the AdES and the QES is the addition of a qualified certificate. This certificate is issued by a qualified trust service provider, and it attests to the authenticity of the electronic signature to serve as proof of the identity of the signatory.
Under eIDAS regulations, a QES has the same legal effect as a handwritten signature. It is recognized in all member states of the EU.
Specs, Specs, Specs
The standards for creating and validating advanced digital signatures are defined in ETSI EN 319 102-1 and specified in ETSI EN 319 122 , ETSI EN 319 132, ETSI EN 319 142-1 and 2 as well as ETSI EN 319 162.The advanced electronic signature formats (AdES) were published by the European Telecommunication Standarisation Institute ETSI. To comply with the eIDAS regulation on electronic signing, digital signature services must be implemented following these formats. The term AdES refers to the result of serializing structures compliant with CAdES, XAdES or PAdES.
AdES Section 5: VALIDATION!
After that catch up we'll move finally to the validation stuff. We'll be brief and straight to make things easier.First, it is important you know that according to AdES there are two main and clear roles, the Driving Application and the Signature Validation Application (this is the component we have to write).
What is the DA?
The Driving App is the software that handles the signature requests, documents, etc against an infrastructure. The DA can sign the documents or not.
What is the SVA?
The signature validation application (SVA) receives an AdES digital signature and other input from the driving application (DA).
The SVA shall validate the signature against a signature validation policy, consisting of a set of validation constraints, and shall output a status indication and validation report providing the details of the technical validation of each of the applicable constraints, which can be relevant for the DA in interpreting the results (we'll talk about validation policies and configuration in a future post).
If the PKI is public some public apps could eventually act as SVAs.
If your PKI is private (corporate networks, intranets, private products -restricted to authorized users-) the SVA role can be performed ONLY by an application able to contact your PKI to verify the involved certificates used to sign.
What are the possible verdicts?
AdES specifies three possible results from the validation of a digital signature:TOTAL-PASSED: when the cryptographic checks of the signature (including checks of hashes of individual data objects that have been signed indirectly) succeeded as well as all checks prescribed by the signature validation policy have been passed.
TOTAL-FAILED: the cryptographic checks of the signature failed (including checks of hashes of individual data objects that have been signed indirectly), or it is proven that the signing certificate was invalid at the time of generation of the signature, or because the signature is not conformant to one of the base standards to the extent that the cryptographic verification building block is unable to process it.
INDETERMINATE: the results of the performed checks cannot be verified.
So, we expect the signatures onto a correct legit non-modified document will return a clear TOTAL-PASSED for all of the digital signatures onto a given document. If this is not the case, the document is affected and can be considered as not valid as a whole.
How is validated each signature onto a document?
The main principle in validation of signatures is to verify the chain of certificates used in the signature are valid. That means that we have to check out the existence, validity and correctness of the involved certificates. To do that we need to access to our PKI.
The steps are simple:
- Iterate the signatures you find onto a given document.
- Get the certificates involved in the signature as a certificate chain.
- Find the signatory certificate in your PKI (internal or external) and the upper level certificates in it certificate chain. You have to check out the validity of the signatory's certificate against your PKI.
- Import the signatory certificate chain you found in the PKI into the temporary trusted list in your validation code. This stpe is critical as it sets p the trust anchors for the signature to be validated.
- Validate the signature and get a verdict. We'll use the default signature validation policy.
- Compose a customized report or use the XML AdES report to be returned to the Driving Application. You can use the simple or the complete report.
This is a sample of a function that validates signatures onto a document using the EU DSS library:
def validateAdESSignatures(businessId: String, filePath: String, packInfoOpt: Option[(String, Pack)]): (DocumentValidationResponse, Int) = {
import eu.europa.esig.dss.validation._
import eu.europa.esig.dss.validation.reports.Reports
val file: File = new File(filePath)
val document: DSSDocument = new FileDocument(file)
val pdfValidator: PDFDocumentValidator = new PDFDocumentValidator(document)
val errors: ArrayBuffer[String] = ArrayBuffer.empty[String]
if (pdfValidator.isSupported(document)) {
val certificateVerifier: CommonCertificateVerifier = new CommonCertificateVerifier()
pdfValidator.setCertificateVerifier(certificateVerifier)
val firstReport = pdfValidator.validateDocument()
val sp = firstReport.getDiagnosticData
val certificateSource: CommonTrustedCertificateSource = new CommonTrustedCertificateSource()
packInfoOpt match {
case Some(pi) => { // A specific certificate has been provdied
val certChain = getUsersCertificateChain(pi)
certChain.foreach(certificateSource.addCertificate)
}
case None => { // Iterate ALL certificates involved
val signatures: List[SignatureWrapper] = sp.getAllSignatures.asScala.toList
signatures.foreach(s => {
val userCert = s.getCertificateChain.get(0)
val pkiRecord: Option[PKIInfo] = PKIDAO.getPKIInfoBySerial(userCert.getSerialNumber)
pkiRecord match {
case Some(p) => {
val certChain = getUsersCertificateChain(getIDPack(p.piiid, businessId))
certChain.foreach(certificateSource.addCertificate)
}
case None => {
val msg: String = s"Digital Identity items (certificate) is not currently available in the PKI - Serial: ${userCert.getSerialNumber}"
logger.warn(msg)
errors += msg
}
}
})
}
}
if (errors.size > 0) { // The validation has detected errors in some signature
(composeFailedAdESReport(businessId, file.getName, errors.toArray), 9)
} else { // All signatures have been valdidated as OK
val certPool: CertificatePool = new CertificatePool
certPool.importCerts(certificateSource)
val keystoreCertSource: CertificateSource = new KeyStoreCertificateSource("PKCS12", "password", certPool)
certificateSource.importAsTrusted(keystoreCertSource)
certificateVerifier.setTrustedCertSource(certificateSource)
pdfValidator.setCertificateVerifier(certificateVerifier)
val finalPdfReport: Reports = pdfValidator.validateDocument()
println(finalPdfReport.getXmlSimpleReport)
val response: DocumentValidationResponse = composeAdESReport(businessId, finalPdfReport.getSimpleReportJaxb)
(response, 0)
}
} else { // For some reason the signatures were not able to be validatedin the AdES way
val msg: String = s"Document '${file.getName}' is not compatible with AdES validation"
logger.warn(msg)
errors += msg
(composeFailedAdESReport(businessId, file.getName, errors.toArray), 3)
}
}Finally, you can get a simple or complete report in XML format or populate a custom class with the results of the validation. Below you can see a sample of a simple XML report:
Long-Term Validation. What happens with revoked certificates?
This is simple. If you have used the LT or LTA (Long Term Availabilty) for the baseline of the AdES signatures we have to consider that eventually the used certificates are revoked in the time the validation of the signature is done. In this case the implications relies on a simple fact. If a certificate is revoked is still valid. The AdES spec tells very clearly about it (A.3.3):
The status goes from INDETERMINATE/REVOKED_NO_POE (using the basic validation algorithm) to TOTAL-PASSED because the Signature with Time validation algorithm processes the signature time-stamp attribute and finds that the signing time lies before the revocation date.
Conclusions
- Read the specifications above mentioned. They are really affordable and understandable.
- Avoid pseudo validations based on “unique codes” (for instance by recording a signature entry and assigning a code) or something like that. This type of solutions only shows you do not understand the standards about digital signatures and of course they are not actually validating anything. Therefore, it’s useless for your customers. The only real validation of signatures compliant to AdES is the complete validation of signatures via the validation of the certificates involved in each signature.
- Use EU DSS when possible (EU's CEF Digital). It will save a lot of time and issues in your project assuring you are compliant with specs.
- Your PKI is critical to validate the certificates in the signatures to validate. To have a standard and strong PKI is life!
- LT and LTA based signatures have to consider revoked certificates as well.
