OOXML PDF Digital Signing in Draw and elsewhere
Vajna, Miklos
LibreOffice originally only supported digital signing for ODF files. Collabora later extended this support to cover OOXML files and also signing existing PDF files in Draw. The latest news is adding visible signatures to existing PDF files. The talk will walk though the steps which were necessary to add support for this feature from document model to layout, from UI to file filters. Come and see where we are, what still needs to be done, and how you can help.
 Hello, this is a talk about Oaxamal and PDF digital signing intro and elsewhere. This talk is meant to be focused on AX509 certificates, creating signatures using that and verifying those signatures. So I won't really be talking about all this GPG-based signing, which is a different piece. Regarding me, perhaps I'm already familiar to many of you. I'm Miklo Shryna from Hungary. I'm a big collaborator for many years now. I started here as a G-Soc student around the writer RTF, important export. Nowadays I mostly do things around writer. So let's start with an overview on regarding what was already available as digital signing as a feature set in OpenOffice.org and how we developed new features on top of that and then I don't really reach what's new this year. So the digital signing we had in OpenOffice all times was just limited to ODF signing. We literally had hardcoded conditions in the code saying in case it's not ODF done, it's impossible to digitally sign something. And when it comes to signing, you always have to decide what's the hashing algorithm you use to create some digest from your original content and then you actually sign that digest. So for digesting, only this order MD5 and SHA-1 was supported, not the newer SHA-256 or anything better and also just RSA was supported, so the newer ECDSA or anything else was not supported. Regarding the verification and the processes somewhat straightforward, so it can do checking if the digest is machined, which means in case you modify the document as an attacker, we have a different digest compared to what was signed and we can detect that the document is modified. It can also do certificate validation, see that we have some trusted root certificates and there should be a chain from the trusted root certificate to your certificate and in case there is no such chain done. That also fails the validation. It's also an interesting attack that you can append some new streams in the Z package or basically put data before or after the signed content, so we also check for that and as mentioned, this is all done by an X509 certificate, so no GPG that was added later. The first thing I added four years ago was a Waxema signing, which is basically digital signing for DoCaX, XLSX and PPTX formats to improve the interface with Microsoft Office. This is somewhat similar to ODF signing because it is building on this W3C specification, the XML digital signing core specification and ODF does the same. So at the very bottom layer, we are just signing a piece of XML fragment and how we do that is actually the same for OXML and ODF. One interesting part here for you as a user is that the never signed metadata for OXML files. This is probably because Microsoft wants to upload the files to SharePoint and tweet the metadata there or something like that. If you open the files in Libreface, then the Libreface standard is that metadata should be part of the signature. So actually, OXML signatures won't be recognized as perfect. The best level you can reach is that you have a partial signature. It's important that we are meant to read what Microsoft Office writes and also we should produce something that they can read. What's somewhat interesting is that there are these different transform algorithms in the XML XML spec and compared to ODF, there is a special one in the OXML spec. There is the custom algorithm and we offload most of this XML signing work to the XML stack library and that has a hard-coded set of transforms that it's supporting. So I had to go to the XML stack library at support for these relationships transform algorithm because that influences what's the input data that will be used for hashing. Once this was contributed upstream, then we could use it for OXML signing purposes. Suddenly the OXML signing markup is a bit awful. Another interesting piece is that it leaks quite some of your software and hardware details like you are supposed to write your Windows version, Office version, Microsoft Office version, how many monitors you have, what resolution your monitor has, and so on and so on. It's a very interesting question, what's your Windows version if you use Librofix on the Mac or Linux? So we have some hard-coded stubdarms that we please what Microsoft Office requires there but it's not really leaking your data. The next step was that PDF export has an optional way to create a signature during the creation of the PDF file itself. This was naturally done as a GSOC project and then a Torli request completed this. And because we had some customer who wanted to try this to completion. And what we do there is basically we do the PDF export, we write placeholder for the signature and then we do the standard binary signing using X509 certificate. This PKCS7 spec defines how to do a binary signature on the hash of this original content. And then we do a hex dump of this signature and put it to the placeholder inside the PDF file. And what's not used from the placeholder is just field-up with padding. So this is for new PDF files and for signatures. Then we wanted to improve this so that we can also verify those signatures and this requires quite like digging into quite some layers. So first I wanted to understand what existing PDF parsers we have in LibreOffice because of course we had multiple ones. So at that time we had three. Popular is used to have some editable ODG file out of some PDF input intro. Then the primary problem there is that this is not available in OBIOS in case you are focusing on NPS. Absolutely, this is just not there. We have some quite hard to read boost-based parser which is as I understand it mostly used just for hybrid PDF so that you can get back your original write or or calc or in press document from some PDF file but in case you have no LibreOffice around you still have the PDF data there. And I checked what's the situation with PDF. But at least back then it had no API to extract all the signature details which is needed by us. So we needed some solution where we can just build the missing piece ourselves. I wanted to add and I did the first PDF tokenizer but this one is really just tokenizing the PDF data. It's not really parsing what's in the object streams which is probably the harder part of the whole PDF parsing. And the basic verification is not that complicated. We need to determine where is this signature inside the PDF file and just have hash everything before and after that. And determine if the digest is matching or not. But then of course you can make things more complicated. You can have multiple signatures in a PDF file and the signatures are changed by definition. So the second signature is always including the first signature as data which means that previously I mentioned we want to have a signature which is covering the complete document. So if signature is partial then we consider that as a failure. And for PDF you can't really do this because technically everything except the last signature will be partial. So we do some middle ground there. We try to find out if actually the first signature is partial only because there is a second signature added or perhaps there is some incestate content between the signatures inserted by some attacker. And in that case the first signature will be partial. So that's a bit complicated and it's a bit sad that these hacks are required for real world multiple signature usage in the PDF format. So once you can verify a PDF signature then of course you want to create PDF signatures. And I sent creating new PDF files with signatures in done that was already supported. But then you can also take existing PDF files and perhaps the user size I just want to sign this. So this is not working but all combinations of Librofist creating PDF files Adobe Acrobat creating PDF files and then creating the initial signature then second and third signatures and swapping between the two software. So that's lots of combinations. But I believe now this is working nicely. The hard part is really that we are expected to parse random PDF files and this is a much larger, much richer markup compared to just the subset that we are producing in our PDF export. Previously it was only necessary to parse what's produced by our own export. One thing you can do on top of existing XML signing and PDF signing is that there is a set of recommendations on top of the XML ID SIG recommendation or on top of the PDF SPAC that this XSODAS and PODAS signing which has the promise that in case all conditions are met then this can result in a signing which is actually legally binding which makes it very much interesting. So we had a checklist of what's obviously missing from Librofist to create such signatures. One thing was that the SHAW256 support as a digesting algorithm was missing and now it's possible to do that. So just RSA was supported, so ECDSA support was added. And one very important piece is that you have to make sure that not only the certain private key was used to create a signature but also what was the original signature because like there is a trap here you can have the same private key in multiple signatures but actually multiple certificates but actually the certificate contains your name and your other details. So as an end user you want to have some signature which actually ensures that this certificate was used for signing and the original digital signing is actually not providing this. And the bottom line here is that when this work was finished then there is some DSS digital signatures service validator which can check if you are confirming to different baselines of this PODAS standard. We are passing the basic checks there, you get a nice great check mark. The use this here is that in case you are doing signing of existing PDF-wise then so far we were signing some kind of stub signature widget which was on the first page, zero size top left corner and now we can actually create some visible signature widget which is semantically associated with the actual digital signature. So you get a user interface which is quite similar to existing signature lines in writer or impress and draw your signature rectangle somewhere, you get a nice vector on graphic there, use the correct PDF markup and once you've drawn some rectangle you can find you that in case the size or the position is exactly what you want and then you actually do the digital signing. As a combination of these I believe currently this is a bit better than what you get from docuSign or Adobe Acrobat. So that sounds pretty nice. The question is like in case you are more interested in the technical details how all of these features are actually implemented. So one thing that we added was signature descriptions, Iwaxamal and PDF-4D has markup for this and we were losing this data. You can also refer to this signature commands or signature reasons. I have the entire block was dedicated for this, it's on the slide, you can click on that in case you are interested in even more details. The point is that this way it makes sense to have the same signature for same signing certificate in multiple signatures because in the description you can actually state what's the reason of your signature signing and perhaps you want to first state reason A and later reason B and then use the same signing certificate for the same document multiple times. You can also do the import of the signatures from Iwaxamal. As mentioned this required an implementation of the relationship transform algorithm. That was a bit tricky because the ECMO version and the ISO version of this algorithm is actually different and I believe there was a bug in the ECMO version so if you implement the ISO version then you will get the same result that Microsoft Office has. There is a small SXPARS in the in AXAMAL security to actually read this Oaxamal signature and this was the first case where we are still we were still just supporting ZIP based formats like Oaxamal and PDF but there is no longer a hard-coded saying if this is not ODF then it's impossible to digitally sign this format. Then once you could import and verify those signatures you perhaps want to add your own ones. So in the Oaxamal case each new signature has new XMF string in the ZIP package so that's somewhat nice because you can't easily break existing signatures or actually it's harder to do that by accident on the other hand it requires some bookkeeping on how these signatures are referenced and so on. Also some refactoring was done here so that most of the signing logic is moved outside the dialogue so that it can be triggered from CPP in it tests. Following the verification of existing PDF signatures this is just happening automatically when you are opening some PDF file and we have some UI where you can actually try to discourage users from editing the file in case it has signatures because in case you are editing the file then you will lose your signatures. I think PADDES support require basically improvements to the hashing and encryption algorithms that we support and also there is some SPAC on exactly how to embed this signing certificate to the existing binary signature and if you implement that then you get this nice green check mark from the DSS validator. There was a separate tab for this exactly the SHO256 and the ECDSA support. I was personally interested in that because there is some Hungarian electronic ID you can get as Hungarian citizens and there is a signing certificate on that and if you get some certificate reader then you can actually use this for signing and this is recognized by the government and whatnot. So some real hardware based signing. I know this is working on Windows and Linux and what was really challenging there is that ECDSA support is not working in this order in this API that we were using for encryption and hashing. So I know we wrote that part to use the Microsoft cryptography next generation, this CNG API and that's working nicely. The last piece was this visible PDF signing where I tried hard to reuse existing code. So this is very similar to signature lines but you may know already from Brighter and Kog the generated visible signature object is actually reusing the existing export shape to PDF functionality so it's nice vector based and also then we are copying this PDF object from the shape PDF to the final PDF using code which is reused from the insert PDF image functionality. Last as always don't forget that Colabora is an open source company so what we do and share with the community has to be always paid by somebody and in this case the Dutch Ministry of Defence in cooperation with now and of a small Dutch company made this work by Colabora possible. The majority of the functionality presented in this call was paid by them so a huge thanks to them and this is a great feature set and it was possible due to them. So as a summary the good news is that compared to the original OpenFish org feature set we support this Xodes and Podesta extensions, the baseline Spark, we support modern hashing and algorithms, you can sign not only audio but OXM and PDF wise. This is working nicely to the matching products like Microsoft Office and Dacrobat for us and the new this year was this visible PDF signature. Thanks for listening. Bye bye.
 Hello, this is a talk about Oaxamal and PDF digital signing intro and elsewhere.  This talk is meant to be focused on AX509 certificates, creating signatures using that  and verifying those signatures.  So I won't really be talking about all this GPG-based signing, which is a different piece.  Regarding me, perhaps I'm already familiar to many of you.  I'm Miklo Shryna from Hungary.  I'm a big collaborator for many years now.  I started here as a G-Soc student around the writer RTF, important export.  Nowadays I mostly do things around writer.  So let's start with an overview on regarding what was already available as digital signing  as a feature set in OpenOffice.org and how we developed new features on top of that and  then I don't really reach what's new this year.  So the digital signing we had in OpenOffice all times was just limited to ODF signing.  We literally had hardcoded conditions in the code saying in case it's not ODF done, it's  impossible to digitally sign something.  And when it comes to signing, you always have to decide what's the hashing algorithm you  use to create some digest from your original content and then you actually sign that digest.  So for digesting, only this order MD5 and SHA-1 was supported, not the newer SHA-256  or anything better and also just RSA was supported, so the newer ECDSA or anything else was not  supported.  Regarding the verification and the processes somewhat straightforward, so it can do checking  if the digest is machined, which means in case you modify the document as an attacker,  we have a different digest compared to what was signed and we can detect that the document  is modified.  It can also do certificate validation, see that we have some trusted root certificates  and there should be a chain from the trusted root certificate to your certificate and in  case there is no such chain done.  That also fails the validation.  It's also an interesting attack that you can append some new streams in the Z package or  basically put data before or after the signed content, so we also check for that and as  mentioned, this is all done by an X509 certificate, so no GPG that was added later.  The first thing I added four years ago was a Waxema signing, which is basically digital  signing for DoCaX, XLSX and PPTX formats to improve the interface with Microsoft Office.  This is somewhat similar to ODF signing because it is building on this W3C specification,  the XML digital signing core specification and ODF does the same.  So at the very bottom layer, we are just signing a piece of XML fragment and how we do that  is actually the same for OXML and ODF.  One interesting part here for you as a user is that the never signed metadata for OXML  files.  This is probably because Microsoft wants to upload the files to SharePoint and tweet the  metadata there or something like that.  If you open the files in Libreface, then the Libreface standard is that metadata should  be part of the signature.  So actually, OXML signatures won't be recognized as perfect.  The best level you can reach is that you have a partial signature.  It's important that we are meant to read what Microsoft Office writes and also we should  produce something that they can read.  What's somewhat interesting is that there are these different transform algorithms in  the XML XML spec and compared to ODF, there is a special one in the OXML spec.  There is the custom algorithm and we offload most of this XML signing work to the XML  stack library and that has a hard-coded set of transforms that it's supporting.  So I had to go to the XML stack library at support for these relationships transform  algorithm because that influences what's the input data that will be used for hashing.  Once this was contributed upstream, then we could use it for OXML signing purposes.  Suddenly the OXML signing markup is a bit awful.  Another interesting piece is that it leaks quite some of your software and hardware details  like you are supposed to write your Windows version, Office version, Microsoft Office  version, how many monitors you have, what resolution your monitor has, and so on and  so on.  It's a very interesting question, what's your Windows version if you use Librofix on  the Mac or Linux?  So we have some hard-coded stubdarms that we please what Microsoft Office requires  there but it's not really leaking your data.  The next step was that PDF export has an optional way to create a signature during the creation  of the PDF file itself.  This was naturally done as a GSOC project and then a Torli request completed this.  And because we had some customer who wanted to try this to completion.  And what we do there is basically we do the PDF export, we write placeholder for the signature  and then we do the standard binary signing using X509 certificate.  This PKCS7 spec defines how to do a binary signature on the hash of this original content.  And then we do a hex dump of this signature and put it to the placeholder inside the PDF  file.  And what's not used from the placeholder is just field-up with padding.  So this is for new PDF files and for signatures.  Then we wanted to improve this so that we can also verify those signatures and this requires  quite like digging into quite some layers.  So first I wanted to understand what existing PDF parsers we have in LibreOffice because  of course we had multiple ones.  So at that time we had three.  Popular is used to have some editable ODG file out of some PDF input intro.  Then the primary problem there is that this is not available in OBIOS in case you are  focusing on NPS.  Absolutely, this is just not there.  We have some quite hard to read boost-based parser which is as I understand it mostly  used just for hybrid PDF so that you can get back your original write or or calc or  in press document from some PDF file but in case you have no LibreOffice around you still  have the PDF data there.  And I checked what's the situation with PDF.  But at least back then it had no API to extract all the signature details which is needed  by us.  So we needed some solution where we can just build the missing piece ourselves.  I wanted to add and I did the first PDF tokenizer but this one is really just tokenizing the  PDF data.  It's not really parsing what's in the object streams which is probably the harder part  of the whole PDF parsing.  And the basic verification is not that complicated.  We need to determine where is this signature inside the PDF file and just have hash everything  before and after that.  And determine if the digest is matching or not.  But then of course you can make things more complicated.  You can have multiple signatures in a PDF file and the signatures are changed by definition.  So the second signature is always including the first signature as data which means that  previously I mentioned we want to have a signature which is covering the complete document.  So if signature is partial then we consider that as a failure.  And for PDF you can't really do this because technically everything except the last signature  will be partial.  So we do some middle ground there.  We try to find out if actually the first signature is partial only because there is a second  signature added or perhaps there is some incestate content between the signatures inserted  by some attacker.  And in that case the first signature will be partial.  So that's a bit complicated and it's a bit sad that these hacks are required for real  world multiple signature usage in the PDF format.  So once you can verify a PDF signature then of course you want to create PDF signatures.  And I sent creating new PDF files with signatures in done that was already supported.  But then you can also take existing PDF files and perhaps the user size I just want to sign  this.  So this is not working but all combinations of Librofist creating PDF files Adobe Acrobat  creating PDF files and then creating the initial signature then second and third signatures  and swapping between the two software.  So that's lots of combinations.  But I believe now this is working nicely.  The hard part is really that we are expected to parse random PDF files and this is a much  larger, much richer markup compared to just the subset that we are producing in our PDF  export.  Previously it was only necessary to parse what's produced by our own export.  One thing you can do on top of existing XML signing and PDF signing is that there is a  set of recommendations on top of the XML ID SIG recommendation or on top of the PDF  SPAC that this XSODAS and PODAS signing which has the promise that in case all conditions  are met then this can result in a signing which is actually legally binding which makes  it very much interesting.  So we had a checklist of what's obviously missing from Librofist to create such signatures.  One thing was that the SHAW256 support as a digesting algorithm was missing and now it's  possible to do that.  So just RSA was supported, so ECDSA support was added.  And one very important piece is that you have to make sure that not only the certain private  key was used to create a signature but also what was the original signature because like  there is a trap here you can have the same private key in multiple signatures but actually  multiple certificates but actually the certificate contains your name and your other details.  So as an end user you want to have some signature which actually ensures that this certificate  was used for signing and the original digital signing is actually not providing this.  And the bottom line here is that when this work was finished then there is some DSS  digital signatures service validator which can check if you are confirming to different  baselines of this PODAS standard.  We are passing the basic checks there, you get a nice great check mark.  The use this here is that in case you are doing signing of existing PDF-wise then so  far we were signing some kind of stub signature widget which was on the first page, zero size  top left corner and now we can actually create some visible signature widget which is semantically  associated with the actual digital signature.  So you get a user interface which is quite similar to existing signature lines in writer  or impress and draw your signature rectangle somewhere, you get a nice vector on graphic  there, use the correct PDF markup and once you've drawn some rectangle you can find you  that in case the size or the position is exactly what you want and then you actually do the  digital signing.  As a combination of these I believe currently this is a bit better than what you get from  docuSign or Adobe Acrobat.  So that sounds pretty nice.  The question is like in case you are more interested in the technical details how all  of these features are actually implemented.  So one thing that we added was signature descriptions, Iwaxamal and PDF-4D has markup for this and  we were losing this data.  You can also refer to this signature commands or signature reasons.  I have the entire block was dedicated for this, it's on the slide, you can click on that  in case you are interested in even more details.  The point is that this way it makes sense to have the same signature for same signing  certificate in multiple signatures because in the description you can actually state  what's the reason of your signature signing and perhaps you want to first state reason  A and later reason B and then use the same signing certificate for the same document  multiple times.  You can also do the import of the signatures from Iwaxamal.  As mentioned this required an implementation of the relationship transform algorithm.  That was a bit tricky because the ECMO version and the ISO version of this algorithm is actually  different and I believe there was a bug in the ECMO version so if you implement the ISO  version then you will get the same result that Microsoft Office has.  There is a small SXPARS in the in AXAMAL security to actually read this Oaxamal signature  and this was the first case where we are still we were still just supporting ZIP based formats  like Oaxamal and PDF but there is no longer a hard-coded saying if this is not ODF then  it's impossible to digitally sign this format.  Then once you could import and verify those signatures you perhaps want to add your own  ones.  So in the Oaxamal case each new signature has new XMF string in the ZIP package so that's  somewhat nice because you can't easily break existing signatures or actually it's harder  to do that by accident on the other hand it requires some bookkeeping on how these signatures  are referenced and so on.  Also some refactoring was done here so that most of the signing logic is moved outside  the dialogue so that it can be triggered from CPP in it tests.  Following the verification of existing PDF signatures this is just happening automatically  when you are opening some PDF file and we have some UI where you can actually try to  discourage users from editing the file in case it has signatures because in case you  are editing the file then you will lose your signatures.  I think PADDES support require basically improvements to the hashing and encryption algorithms that  we support and also there is some SPAC on exactly how to embed this signing certificate  to the existing binary signature and if you implement that then you get this nice green  check mark from the DSS validator.  There was a separate tab for this exactly the SHO256 and the ECDSA support.  I was personally interested in that because there is some Hungarian electronic ID you  can get as Hungarian citizens and there is a signing certificate on that and if you get  some certificate reader then you can actually use this for signing and this is recognized  by the government and whatnot.  So some real hardware based signing.  I know this is working on Windows and Linux and what was really challenging there is that  ECDSA support is not working in this order in this API that we were using for encryption  and hashing.  So I know we wrote that part to use the Microsoft cryptography next generation, this CNG API  and that's working nicely.  The last piece was this visible PDF signing where I tried hard to reuse existing code.  So this is very similar to signature lines but you may know already from Brighter and  Kog the generated visible signature object is actually reusing the existing export shape  to PDF functionality so it's nice vector based and also then we are copying this PDF object  from the shape PDF to the final PDF using code which is reused from the insert PDF image  functionality.  Last as always don't forget that Colabora is an open source company so what we do and  share with the community has to be always paid by somebody and in this case the Dutch  Ministry of Defence in cooperation with now and of a small Dutch company made this work  by Colabora possible.  The majority of the functionality presented in this call was paid by them so a huge thanks  to them and this is a great feature set and it was possible due to them.  So as a summary the good news is that compared to the original OpenFish org feature set  we support this Xodes and Podesta extensions, the baseline Spark, we support modern hashing  and algorithms, you can sign not only audio but OXM and PDF wise.  This is working nicely to the matching products like Microsoft Office and Dacrobat for us  and the new this year was this visible PDF signature.  Thanks for listening.  Bye bye.
OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_0_47.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_48_803.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_804_1343.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_1344_5219.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_5220_10007.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_10008_11675.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_11676_16535.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_16536_18371.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_18372_21947.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_21948_23843.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_23844_24011.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_24012_27815.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_27816_28463.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_28464_29147.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_29148_31787.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_31788_33623.png OOXML_PDF_Digital_Signing_in_Draw_and_elsewhere__Lwg3EZ_Dc4_33624_33690.png
Hello, this is a talk about Oaxamal and PDF digital signing intro and elsewhere. This talk is meant to be focused on AX509 certificates, creating signatures using that and verifying those signatures. So I won't really be talking about all this GPG-based signing, which is a different piece. Regarding me, perhaps I'm already familiar to many of you. I'm Miklo Shryna from Hungary. I'm a big collaborator for many years now. I started here as a G-Soc student around the writer RTF, important export. Nowadays I mostly do things around writer. So let's start with an overview on regarding what was already available as digital signing as a feature set in OpenOffice.org and how we developed new features on top of that and then I don't really reach what's new this year. So the digital signing we had in OpenOffice all times was just limited to ODF signing. We literally had hardcoded conditions in the code saying in case it's not ODF done, it's impossible to digitally sign something. And when it comes to signing, you always have to decide what's the hashing algorithm you use to create some digest from your original content and then you actually sign that digest. So for digesting, only this order MD5 and SHA-1 was supported, not the newer SHA-256 or anything better and also just RSA was supported, so the newer ECDSA or anything else was not supported. Regarding the verification and the processes somewhat straightforward, so it can do checking if the digest is machined, which means in case you modify the document as an attacker, we have a different digest compared to what was signed and we can detect that the document is modified. It can also do certificate validation, see that we have some trusted root certificates and there should be a chain from the trusted root certificate to your certificate and in case there is no such chain done. That also fails the validation. It's also an interesting attack that you can append some new streams in the Z package or basically put data before or after the signed content, so we also check for that and as mentioned, this is all done by an X509 certificate, so no GPG that was added later. The first thing I added four years ago was a Waxema signing, which is basically digital signing for DoCaX, XLSX and PPTX formats to improve the interface with Microsoft Office. This is somewhat similar to ODF signing because it is building on this W3C specification, the XML digital signing core specification and ODF does the same. So at the very bottom layer, we are just signing a piece of XML fragment and how we do that is actually the same for OXML and ODF. One interesting part here for you as a user is that the never signed metadata for OXML files. This is probably because Microsoft wants to upload the files to SharePoint and tweet the metadata there or something like that. If you open the files in Libreface, then the Libreface standard is that metadata should be part of the signature. So actually, OXML signatures won't be recognized as perfect. The best level you can reach is that you have a partial signature. It's important that we are meant to read what Microsoft Office writes and also we should produce something that they can read. What's somewhat interesting is that there are these different transform algorithms in the XML XML spec and compared to ODF, there is a special one in the OXML spec. There is the custom algorithm and we offload most of this XML signing work to the XML stack library and that has a hard-coded set of transforms that it's supporting. So I had to go to the XML stack library at support for these relationships transform algorithm because that influences what's the input data that will be used for hashing. Once this was contributed upstream, then we could use it for OXML signing purposes. Suddenly the OXML signing markup is a bit awful. Another interesting piece is that it leaks quite some of your software and hardware details like you are supposed to write your Windows version, Office version, Microsoft Office version, how many monitors you have, what resolution your monitor has, and so on and so on. It's a very interesting question, what's your Windows version if you use Librofix on the Mac or Linux? So we have some hard-coded stubdarms that we please what Microsoft Office requires there but it's not really leaking your data. The next step was that PDF export has an optional way to create a signature during the creation of the PDF file itself. This was naturally done as a GSOC project and then a Torli request completed this. And because we had some customer who wanted to try this to completion. And what we do there is basically we do the PDF export, we write placeholder for the signature and then we do the standard binary signing using X509 certificate. This PKCS7 spec defines how to do a binary signature on the hash of this original content. And then we do a hex dump of this signature and put it to the placeholder inside the PDF file. And what's not used from the placeholder is just field-up with padding. So this is for new PDF files and for signatures. Then we wanted to improve this so that we can also verify those signatures and this requires quite like digging into quite some layers. So first I wanted to understand what existing PDF parsers we have in LibreOffice because of course we had multiple ones. So at that time we had three. Popular is used to have some editable ODG file out of some PDF input intro. Then the primary problem there is that this is not available in OBIOS in case you are focusing on NPS. Absolutely, this is just not there. We have some quite hard to read boost-based parser which is as I understand it mostly used just for hybrid PDF so that you can get back your original write or or calc or in press document from some PDF file but in case you have no LibreOffice around you still have the PDF data there. And I checked what's the situation with PDF. But at least back then it had no API to extract all the signature details which is needed by us. So we needed some solution where we can just build the missing piece ourselves. I wanted to add and I did the first PDF tokenizer but this one is really just tokenizing the PDF data. It's not really parsing what's in the object streams which is probably the harder part of the whole PDF parsing. And the basic verification is not that complicated. We need to determine where is this signature inside the PDF file and just have hash everything before and after that. And determine if the digest is matching or not. But then of course you can make things more complicated. You can have multiple signatures in a PDF file and the signatures are changed by definition. So the second signature is always including the first signature as data which means that previously I mentioned we want to have a signature which is covering the complete document. So if signature is partial then we consider that as a failure. And for PDF you can't really do this because technically everything except the last signature will be partial. So we do some middle ground there. We try to find out if actually the first signature is partial only because there is a second signature added or perhaps there is some incestate content between the signatures inserted by some attacker. And in that case the first signature will be partial. So that's a bit complicated and it's a bit sad that these hacks are required for real world multiple signature usage in the PDF format. So once you can verify a PDF signature then of course you want to create PDF signatures. And I sent creating new PDF files with signatures in done that was already supported. But then you can also take existing PDF files and perhaps the user size I just want to sign this. So this is not working but all combinations of Librofist creating PDF files Adobe Acrobat creating PDF files and then creating the initial signature then second and third signatures and swapping between the two software. So that's lots of combinations. But I believe now this is working nicely. The hard part is really that we are expected to parse random PDF files and this is a much larger, much richer markup compared to just the subset that we are producing in our PDF export. Previously it was only necessary to parse what's produced by our own export. One thing you can do on top of existing XML signing and PDF signing is that there is a set of recommendations on top of the XML ID SIG recommendation or on top of the PDF SPAC that this XSODAS and PODAS signing which has the promise that in case all conditions are met then this can result in a signing which is actually legally binding which makes it very much interesting. So we had a checklist of what's obviously missing from Librofist to create such signatures. One thing was that the SHAW256 support as a digesting algorithm was missing and now it's possible to do that. So just RSA was supported, so ECDSA support was added. And one very important piece is that you have to make sure that not only the certain private key was used to create a signature but also what was the original signature because like there is a trap here you can have the same private key in multiple signatures but actually multiple certificates but actually the certificate contains your name and your other details. So as an end user you want to have some signature which actually ensures that this certificate was used for signing and the original digital signing is actually not providing this. And the bottom line here is that when this work was finished then there is some DSS digital signatures service validator which can check if you are confirming to different baselines of this PODAS standard. We are passing the basic checks there, you get a nice great check mark. The use this here is that in case you are doing signing of existing PDF-wise then so far we were signing some kind of stub signature widget which was on the first page, zero size top left corner and now we can actually create some visible signature widget which is semantically associated with the actual digital signature. So you get a user interface which is quite similar to existing signature lines in writer or impress and draw your signature rectangle somewhere, you get a nice vector on graphic there, use the correct PDF markup and once you've drawn some rectangle you can find you that in case the size or the position is exactly what you want and then you actually do the digital signing. As a combination of these I believe currently this is a bit better than what you get from docuSign or Adobe Acrobat. So that sounds pretty nice. The question is like in case you are more interested in the technical details how all of these features are actually implemented. So one thing that we added was signature descriptions, Iwaxamal and PDF-4D has markup for this and we were losing this data. You can also refer to this signature commands or signature reasons. I have the entire block was dedicated for this, it's on the slide, you can click on that in case you are interested in even more details. The point is that this way it makes sense to have the same signature for same signing certificate in multiple signatures because in the description you can actually state what's the reason of your signature signing and perhaps you want to first state reason A and later reason B and then use the same signing certificate for the same document multiple times. You can also do the import of the signatures from Iwaxamal. As mentioned this required an implementation of the relationship transform algorithm. That was a bit tricky because the ECMO version and the ISO version of this algorithm is actually different and I believe there was a bug in the ECMO version so if you implement the ISO version then you will get the same result that Microsoft Office has. There is a small SXPARS in the in AXAMAL security to actually read this Oaxamal signature and this was the first case where we are still we were still just supporting ZIP based formats like Oaxamal and PDF but there is no longer a hard-coded saying if this is not ODF then it's impossible to digitally sign this format. Then once you could import and verify those signatures you perhaps want to add your own ones. So in the Oaxamal case each new signature has new XMF string in the ZIP package so that's somewhat nice because you can't easily break existing signatures or actually it's harder to do that by accident on the other hand it requires some bookkeeping on how these signatures are referenced and so on. Also some refactoring was done here so that most of the signing logic is moved outside the dialogue so that it can be triggered from CPP in it tests. Following the verification of existing PDF signatures this is just happening automatically when you are opening some PDF file and we have some UI where you can actually try to discourage users from editing the file in case it has signatures because in case you are editing the file then you will lose your signatures. I think PADDES support require basically improvements to the hashing and encryption algorithms that we support and also there is some SPAC on exactly how to embed this signing certificate to the existing binary signature and if you implement that then you get this nice green check mark from the DSS validator. There was a separate tab for this exactly the SHO256 and the ECDSA support. I was personally interested in that because there is some Hungarian electronic ID you can get as Hungarian citizens and there is a signing certificate on that and if you get some certificate reader then you can actually use this for signing and this is recognized by the government and whatnot. So some real hardware based signing. I know this is working on Windows and Linux and what was really challenging there is that ECDSA support is not working in this order in this API that we were using for encryption and hashing. So I know we wrote that part to use the Microsoft cryptography next generation, this CNG API and that's working nicely. The last piece was this visible PDF signing where I tried hard to reuse existing code. So this is very similar to signature lines but you may know already from Brighter and Kog the generated visible signature object is actually reusing the existing export shape to PDF functionality so it's nice vector based and also then we are copying this PDF object from the shape PDF to the final PDF using code which is reused from the insert PDF image functionality. Last as always don't forget that Colabora is an open source company so what we do and share with the community has to be always paid by somebody and in this case the Dutch Ministry of Defence in cooperation with now and of a small Dutch company made this work by Colabora possible. The majority of the functionality presented in this call was paid by them so a huge thanks to them and this is a great feature set and it was possible due to them. So as a summary the good news is that compared to the original OpenFish org feature set we support this Xodes and Podesta extensions, the baseline Spark, we support modern hashing and algorithms, you can sign not only audio but OXM and PDF wise. This is working nicely to the matching products like Microsoft Office and Dacrobat for us and the new this year was this visible PDF signature. Thanks for listening. Bye bye.
OpenOffice.org and how we developed new features signing, which is basically digital signing for understand what existing PDF parsers we have in press document from some PDF file but in case you creating new PDF files with signatures in done only necessary to parse what's produced by our was the first case where we are still we were some PDF file and we have some UI where you can encryption algorithms that we support and also nicely. The last piece was this visible PDF