OOXML PDF Digital Signing in Draw and elsewhere
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 45 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54642 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 202022 / 45
5
9
14
16
19
26
28
34
35
40
00:00
Virtual realitySimilarity (geometry)Core dumpMetadataElectronic signatureSinguläres IntegralAlgorithmComputer hardwareLeakSoftwareCollaborationismHash functionFree variables and bound variablesParsingFormal verificationStreaming mediaGUI widgetLine (geometry)Markup languageShape (magazine)Computer fileSign (mathematics)Digital electronicsRSA (algorithm)MultiplicationCondition numberChecklistSet (mathematics)CASE <Informatik>RandomizationSubsetParsingElectronic signatureCombinational logicMereologySoftwareReal numberHacker (term)Complete metric spaceContent (media)Formal verificationComputer fileParsingFree variables and bound variablesHash functionSign (mathematics)Projective planeComputer hardwareMarkup languageLeakAlgorithmMetadataFile formatInformation securityRevision controlResultantSoftware bugImplementationMultiplication signMultilaterationPublic key certificateState of matterDescriptive statisticsPoint (geometry)BlogSlide rulePosition operatorTunisRectangleVector spaceGreen's functionValidity (statistics)Standard deviationLine (geometry)Service (economics)WindowOffice suiteoutputBitLibrary (computing)Partial derivativeMatching (graph theory)Level (video gaming)Product (business)Extension (kinesiology)Latent heatSystem callGUI widgetInterface (computing)Functional (mathematics)Medical imagingCodeString (computer science)Insertion lossObject (grammar)ChainRootCryptographyEncryptionProcess (computing)Student's t-testCode refactoringExecution unit1 (number)Core dumpCollaborationismOpen sourceShape (magazine)User interfacePublic-key cryptographyUser-generated contentLoginStreaming mediaToken ringSingle-precision floating-point formatGraphics tabletImage resolutionMusical ensembleOpen setReading (process)Electric generatorMassDecision support systemForm (programming)CalculusHybrid computerHexagonBinary codeBeer steinComputer configurationRaw image formatArmTheory of relativitySystem of linear equationsOrder (biology)VideoconferencingOffice <Programm>Web pageAxiom of choiceDifferent (Kate Ryan album)Computer animation
Transcript: English(auto-generated)
00:03
Hello, this is a talk about OXML and PDF digital signing in DRAW and ENSWAR This talk is meant to be focused on X.509 certificates, creating signatures using that and verifying those signatures
00:24
So I won't really be talking about all these GPG-based signing, which is a different piece Regarding me, perhaps I'm already familiar to many of you I'm Miklos Shainov from Hungary, I've been a collaborator for many years now
00:43
I started here as a GSOC student around the writer RTF, import and export And nowadays I mostly do things around write-on So let's start with an overview regarding what was already available as digital signing
01:06
as a feature set in OpenOffice.org and how we developed new and new features on top of that and then we reach what's new this year So the digital signing we had in OpenOffice.org was just limited to ODF signing
01:30
We literally had hardcoded conditions in the code saying in case it's not in ODF It's impossible to digitally sign something
01:45
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
02:02
For digesting, only this ODF 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
02:25
Regarding the verification, the process is somewhat straightforward So it can do checking if the digest is matching, which means in case you modified the document as an attacker We have a different digest compared to what was signed and we can detect that the document is modified
02:46
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, that also fails the validation
03:05
It's also an interesting attack that you can append some new strings 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 X.509 certificate, so not JPG, that was added later
03:30
The first thing I did four years ago was OXML signing Which is basically digital signing for docx, xlsx and pptx formats
03:43
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
04:00
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 we never sign metadata for OXML files
04:23
This is probably because Microsoft wants to upload the files to SharePoint and tweak the metadata there So if you open the files in LibreFest, then the LibreFest standard is that metadata should be part of the signature
04:41
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
05:04
Somewhat interesting is that there are these different transform algorithms In the XMLD spec And compared to ODF there is a special one
05:22
In the OXML spec there is a custom algorithm We offload most of this XML signing work to the OXML spec library And that has a hardcoded set of transforms that it's supporting So I had to go to the OXML spec library, add support for this Relationships transform algorithm
05:44
Because that influences what's the input data that will be used for hashing And once this was contributed upstream then we could use it for OXML signing purposes Sadly the OXML signing markup is a bit awkward
06:03
One 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
06:25
And it's a very interesting question, what's your Windows version if you use LibreOffice on the Mac or Linux So we have some hardcoded stuff there We pleased what Microsoft Office requires there, but it's not really leaking your data
06:42
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 initially done as a GSoC project and then Tor Lyrquist completed this
07:01
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 X.509 certificate
07:21
This PKCS 7 spec defines how to do a binary signature on the hash of this original content And then we do a hexdump of this signature and put it to the placeholder inside the PDF file And what's not used from the placeholder is just filled up with padding
07:43
So this is for new PDF files and for single signatures Then we wanted to improve this so that we can also verify those signatures And this requires digging into quite some layers So first I wanted to understand what existing PDF parsers we have in LibreOffice
08:08
Because of course we had multiple ones So at that time we had three Poplar is used to have some editable ODG file out of some PDF input in draw
08:24
Then the primary problem there is that this is not available in all builds In case you are focusing on MPI subset builds then 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
08:44
So that you can get back your original writer 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 PDFium
09:04
But at least back then it had no API to extract all this initial details which is needed by us So we needed some solution where we can just build the missing piece ourselves So I went ahead and added the first PDF tokenizer
09:21
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
09:40
And just 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 these signatures are changed by definition
10:03
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
10:20
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 ingested content between the signatures inserted by some attacker
10:46
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
11:02
So once you can verify a PDF signature then, of course, you want to create PDF signatures And I started creating new PDF files with signatures in them That was already supported But you can also take existing PDF files And perhaps the user says
11:21
I just want to sign this So this is not working But all combinations of LibreOffice creating PDF files, Adobe Acrobat creating PDF files And then creating the initial signature Then second and third signatures
11:40
And swapping between the two softwares So that's lots of combinations But at the end 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
12:04
Previously it was only necessary to parse what's produced by our own exporter The one thing you can do on top of existing XML signing and PDF signing
12:23
Is that there is a set of recommendations on top of the XMLD SIG recommendation On top of the PDF spec This Exodas and Padas signing
12:42
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 LibreOffice To create such signatures
13:03
One thing was that the SHA-256 support The digesting algorithm was missing And now it's possible to do that Also just RSA was supported
13:21
ECDSA support was added And one very important piece is that You have to make sure that not only a certain private key was used to create a signature
13:42
But also what was the original signature Because 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
14:01
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 digit signature service validator
14:25
Which can check if you are confirming to different baselines of this PADAS standard And we are passing the basic checks down You get a nice green check mark And the use this year is that
14:43
In case you are doing signing of existing PDF files So far we were signing some kind of stub signature widget Which was on the first page, 0 size, top left corner And now we can actually create some visible signature widget
15:03
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 in press And draw your signature rectangle somewhere
15:25
You get a nice vector graphic there Use the correct PDF markup And once you draw some rectangle You can fine tune that in case the size or the position is exactly what you want And then you actually do the digital signing
15:43
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
16:02
So one thing that we added was signature descriptions UXML and PDF already has markup for this and we were losing this data You can also refer to these signature commands or signature reasons I have the entire blog was indicated for this
16:20
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 signing certificate in multiple signatures Because in the description you can actually state what's the reason of your signature Perhaps you want to first state reason A and later reason B
16:43
And then use the same signing certificate for the same document multiple times You can also do the import of the signatures from UXML As mentioned this required an implementation of the relationship transform algorithm
17:07
That was a bit tricky because the ECMA version and the ISO version of this algorithm is actually different I believe there was a bug in the ECMA version So if you implement the ISO version then you will get the same result that Microsoft Office has
17:24
There is the smallest exposure in the ECMA security to actually read this UXML signature And this was the first case where we were still just supporting zip-based formats like UXML and ODF
17:41
But there is no longer a hard-coded saying if this is not ODF done 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 UXML case each new signature is a new XML string in the zip package
18:06
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 required some bookkeeping on how these signatures are referenced
18:22
Also some refactoring was done here so that most of the signing logic is moved outside the dialog So that it can be triggered from CPP unit tests Regarding the verification of existing PDF signatures
18:41
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 further support required basically improvements to the hashing and encryption algorithms that we support
19:10
And also there is some spike on exactly how to embed this signing certificate to the existing binary signature And if you implement that at the end you get this nice green checkmark from the DSS validator
19:27
There was a surprise tab for this exactly at the SHO 256 and the ECDSA support I was personally interested in that because there is some Hungarian electronic ID
19:45
You can do that as a Hungarian citizen since 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 what not So some real hardware based signing
20:01
I know this is working on Windows and Linux And what was really challenging there is that ECDSA support is not working in this other windows API that we were using for encryption and hashing So I rewrote that part to use the Microsoft cryptography next generation, this CNG API and that's working nicely
20:30
And the last piece was this visible PDF signing where I tried hard to reuse existing code So this is very similar to signature lines in what you may know already from Breiter and Coq
20:45
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 that shape PDF to the final PDF using code which is reused from the insert PDF image functionality
21:13
Last, as always, don't forget that Collabura is an open source company
21:21
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 Noun and Of, a small Dutch company, made this work by Collabura possible The majority of the functionality presented in this call was paid by them, so a huge thanks to them
21:43
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 OpenOffice org feature set, we support this XODAS and PODAS extensions to the baseline SPAC
22:02
We support modern hashing and algorithms, you can sign not only audio but OAXM and PDF files This is working nicely to the matching products like Microsoft Office and Acrobat files And the news this year was these visible PDF signatures
22:20
Thanks for listening, bye bye