Why digital signatures are not a substitute for MACs
This is an addendum to ISO 32004: an overview with some additional background information on how MACs (Message Authentication Codes) differ from regular signatures, and what that implies for their usage in PDF. It's best read in that context.
If you've dabbled in PDF-related development before, your first thought might be "Wait, why are we having this whole integrity protection conversation? Can't you just slap a digital signature on your encrypted files and call it a day?".
That's a very natural question to ask, and you certainly wouldn't be the first one to raise the point. That said, MACs and digital signatures really aren't interchangeable. Some of the differences are intrinsic, others have more to do with how digital signatures are used in PDF documents and how PDF software processes them.
First, MACs and signatures are based on completely different cryptographic principles.
When protecting an encrypted PDF document using a MAC, we want the MAC key and file encryption key to be computable from the password (+file data). With digital signatures, that's not possible: the key material is unrelated. In fact, due to the way PDF encryption works, it's perfectly practical to add a signature form field to an encrypted document and sign it with any old key without even knowing the encryption key! Surely that doesn't qualify as "authenticated encryption"?
ISO/TS 32004 only deals with encrypted PDF documents, but generally speaking, there's actually nothing about MACs that makes them only applicable to encrypted data.
It's just that, when operating on encrypted PDFs, there's already a shared secret to work with, and that's convenient to bootstrap from. There's no technological reason why one couldn't also define a password-based (?) integrity checking mechanism for unencrypted PDFs. Whether that's a good idea is of course another question.
Additionally, the asymmetric nature of digital signatures comes with a lot of added complexity:
MACs are a lot simpler.
It's easy to simply validate a MAC token when an encrypted document is opened, and throw up an error if there's a mismatch. On the other hand, with digital signatures, validation could fail for a lot of reasons 3. In addition, reasonable people can disagree on all sorts of policy questions related to signature validation. That complexity has several knock-on effects:
Given how long both file encryption and digital signatures have been around in the PDF ecosystem, it's safe to say that no vendor is going to adapt their viewer to perform signature validation prior to displaying a document. Not that that'd change anything, though: users would still just dismiss all the warnings to see the file anyhow.
MACs do not require any trust assessments and are therefore a lot more black-and-white. When opening an encrypted document with a MAC, a MAC verification failure can simply 4 be treated as a decryption error.
In PDF-land, adding a signature to a document is a fairly invasive operation, and the various bits and pieces of metadata that come with it can impact how the signature should be understood in context. Moreover, unlike most other digital signing applications, a digital signature in a PDF file can be visually part of the document content displayed on-screen!
In other words, signatures in PDF documents can have a significant semantic impact. This, to me, is a strong argument in favour of considering signatures to be true document modifications as opposed to mere augmentations.
Used properly, MAC tokens are semantically neutral, and therefore don't have any of those issues. What's more, ISO/TS 32004 MACs have the ability to also authenticate signature additions directly, just like any other edit.
When working with encrypted documents, MACs are a simple solution to a simple problem. They allow you to answer the following question: "Did the last actor to modify this document know the encryption key?".
Digital signatures and PKI address something much more complicated and vague, ranging from questions like "Who authored/approved/countersigned this document?" over "When was this document known to exist?" to "On whose authority are all these assertions based?".
As such, it's not surprising that they require more baggage to process correctly.
What if one were to replace the MAC with a signature using a key pair for which the private key is known among all participants? The signature could simply use self-signed certificates (perhaps with some custom extensions). Wouldn't that amount to pretty much the same thing? If so, we don't have to adopt any new technologies.
I don't feel qualified to comment on whether one could provably recover the same (or roughly similar) security guarantees of a comparable MAC function with such a construction. It sounds plausible enough, so for the sake of the argument, let's assume that this "disguised MAC" idea is cryptographically sound.
Even so, I don't think the idea simplifies things in PDF applications. Here are a few reasons why:
Bottom line: MAC functions like HMAC are widely implemented and known to do very well in exactly this kind of use case, and insisting on using signatures would make things more confusing than they need to be.
Oversimplifying slightly, I like to characterise the difference between MACs and signatures (in the PDF context) as follows.
So, can MACs replace digital signatures? Absolutely not. But given the way signing is used in PDF, neither can digital signatures fully replace MACs. Both have their place.
1: Document timestamp signatures (see ISO 32000-2:2020, 12.8.5]) would fall into that category. Those are a statement by a time-stamping authority asserting that it witnessed a document at some point in time. That obviously has no bearing on the authenticity of the document's contents. ⇐
2: If this sounds like an unreasonable assumption, then I have bad news for you: regardless of which authentication scheme you choose, it's going to fall apart if you can't trust all (authorised!) parties involved to do their due diligence. ⇐
3: Those reasons can be very mundane, e.g. lack of network access. ⇐
4: In theory, that is... In practice, given that ISO/TS 32004 is not part of the "core" PDF spec, there are compatibility issues to keep in mind. ⇐
A version of this article was originally posted at https://mvalvekens.be/blog/2022/about-macs-vs-signatures.html.
Independent PDF expert and FOSS developer, co-representing the Belgian standards body NBN in ISO/TC 171/SC 2. I’m the current project leader for ISO/TS 32004. I was employed as a Research Engineer at iText in Ghent between 2020 and 2022. Before that, I spent a few years doing mathematical research at KU Leuven, where I obtained my PhD in mathematics in … Read more
Independent PDF expert and FOSS developer, co-representing the Belgian standards body NBN in ISO/TC 171/SC 2. I’m the current project … Read more