 Hello, good morning. I would like to talk about some improvements regarding to the existing feature This digital signing in LibroFist I guess half of you know me already, but in any case I'm from Hungary I got involved with LibroFist and previously OpenOffice Coding due to Google Summerf Code I did a re-implementation of the writer RTF import and export filters and Ever since then hooked into writer Most recently doing this for Colabor so the topic for this talk is Digital Signature Handling so the feature itself is that you can digitally sign a document and There can be two cases when you open it again a door. It wasn't altered So you just get some Hard to notice sign at the bottom of the toolbar saying that the document is correctly signed or in case somebody Nasty did some nice in a modification to the document behind the scenes that you have this beautiful dialogue explaining Hopefully explaining what the situation is and the whole purpose of this digital signing is Or this feature is that in case the document has been modified that this Dialogue should fire and in case it hasn't then it should not Say that's a that's the primary expectations so I would Go through what but are the results of these improvements, but you see as a user and then I would go Into details how this is actually implemented So the first thing is that if you over through and try to do Two signatures with the very same certificate and a document then you might have noticed that this is not possible I Guess the reason for this was that it didn't really have any meaning to sign a document twice with the same certificate so because Some customer needed wanted to have this ability. I came up with this concept of Signature descriptions, which is really similar to what Microsoft Office has I guess they use it they call it reason or role or comment or something But they this basically or refer to the very same thing So next to just using the certificate for signing you can provide some string and then it may Make sense to Sign the very same document multiple times You can state the Reason for that different signings in this in this train One more thing I learned later is that it turns out unless you are really into these cryptographic things You probably don't know that What is signing works with the private and public keys like you use or your private key to Make it sure that it it was really you who signed it and anyone else can just Do the reverse coding and verify that that was really you but actually the signing here Works with the certificate and then can be multiple certificates with the very same Private key at the moment LibreOffice doesn't really differentiate between these two. So in case you used one certificate for signing and You replace that certificate with an other one and in case they have the same private key Then you can replace this certificate and nobody will notice this Usually this is not a problem because typically one certificate is one private key But in some situations this difference is Interesting and that's that's something that can be still improved The next thing is that the show 256 support Privileged slave. We only supported a show one hashing for for the hashing of the document before you actually sign it the problem is that It it no longer has any strong It it's not considered to be legally binding anymore for quite some time now So to be conservative what I did is that and now we can read this strong or hashes and After some some transitive period when all of the supported LibreOffice versions can read this Then we can also switch on the writing of these strong harshes And This is for the ODF case the work some all Markup for this is much newer. That's that has the stronger harshes Right from the beginning Which leads us to the First more complex features next to this signature descriptions The import of or verification of Oaxama signatures Luckily, it's really the same markup for docaxx, xxx and pptx Basically the but what was a bit challenging here is that Ideally they both the ODF markup and the Oaxama markup is based on the very same W3C recommendation But the recommendation only describes how to what markup to use for a single signature and It doesn't really say how to Store any metadata like a description or a signature date or anything Those it doesn't talk about how to store multiple signatures And it's a very frequent use case that a document is signed by multiple people And of course Both ODF and Oaxama came up with their own markup for these cases, which are not specified This is one thing to do you can basically look how the ODF import and export of these signatures look like and Based on that and based on reading the Oaxama specification you can implement something but more problematic is that at least the ACMA version of the Oaxama specification is quite incomplete Regarding digital signatures. So if you just implement what's written down you won't get what Microsoft of it does Now after a few days of debugging I Realized that the ISO version has a different wording Like just the number of steps in the algorithm is is already different And if you implement the ISO version then you get the matching hash So the lesson learned you should Look at the ISO version in case you ever look at something regarding Oaxama That's a more up-to-date and in some cases like this It's a it's a hard requirement to actually implement what's done So with the import or verification that means that in case an Oaxama document has been signed And we have two copies one is left unchanged and the other one is It's just a zipped axama file so you can change it Then LibreOffice can correctly say that one version is signed Correctly and in the other cases raise this scary dialogue And One detail regarding the good signature is that the Oaxama signature is not as strong as the ODF one I'm not saying this for political reasons is just for technical ones Oaxama intentional it doesn't sign the metadata of the document And that's a pretty problem. I think we will see it later when you store your custom You document properties into the document It's allowed to change these without breaking the signatures in the Oaxama case That's what Microsoft Office does and that's why The Oaxama filter in LibreOffice does the same and So basically not all the streams in this zip package are signed while in the ODF case All of really all of the streams are signed so that But this means to you as a user is that in case you open a valid or correctly signed ODF the ODF document Even the title of the window is changed to signed and and everything is perfect But if you open a correctly signed Oaxama document you get a small warning in the status bar saying that The certificate is correct. The all the signatures are correct, but not all the streams are signed So we don't consider a valid Oaxama document correctly signed Oaxama document as a perfect signature once The import of the verification of this Oaxama signatures following the next step was exporting them So That's a bit harder because on import in case you don't need something then you can just ignore it So basically you get in this very rich markup Of an Oaxama signature and you just extract the details You need to be able to determine if the signature is valid or not While on export you are supposed basically writing everything back. I say You need to find out what part of the markup specification is optional and not and so But at the end I came up with something that makes Microsoft office happy I need to add this differentiation between ODF where we sign all the streams and in the Oaxama case where the method that they is not signed Also, what's really scary is that the Oaxama or at least Microsoft Office requires Leaking various hardware details of your machine like your display or resolution and other crazy details into the signature And if you don't do that then the signature is not verified by Microsoft Office So and of course your Microsoft Office version and Windows version and whatever has to be leaked out That's not joking. This is serious say But LibreOffice does is that I took one configuration of a virtual machine and we do this hard wire values there so LibreOffice won't leak the very same detail there But we still write something to make Microsoft Office happy Once all these Signature description and the Oaxama import and export was done. The next thing is Slight slightly are related to the actual signing this Classification feature with the classification toolbar But we will see in a minute how they these connect together so One use case is that you are working on an organization and you have some long legal attacks You are supposed to follow and as a human being you probably don't understand that tax Even if it's a syntactical a valid in your language So it would be wouldn't be it'd be nice if LibreOffice would help you respect these rules See one solution for this is that there is a Stunt organization called the SCP as in I guess I will resolve this abbreviation later and they produce a number of standards how to turn these long and hard to understand legal attacks into some markup that's a that's machine machine Parseval and also they came up with the specification how to refer to the I call this a policy and And this policy basically contains different categories on If something is totally public or it's something you shouldn't share outside the company and stuff like this and They also came up with the specification how to refer to these policies from undocumented What's really nice about this is that they are a vendor not neutral So it's not a problem if LibreOffice implements this as is because it's not tied to a single vendor You can buy for a good amount of money For example Word plugin that does something similar, but all your documents will have under specific tasks So you are not allowed to change to a different vendor anymore But we do is something that's produced by an independent Organization producing these standards See The first cut is that you have this classification toolbar It's not enabled by default because I guess it's not interesting for most of the users, but still you just Choose you two bars and you can take it in and You get a toolbar where you have a drop-down Where you have these categories from the policy LibreOffice came with a very lame example policy I came up with those names. So I don't take it serious seriously But hopefully each category demonstrates some feature of what the policy such a policy can describe So you get the idea and then if your organization has some return legal tax policy them you can turn that into Such a machinery about policy basically what it has is that There can be a color line above the document that always stays there as an info bar Similar to the one when you open a documentary don't you or something? and if it's close to green then it's something that's a Public if it's close to red, then it's must be very secure Then the policy may require that you have some tax in the header and the footer of each page It may require some watermark behind the tax What to us it stores the Date on the timestamp of the actual classification Stuff like this and all these is stored as a metadata of the document That's why it's important that in ODF we signed the metadata That means if you classify a document and you sign it then the class classification can be changed without Someone else noticing and this only works for we do the F not we don't work someone It turns out the specification also allows multiple categories as in Your your legal tax may specify that in one case like with communicating with one customer This is secret but communicating with some other customer. This is okay to share or something like this And actually the the standard came up with exactly three different Types Where you can choose these categories so the toolbar has this but it's not exactly clear How the user interface should react in case you have this conflicting category selections say as the Help page states the user interface in LibreOffice currently just always reacts to the first Selected so the left most Selected category So basically that's what you see as a user and the question is How does it work behind the scenes? So as I mentioned there is a recommendation from W3C Which is really just the core of a single signature? and they have The open document format. I didn't check the history, but at least the current 1.2 Version have different parts and the third part was a section on the digital signatures file It's not very strict. It allows you to add new Metal data to the Signature itself. So one existing meter that was an actual time stamp of the signature But I Added a signature description and it's okay to add these so it's not invalid in in all the of terms to add Such new metadata key value parts As I mentioned them them in the Oaxama case the ISO standards Document this Quite fairly No in case in from the code perspective Of course I don't want to get involved much in all this heavy lifting or on keep Cryptography because if I do this and do is the there will be boxing it on that would be very bad for such a Feature that's supposed to be serious and so on same every in the LibreOffice code base delegates most of the hard work to an external library called the Librex Amasak and it does the the creation and Verification of the signature No next level of Obstruction or the next layer is that Librex Amasak X Amasak itself doesn't implement all the cryptography itself But it has different backgrounds and on Windows. There is some native Microsoft API to do this and on Linux and Mac OS Currently we use the Anasas library from Mozilla Probably for the Mac OS users. This is pretty terrible because I'm sure there is some native API and That's the current situation is quite suboptimal, but at least it's something working On Linux, it's it's again a bit more and more Not very general that everyone has a valid Firefox or Mozilla profile, but at least it's not as weird as on Mac OS See the I wish that Librex Amasak Provides everything but I need for for the features are presented earlier The problem is of course it does not So These are just comment messages I sent the Librex Amasak external the most important part was that the Oaxama specification Defines the new algorithm as in basically it's just an XAML identifier and the description how An XAML 3 of no node 3 nodes should be transformed to something asked that's on an algorithm in W3C terms and The Oaxama specification Defines an algorithm how to filter out the metadata from from the document before you actually hash it and sign it and Because all the algorithms are handled that inside the Librex Amasak. I had to implement it down Which means writing C code that please is not only GCC and clang, but also MSVC Where the C support is not updated in the past 15 years or something because customers are not interested in that So that's very much funny But at the end I came up with something that implements the Specification and even boy builds on every platform we care for By V car for I mean It turns out it's a mostly only Libre office that the curse of out the Windows part of Librex Amasak, which is very sad again a situation when I touch this something and know I'm called as the go-to guy for any issues At least they didn't use the word maintainer So I had to fix up The Windows build in the next release that incorporated this This relationship transform algorithm because the maintainer tasks only only nox and macOS so that Included fixing a problem that the Librex Amasak has Two build systems. Have you ever heard about such a problem in a project having two different build systems? So they do have they use autocom for for a Linux and macOS and they have some Handcrafted make five for Windows and when the configure was Adopted and the windows make five wasn't and this way it didn't be odd then we had some patches for the newer visitors to the version and Those were not upstream so that's now also included in the latest upstream release and those so there were some changes around How you select these different backends in the LibreOffice case We always use a single backhand But at build time you could build Librex Amasak in a way so that you can select the backhand at runtime And again, the maintainer is only interested in in the case when you choose the runtime The backhand at runtime, but of course we go with the other parts Where we choose the backhand at build time so that means on Windows this Selecting of the runtime at build time was resulting in a big build failure So after my struggling No, I Managed to rebays on our Librex Amas patches on top of the latest upstream layer release and also all my Additional patches I had in the LibreOffice core up who I upstream AR upstream So Basically this explains how how the ODF signing Was extended and implemented even in the technical terms Now the next problem was that LibreOffice had this assumption that That That in case the document can be signed then it must be ODF because that's the only format supporting signing But I wanted to add the this Oaxamon support. So I introduced a new filter flag called support signing and In case we are not ODF, but this plug is sad then we still attempt to sign We still Assume that in case we can sign something that's zipped XAML because that's true for Oaxamon and ODF But in case later we would like to do I don't know open a PDF file in drone and sign it for example Then that would be yet another saying to To fix because currently we assume zipped XAML And the description feature isn't Really really complicated in the ODF case as I mentioned you could add the new method without break and without generating invalid ODF And also It's important that a document in case a document has some signatures already then you have to round trip if 100% perfectly otherwise the hash will be broken So for that reason in case the description is empty then we just don't just don't write it and this way previous Signatures which and don't have a description are also run trip correctly The Oaxamon case was easier because that wasn't supported earlier and also an Oaxamon mandate is this comment or description The actual code that generates the markup for the Oaxamon signature and and the part there is pretty Straightforward there are not many complicated things there under the axema security module. There is a dedicated class that handles these Sucks evens and there is a sterilizer that that actually arise the markup The Classification to a bar is basically just a user interface you could go to five properties and put and then send all these Properties of the classification yourself and you can change it So it's it's not a sacred that you can break it the whole purpose of the feature is to help you in case you are willing to Follow some some policy in any way So it's not hidden from these Custom document properties or anything and as I mentioned The organization that's passive and that came up with this specification is this a trans grower secure collaboration program they are actually a company even if it's a program and and There is a framework for how to describe these these legal attacks in some technical form This is the BAF and the other relevant specification from them is how to refer to these specifications From the documents and that does the bareness of certification so basically the Work and the flow is that you have the legal attacks Then you turn it into a policy and then LibreOffice embass this BAF you part into your documents and the you are inflected So all this work that I presented here was supported by the Dutch military Which is really great because Colabor is a consulting component So somebody has to pay for the work we do and then concludes my talk. Thanks for your attention