Allow Digital Sign Validated with airSlate SignNow

Validate digital sign template

(upbeat music) Hello , my name is Bernd Wild from Intarsys and I will take you on a tour through the world of signing and validating PDF documents. I would like to give you a better impression of what happens when the validating a digitally signed PDF document. And we will see that validating a signature in a PDF can be a real challenge. And that validation as a whole is often more complex than actual signing. Well, what is validation? Validation of a digital signature, regardless of the document formart always consists of two components, proof of the identity of the signer, and proof of the integrity of the signed content. A digital signature is only valid if both checks are successful. The scope of verification of a digital signature, goes far beyond that of a hand written signature. The case of paper, it is only possible to check with great efforts and with the help of experts, whether any changes have been made to the written content after signature has been fixed. Just think of multi-page contract with a signature on the last page and the identity of the signer that can actually not be verified by the recipient at all. He's usually dependent on the believing that the printed name of the sign-on matches the handwritten signature. digital signatures therefore offer a completely different level of security and trust. The case of digital signatures, the identity verification of a signature is based on the verification of the certificates and the certificate chains. And is described in detail in standards such as carters and charters. This is therefore not the focus of the presentation. We will rather concentrate on the second part, the proof of content integrity. whatever one wants to achieve when opening, or validating a digitally signed PDF document, is the green check mark. This is the most important thing. Here I have shown this green check mark on two different PDF viewers, left in Adobe reader, and right in sign live CC our own PDF viewer. We notice two points. First, validation takes place automatically without any further action when the PDF document is opened in the viewer. That means the user does not have to initiate an explicit validation process. Of course he can. And secondly, we can already see various sub-items in the check result. Which illustrate that the check process itself consists of several steps. Only when each of these step provides a green hold. The overall result is also positive. Unfortunately, it is quite possible that some steps do not have clear results. Then the green check mark quickly turns into an exclamation mark, that requires a closer examination of the validation result. What you've never across, which indicates a negative validation. The assessment, what went wrong is then up to the user. And from personal experience, this is often the point at which the hotline of the manufacturer of the viewer or signature application is contacted by the user to determine the cause more precisely. Because to be honest, the interpretation of the validation report of a digital signature is not exactly user-friendly. The underlying processes are too complex for that. So the best thing to do is to make sure everything runs smoothly and ends up in a green check mark. PDF as a document format supports several types of digital signatures, which differ purely in their validation behavior. With regard to the changeability of content after a signature has been applied. technically and cryptographically, both signature types are identical. On the one hand, we have the most common and widely used signature type, the so-called approval signature. You see it here on the right side of the table. This is the standard signature form in PDF. It can be applied to a PDF as many times as desired. One after the other to obtain so-called serial signatures. An approval signature, always refers to the entire PDF document. At the time of the signature to be precise . focusing only on certain objects in the PDF or often asked on individual pages, is not possible with approval signatures. This special form was originally possible directly after the introduction of digital signatures in PDF with PDF version 1.3, but was then removed by Adobe with PDF 1.6 and has been prohibited since then. Approval signatures allow mark and anotations to be applied to the document after signing, without affecting the validity of the signature. This means that commands and graphic annotations can be applied. Furthermore, the feeling of form fields is also allowed. However, changing the shape or form fields is not allowed. As mentioned, this is the standard case without any further specifications. The certification signature on the other hand, is a limited form of the approval signature in terms of modifications. Here, the scope of modifications that is still permitted after signature can be specifically limited. Mind you restricted, not extended. It's not possible to extend the possibility the author signature. An approval signature cannot create additional modification possibilities. And as a special feature, a certification signature must always be the first signature in a PDF document. Hence the alternative name of a signature. It is not allowed to add a certification signature after your approval signature or multiple certification signatures. This will inevitably lead to a validation error, as long as the PDF viewer and validator is compliant with the PDF standard. Here is a brief list of the most important standards that play a role in the creation validation of PDF signatures. Of course, there are many more as these standards are based on other specifications as well, but for now these are the essential documents. Besides the three-part ETSI, and SA standard 31942, which describes the so-called PAdES standard, which stands for PDF based advanced electronic signatures, the ISO 32,000-1 and -2, also include the way signatures are integrated into the PDF structure. Only very privy to the process of signing a PDF, which is shown here in a simplified form. The PDF document is to be teacherly signed, the certificate of the signer and his public and private key are required. Usually for a high quality advanced or even qualified signature. The private key is stored on a highly secure hardware, such as a smart card or an HSM hardware security module, such as those for use by remote signature services. The first step is to split the existing PDF at a suitable location, insert an empty block, and then save the document again.The new PDF document now consists of three parts. The empty block part two, is a space that is taken up by the signature container later on. Here called CMS container. After the signature has been created , the coordinates part one and part three from the content of the so-called byte range, which is written at the beginning of part three, then a hash value is calculated over the range of part one and part three. With the help of the private key, this hash value is then encrypted and forms the signed hash value, the actual signature value. This hash value is packed into the CMS container together with certificate information, validity information for the certificates according to the carter standard. If you open a signed PDF in a text editor, or in a cross-browser, you can easily find out where the CMS container was inserted. A signature in the PDF is implemented by an acro form field of type signature or/sick As you see here in this slide. The value of the dictionary element contents is the base 64 encoded value of the CMS container. The byte range directly following the contents is also nicely displayed. In this case, part one of the PDF starts at byte zero and has a length of 84,102 bytes. While part two starts at byte position 160,872 and has alength of 775 bytes. If you take a closer look at the CMS container and decode it with an appropriate tool, you will recognize the hierarchical ASN.1 structure, which includes all signature of relevant information. This means that almost all signatures and certificate information, including the encrypted hash value is located within this container. Therefore, the structure of the container is also independent of the actual document format and would look exactly the same for assigned film or image. PAdES, is essentially only the transfer or the Carter standard to the PDF case. Here. Again, the structure of the byte range. Only the range specified here is covered by the signature, and can therefore easily be checked for changes. Every change within the range defined find by the byte range, always an inevitably leads to a validation error and thus, to the breaking of the signature and this without exception, remember it is not possible to sign only individual objects within a PDF document. This possibility is no longer available since PDF 1.6. If you still want to allow modifications in the PDF, After a signature has been applied, you have to resort to another trick, which I will discuss in a moment. What exactly happens when validating such a signature? Here are the steps that are taken to verify the identity of a signature. Of course, this can only be understood as an example, since the steps can vary, depending on the selected signature profile. The result of the check provides information as to whether the said signer has a certificate issued by an authority recognized as trustworthy, and whether this certificate was valid at the time of the signature. Depending on the specifications, the root certificates in the so-called trust list are considered trustworthy. In case of qualified electronic signatures, according to the eIDAS regulation, this would mean, for example, the national eIDAS trusted lists and the EU's list of eIDAS trusted lists. In the PDF world, the Adobe Approved Trust List AATL ,is also regarded as an anchor of trust for verifying trustworthiness. And here are the steps to determine the integrity of the content. The crucial step here is the last one the list. Where both hash values are compared, that means the hash value of part one and three immediately before the signature, and the count hash value of this areas at the time of validation. If both equal, then the integrity check has been successful. If the content of the PDF cannot be modified after signing, without breaking the signature, how can modifications be made without affecting the validation algorithm? Of course, this is also includes applying other signatures in the case of serial signatures. Since as we have learned, applying a signature is done by creating a corresponding acro form field, with it's substructures in the PDF. The trick, is to append new revision to the existing PDF. This way, the already signed area is not touched or changed. So the use byte range can still be used to calculate the hash value. If a new signature is appended, the same mechanism is performed within the new revision as described here earlier. That means ,get formation and determination of the new byte range. Which now completely includes the previous revision, and the back half of the new version. Then the second signature container is inserted into revision one. This process can be repeated as often as desired. This allows as many signatures to be applied one after the other. It means serially 'S' is useful for the business workflow. Up to now we have always done the process of splitting into two parts when applying the first signature directly in the body of the PDF. That means without ending a new revision, The usual aim is another round. To be precise however, a new revision is already added with the first signature and the signature container becomes part of this revision. This is shown again in this slide. That means you can take a look for example, at our application Sign Live! CC And then you will notice that if a single signature is applied without any further changes, only one additional revision is added to the PDF. In this picture, this would be revision one. The exciting part now comes when the permitted modification is to be made to the CND document. The case shown, a command is added to the signed PDF. As already shown for serial signatures, the only way to implement this in the signature compatible way, is to append a new revision, revision two in this case ,to the PDF and define the command as an annotation within its body. This means that in the body of revision two, all necessarily PDF objects on the cost level must be defined. As well as the changes to the objects from revision CRO, such as a page objects, so that the command can be visualized in the viewer at all. The corresponding sections from the ISO 32,000 specifications that govern the handling of annotations and signatures, and that compliant validation are presented here. It is clearly stated that in case of a subsequent modification, and this plate state does not correspond to the science state. If however, the annotations are used, according to the description in chapter 12.5 of the ISO specification, this does not lead to a breaking of the signature. On the contrary, annotation is recommended as a means of choice for implementing document workflows. What exactly happens when assigned and subsequently modified PDF is validated can be summarized under the term modification analyzers. Unfortunately, exactly this process is not clearly and unambiguously despecified. This means that there is hardly any specification material for someone who wants to implement such a behavior. The benchmark here are the implementations of Adobe reader and Acrobat. For everyone else, this is more or less a realistic process, which may lead to more or less discussions with customers, and users are even too generous and tolerant interpretations, which in turn are more vulnerable to malicious attacks. The general goal is to avoid the green hook, for a compliant modified signed PDF. Let's take a closer look at the modification analyzers. We start with a document that contains any remissions. For each revision, we check whether a signature is included. If so, it's really duty is checked by the respective byte range. Afterwards, it is determined whether there is a subsequent revision that contains mark up annotations or another signature. If mark up annotations are present, they're checked for the effect on objects from the previous revision. This means for example, that the previous page object, is only changed to include the new annotation Additional non-permitted objects may not be inserted. This is followed by a check of the cross-reference table. The last step when it is checked whether certificate signature is present. And if so, whether the modification restrictions possibly stored there are violated. At the end of this analyzers process, either a green check mark is displayed to indicate that the signatures are valid, and only permitted modifications have been made, or an error messages displayed indicating that the requirements or restriction or the approval or certification signatures have been violated. If we now add several annotations to this document, the validation result itself remains the same. However, it is noted here that several changes have taken place after the signature. However, these changes have not affected the validity of the signature, which is why the green check mark in front of the signature applies still in this picture. The present case several annotations were applied. For example, the rotor test was marked yellow Furthermore ,a form field was added and red borders were drawn around individual objects on the page. This brings us to another very important use case of post assigning modifications, the so-called signature augmentation. at HCN standards provide for certain signature profiles. In which all certificate chain informations necessary for identity verification, that means validity and revocation formation like OCSP responses or CRL information, can be stored together with a signature so that it is necessary. A complete validation of the signature can be performed without any online access to the trust service providers involved in the certificates. In this case, one can speak of a self-contained signature, which apart from the durability of the crypto graphic algorithms used, its very well-suited for long-term archiving. Since no further external resources or online instances need to be consulted for future validation. For PDF signatures, this extended validation information can be stored either in the CMS container itself, and thus transparent for the pre-PDF document, or in specially created dictionaries. These include the DSS or document security store dictionary, and the VRI, the validation related information dictionary. These two dictionaries were explicitly specified for the first time in the standard EN 319142-1 as part of PAdES ,and are not in ISO 32,000-1 but firstly appear in ISO 32,000-2 Excalty this possibility of allowed post signing modifications is used by a class of attacks on signed PDFs that became known as shadow attack this year. Still for us to manipulations of revisions have signed PDFs, that use was either incorrect or corrupt revision structures or annotations, that visually overlay the original signed content in such a way that at the first glance, the originally signed content appears to have been changed. Similar to the previously published a text on the signature structure, also known under the German universal signatory forgery. The good nature of many PDF viewers and validators is exploited to interpret corrupt PDF structures in order to accommodate the user as much as possible. Together with a lake of exact specifications on how to perform the modification analyzes, positive validation results can result despite malicious modifications. Of course, attack scenarios presented@pdfinsecurity.org require very specific constellations in the PDF, which are not necessarily found in the market. Rather they are theoretically possible methods of compromising assigned PDF with respect to validation. As long as the PDF tools and validators strictly adhere to the specification, there no significant risk. Even if in some implementations, the user experience is more important than the correctness of the format. Nevertheless, we must be grateful to the authors of the study. For specifically pointing out possible improvements with regard to trust in digital signatures in PDF. They describe problems with the modification analyzes and flat to the fact that they are now also taken up by ETSI as a standardization body for electronic signatures and their application to PDF. Several work packages are currently working now, on the specifications of these requirements and their definition in a supplement to the known standards. The result of this work is expected to be ready in 2021, so that we can assume, that the validation of signed PDFs will then become somewhat more transparent and no longer pose the challenge as it does today, we at Intesis are manufacturers of software for the electronic signature of documents and data. This includes the entire range from biometric to qualified electronic signatures. The core product here is Sign Live! CC for use at the workplace and Sign Live! cloud suite gears for the web-based signature. Intesis supports a wide range of signature devices such as smart cards, crypto tokens, and HSMs from various manufacturers. Sign Live! is used across all industries in various Europeancountries, in cooperation with various trust service providers. We are also actively involved in various signature related standardization committees, such as ETSI and the cloud signature consortium, of which we are also a founding member. As one of the first members of the PDF association, we are represented on the board of directors of the association and focus on the work around the digital PDF signature. Our slogan for Sign Live! is 'To be better than ink.' That means to improve user experience when making the transition from handwritten and signatures ,or paper-based signatures, to digital signatures, Just a few facts about the company. And we have about around 17 long time employees and more than 1100 customers from various industries and public administration. We work together with more than 40 partners. And with our software, the customers produce more than 5 million signatures per month, and they are doing also more than 5 million validations per month. In total, we have relationships to around 18 European trust service providers, and we are supporting actively around five to six with our APIs directly, others with a short time of integration, which is around two to three days. This again is a short overview about our portfolio and besides signature software, we also involved in PDF and PDF aid development, especially for the usage within electronic invoicing and the the standards so-called scaffold in Germany or Factor X now in Europe, France, and Germany. We also offer consulting in these domains, That means if you need some consulting for developing an appropriate signature solution for integration of an signature solution or, and PDF or PDFA solution, you can also come to us and we will help you. And we support our customers in a holistic way with extensive know-how and of corresponding component, competence and offer them solutions from one source. So they can ask us, and we are looking for all the different interfaces, and we will have them to integrate their software and to help them with the problems. From the trust services as defined by eIDAS, we focus on the first categories of trust service, electronic signatures, remote signatures, as well as the electronic seal or remote seal, that are trying timestamp. And last one, the preservation services. We don't offer a products for electronic trusted email services or website authentication. This is outside of our scope. They are in this four categories. We support secure signing, secure validating, and secure preserving. That means if you need to preserve your documents in a cryptographical way for more than 10 or 15 years, that means after the expiry of the actual cryptographical algorithms, we have the solution for this to do it, So this, this so-called IQ soft product, which gives you history based renewal of already assigned documents. Some of our customers are shown here, So we work with a lot of big, medium scale cam companies, and we have them as customers, Some of them also, as, as partners, for example, we are working closely with, with Swisscom in Switzerland, as well as Bundesdruckerei with in Germany, because they are the main trust service providers here. We also support from two systems or Tailor SEC, they are trust service provisions, and then you trust services coming up for, from Bank for luck and also from a Me Design. Signing with Sign Live!,our corporate act as I said, you can do this. And on the local base with a smart card or a crypto token, as well as on the remote base, that means then you have to use a server or you go and use our client and the client talks directly to your remote signature service. And there we can offer all common more signature services in Europe, as, as long as they are published via the CSE API. Beside this, we can give you also solutions for local or remote times stamping and means if you want to set up your own timestamp server for advanced the timestamps or even for qualified ones, we can deliver you the complete software stack to do this, and to have an app as a very reliable and performant installation for times stamping your documents. Sign as you like, as with that, you can choose among these offers, what you want to implement, you can use, as I said, time stamping in a local or remote manner, you can have the personal signature based on software assisted certificates on smart cards, or even on the remote signing service, and the same applies to seals. And you can have this also in, in the quality signature qualities, qualified or advanced. And if you like, you can also include your handwritten signature taken by a pressure sensitive PET, and in your digital signature. So that user experience is more or less the same than writing or signing on paper, but you end up with a high ,so secure digitally signed document. And the technical requirements for using our software are very, very low, we offer them for all platforms or major platforms, I have to say that means that you can use them on Windows, on Mac iOS or on Lennox and the, the new generation of software, the cloud suite gear software can also be used on every device, which has a browser, because they are we don't need any local installation. We only need and normal an actual browser so that you can have a connection to ours with our cloud server. One of the important things with our solution is in contrast to other solutions is that you don't need to upload the documents to add to a cloud server, and to get them signed. You only have these documents on your own server in your own company domain, and the only information which is leaving your company domain, which is sent to the trust service providers, the hash value of the document to be signed. And so there is no lack of in information. There is no security hole in, in the installation where you can have probably some problems in the future. If you upload your secret and confidential documents to a public cloud server. This is a short overview about the remote signature with and the new flagship product cloud suite gears? We have, they are on the clouds with gear server. We offer the web interface and they are also the interface for the certificates and administration and for adopting the APIs of the various trust service providers, We offer they're a very powerful rest API. You can integrate very easily into your own software environment. So if you don't want to take the software as it is with our demo stack, you can also integrate it very, very deeply in your own software environment and your workflows, so that you end up with a seamless digital document solution. And this is, I think one of the best of us, we can do, and we have a lot of customers who are especially looking for such a solution, which can be customized to their own needs. And by preserving the fact that the documents will never leave their own company domain (upbeat music)