I feel there are some fundamental misconceptions about signatures that are baked into many of these older standards. There have been similar attacks on XML signatures, email signatures and PDF files (with some overlapping authors).
It usually comes down to creating some complex formats where signatures are allowed to sign sub-parts of the information. This is an extremely fragile design, and should probably be considered broken unless proven otherwise.
Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous.
Yes though there are other large classes of error, I've had editor makers insist that they want their signed document format to include code and be signable. "Is that date fixed or calculated from the current time?"
I guess hypothetically in an extremely niche situation— signed documents for coders who can actually read the code and decide they want to sign whatever it output—that could make sense… but I can’t imagine any market for such a tool.
They didn't want to upset people who used macros for footer page numbers and other boilerplate. Naturally the general code capabilities preceded the interest in adding signatures.
The page numbers seem important, in the sense that the sudden removal of a bunch of pages from a contract ought to be easy to detect. But maybe your co-workers were so fundamentally honest that they couldn’t think of the duplicitous applications there.
JWTs are the poster child of fragile signature design. If something is like JWTs, you should reconsider. Many implementations allowed JWTs with a null signature scheme, completely bypassing any security!
The assertion was that allowing signatures for sub-parts of the information is extremely fragile. Your example of null signatures being allowed would equally affect sub-part signing and whole document signing, so doesn't really show that sub-part signing is a problem.
It’s also difficult to actually get people on board with the idea of supplying a user-specific signing key instead of relying on a global one.
Instead they’ll end up persisted in a data store, making them stateful, because there’s no reliable way to invalidate such a token simply by rotating the signing key. Or using a cookie-backed session.
Can you be more specific? a JWT's structure is really simple and easier to process compared to what came before (SAML, etc).
I accept there's fragility in the wider distributed-authX/federation ecosystem (e.g. browser cookie policies breaking OIDC), but that's not inherent in JWT.
Nothing in that article mentions any kind of "fragility" in JWT's design - and the issues it documents (e.g. consumers overrwriting the signature portion) concern only extremely non-compliant (i.e. dodgy) JWT scenarios - which sounds like someone applying a bodge because they were forced to implement JWT because it was thrust onto them, usually because JWT is already so popular already - so it's nothing inherent in JWT specifically, but any kind of distributed, non-opaque and structured authX/id-token would suffer from the exact same problems - though I appreciate the textual-basis of JSON and JWT lower the barrier-to-entry-for-bodging compared to binary formats like ASN.1 (though I speculate that if we had to use a binary format today I think things would be a lot worse overall, due to second-order effects of using a binary format, e.g. relating to higher barriers-of-entry).
No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format.
It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.
It is indeed an appeal to authority. And, if you read the comment again, you'll see that you're agreeing with me: hearing that JWT is bad surprised the previous commenter precisely because we've stopped having meaningful discussions about whether JWT is good; it isn't, the case is closed, there's not much more to talk about.
And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null".
So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.
You should be validating all protected headers, in much the same way as border patrol should reject a crayon drawing of a passport.
JWS (and JWT) standardized interoperable parameters and what they mean, but applications are supposed to standardize how they are used.
An integrity protected message used as part of a transaction, one used to represent user state, and one used for document archival are going to have dramatically different requirements for verification metadata.
Similarly, a signed message issued by a single site vs one meant for use across a federation will have different requirements.
This is the #1 misconception of JWS/JWT which has led to people mislabeling it as insecure. They are only using the half that defines what fields mean, and ignoring application-specific instructions on if they are supposed to accept and how they are supposed to process those fields.
The point of input in any case is that you are going to validate it and then process it. Any input that isn't validated should not be trusted, even in the most benign scenarios and triply so in security relevant contexts.
Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algorithm, if results come back valid, all is good. Results come back bad? Reject the input without trying any of the other 19 algorithms you support and trust on the input.
As you can see here, the purpose of the field is to make it easy to validate the token without having to try all the algorithms that you might support. If you support 20 algorithms for something, you don't want to have to try all of them. But you do have to know which algorithms you trust. It's really not different from an SSL negotiation. You know which algorithms you accept/support, the other side knows what algorithms it accepts/supports. If you can't find one both of you support: tough luck!
The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that the JWT scheme punts that complexity and "make sure you hold it correctly!" onto the application is bad.
Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.
For example: simply take a valid identity's public key, and use it as the secret to forge a token with alg=hs256. A service receiving this token will use its copy of the public key (by key id) to verify the signature, but because it's being told that it's an HMAC-signed token, will construct an HMAC.
Of course this HMAC will verify correctly because both you (the attacker) and the server hold the same public key used. And now the server thinks its a legitimate JWT because the signature is valid.
Mixing symmetric and asymmetric cryptography types in the same message scheme is just one of the many ways in which JWT is a bad idea.
I really don't think this is an intrinsic problem at all.
I've written JWT-parsing code and it looked for a local public key if it got an RS-algorithm and a local secret if it got an HMAC algorithm. It would be an insane implementation to treat either of them as the other.
Yes. This is definitely one of the weaknesses of JWT. It is prudent to whitelist the allowed headers. And the fact that any implementations accepted `null` as an algorithm is awful.
They also don't want to share two files, one for the file, one for the signature. Ideally, it's integrated, which means there needs to be some management. And ideally, it's also applied to the data before it's compressed, so that you can apply advanced compression and deduplication to archived documents like zopfli for example.
Right, that much makes sense. The point is that the signed file being part of a larger container does not immediately make the signature of the signed file, as a whole, useless.
I discovered a related problem before, while integrating with an enterprise customer/partner. Some critical software they used was erroneously signing&validating the wrong part/extent of a very security-sensitive message.
I raised the issue on my company's end, and we had to explain to the customer/partner their big problem.
> On macOS, we could reveal a surprising result: although Microsoft Office indicates that the document is protected by a signature, the signature is not validated.
I wonder whether someone discovered the incorrect digital signatures approach while working with the code on the occasion of a MacOS port/implementation, slammed the brakes on that while escalating the issue internally, a decision was made to keep it quiet, and the MacOS implementation was shipped just stubbing out the signature validation behavior (or otherwise made to always claim validation OK)?
I wonder whether these broken digital signatures were exploited in the wild. Were forged invoices paid, or banking details changed, while trusting the signature? Was a digital signature held up as evidence in legal proceedings? Are there any automated systems that rely upon the digital signatures in these documents?
> acknowledged and awarded our research with a bug bounty.
Rather than just uncomfortable conversations everyone wishes they weren't a part of... there's cake? :)
> For documents of prime importance, such as contracts and invoices
Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off.
Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic signature solutions don't necessarily solve it.
At least in Europe, electronic signatures of a certain form are legally equivalent to handwritten signatures [0], and are increasingly used as such. Emails don’t provide that legal value.
I think the main point the parent comment is making is that, today and historically, the great majority of contract disputes today don't involve disputing (analog or digital) signatures. People usually dispute about all the other terms rather that about the act of having signed it. [Even though analog signatures aren't particularly secure either]
However, if Microsoft signatures have now became more forgeable at scale, perhaps we could see some rash of fake contract fraud in the future where disputing fact of signature becomes more common.
The question of signing generally arises with dueling forms, where there's no dispute that "a" 20-page contract was signed on June 4, 2017, and that this is page 20, with all of the signatures, but... What did that contract say in Paragraph G on Page 12?
Perhaps the bank only retained page 20, and is saying that they used the same master form for every mortgage and the master form says "this" on page 12.
Or one party discovers that other has misplaced their copy of the contract and then shows up with a copy that has advantageous wording on page 12.
Asking for a copy of the signed documents for my corporate bank account was how I discovered that my bank’s internal processes were using one revision, and the forms they ask you to download and fill out ahead of time were a different revision, despite being the same (uniquely numerically identified) form.
They accepted my copy verbatim and scanned it right into their DMS, despite the fact that my revision was older than the internal revision it was tagged under. They scanned the -whole- document though, so the language on the signed copy is crystal clear.
The banker’s remark: “that’s unusual, no one ever asks for a copy of them signed.”
Edit: my initial draft was a grammatical mess up top
On "serious" contracts, it's common to put your initials on each page, or to fan out the stack of papers and sign the margin so that each page contains part of that signature. Both are in addition to the "real" signature at the end, and provide some protection against exactly these kinds of problems.
I guess a cryptographer would add a hash of all preceding pages on the last page.
> I guess a cryptographer would add a hash of all preceding pages on the last page.
That's basically how hashes and signatures work anyways. They basically take in the result of the previous block and integrate it into the new block so that if you change any part of the previous parts, the whole thing breaks.
Edit: I should specify this is how the algorithms themself work. Implementations can fuck this up (and they do a lot).
There are also Merkel trees, which are closer to the signature -on-"subdocuments" mentioned above. Also blockchains that explicitly include the previous block's hash.
Signing a PDF via "/s/ Name E. Name" and sending it via e-mail solves the "lost pages" issue, and doesn't require the parties to use cryptographic techniques.
The point is forgery of signatures and contracts is not typically an issue.
In contract disputes, there's usually no dispute of if a contract was signed. Sometimes there's a dispute over which contract was signed, but then each party may have a signature on a contract or not. Much more often there's no disagreement on the contract or that it was signed, but on the terms.
It's nice that electronic signing can solve the issue of validity of signatures, but it's not that big of a deal, because it wasn't that much of an issue; and that's why e-signing has devolved into 'click a button to enter a signature' without any sort of cryptography.
In the UK at least it you email agreeing to terms and then appear to be complying you're unlikely to get out of it.
Common examples are someone is sent a contract of employment unfortunately often after starting and they don't sign it. If they have been coming into work broadly in line with that contract so long as it's fair, employee and employer are bound by it.
Here is an interesting edge case in the UK [0]. Long story short if you give someone the ability to sign on your behalf and appear to consider parties bound by that it's binding.
In a personal sense, I send out appointment letters but my secretary does it for me. I consider myself as bound to that as if I arranged it myself. I gave the secretary latitude to book appointments for me, and I usually turn up to those appointments. If that letter is signed, or if it's by my hand. Doesn't legally matter as much as you'd imagine.
"An Englishman's word is his bond" as the old saying goes, verbal contracts are enforceable. The whole financial system used to run on purely verbal contracts. There are some requirements, there has to be a consideration for example. I am not sure this is true in other legal systems though.
I don't know about other places; but in the UK, a contract doesn't even have to be written down, let alone signed.
Of course, an unwritten contract is no more valuable than the paper it's (not) written on; and either party can dispute the terms. But you can still make a valid contract with a verbal agreement and a shake of hands. But don't do this unless you trust your co-contractor!
In most places, if there are witnesses to a contractual obligation being established or contract being performed, even a verbal agreement can be sufficient.
It mostly depends on how quickly courts will do the proceedings to establish that it is or isn't so.
...but apparently not always. Not something I'd want to bet my business or reputation on.
"AUSTRIA’s Federal Administrative Court [..] declared a framework contract from Austrian Federal Railways (ÖBB) to Stadler for the delivery of up to 186 double-deck trains to be null and void due to an alleged formal error in the qualified electronic signature of the offer."
(September 2021)
That is about a public tender, where there are "form requirements", meaning that certain documents and signatures have to conform to the required form. Usually that means "in writing, on paper, with signatures made by hand" or the new legally accepted replacement of secure electronic signatures. Sometimes it might even mean signing the paper in front of a notary, e.g. for contracts regarding the sale of real estate. But in general, outside clearly defined exceptions, contracts and declarations do not have a form requirement, so even oral agreement or "conclusive behaviour" (sign language, point-and-grunt, silently carrying an item to the cash register) are absolutely valid.
Of course, when in doubt, proving the exact content of such an unwritten contract may be hard.
> But in general, outside clearly defined exceptions, contracts and declarations do not have a form requirement, so even oral agreement or "conclusive behaviour" (sign language, point-and-grunt, silently carrying an item to the cash register) are absolutely valid.
Correct in the US, although it's worth mentioning the Statute of Frauds and the Uniform Commercial Code:
Which makes attacks like these even worse: Serbian law, for instance, has a clause how you are not allowed to dispute an electronic signature signed using an officially issued eID certificate.
While I am sure that clause can be nulled and voided if it came to that, the fact that the responsibility is on the signee is terrible.
True, our company constantly use certificate based signatures, and government agencies emit most documents with the same method, almost always on pdfs. Tho most people tend to use AutoFirma, a java program written by the government for signing and checking signatures validity. I would love to see it thoroughly audited too.
The service probably has nothing to do with email and is only tangentially related to eIDAS. At least that is the case in Czech Republic. One surprising fact about such systems is that they tend to produce blockchain-like audit log and predate bitcoin by several years.
I don’t know where you’re taking “click a link in an email” from, but that’s decidedly not how eIDAS works. The private keys must be hardware-protected and under the sole control of an identified signer, which usually means either a physical token or a 2FA-protected remote key in an HSM. In addition, a prior ID verification procedure like video ID or a face-to-face verification is required.
> Well. Eversign holds the key and promises to only use it when you authenticated by clicking the link in the email that was sent to you personally.
This method would most likely be eIDAS confidence level low. They (like many other providers) most likely offer multiple LoA variant but only advertise the lowest one online so you think you are "ok" with an easy to use variant but when push comes to shove you need to upgrade to substantial or high, do the full validation scheme and get a QSCD to do you signatures with.
eIDAS' levels of assurance are about authentication when logging in.
For digital signatures, the levels are 'An electronic signature', like /s/, 'advanced electronic signature', and 'qualified electronic signature'.
The first "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures."
Qualified signatures used to require that the private key was physically on some tamperproof chipcard (or similar), but eIDAS changed that. Now, you can rely on some vendor's implementation of cloud signing services that is certified to ensure(?) that "signature creation [data] [is] with a high level of confidence, use[d] under [your] sole control". Much like how many people don't manage the secret keys of their crypto wallets.
For remote QCSD the relevant spec is ETSI EN 419 241‐2 PP. It has very few requirements (8.1.8) about authentication, only that it should be resistant to guessing your PIN/password, and it should only let in the legitimate user.
Note that you can get certified as a qualified trust provider by EY or KPMG.
Service providers must undergo audits to ensure that the security measures they take meet the eIDAS requirements. This includes strong protective measures against unauthorized access to private keys. The keys are usually unrecoverable when the end user has lost their credentials. It’s actually quite involved and costly to become such an accredited provider.
You completely miss the point. The crypto key held by the EIDAS provider is not the weak link. They are very securely attesting ONLY that the signatory controlled a given email address at the time of the signature. If I can get control of your email address then I can sign anything in your name with EIDAS. It's worthless, as the signatory can just claim that their email was hacked. You might as well just rely on emails, as we do in the UK.
Disclaimer: I'm not familiar with this service or EIDAS, so my comment might be entirely off the mark.
The decision to require users to use an emailed link to view and sign a message could stem from DLP requirements. Emails are plain-text and therefore any sensitive data leaked could be irreversibly exposed. By keeping the messages inside a system that requires authentication, there is less likelihood that a someone besides the intended recipient will interact with the message. Such systems also support auditability and DLP scanning.
Same thing with the notarization system. Is the notary system foolproof? Absolutely not! Imagine how much better notarizations could be with a bit of technology around it. A digital notary could take a photo of your document, register a hash/summary/thumbnail in realtime, and make it so that backdating or changing the document after the fact is a technical impossibility.
What do we use instead? A guy who's probably employed by the signatory promises that he stamped the document on a certain date.
But here's the thing: the current system works well enough. Sure, as crypto enthusiasts and programmers, we take offense at the current system and immediately start dreaming up notary camera devices with tamper-resistant hardware and image hashes on blockchains and whatnot, but why go and build a fancy, hard-to-fool system unless somebody actually needs it?
"The current system works well enough" is a poor justification to avoid technological progress. I imagine people said the same thing about automobiles during the era of horses & buggies... yet here we are.
A much better argument is the indelible nature of physical signatures. But even that factor has pluses & minuses in an increasingly-digital world. If anything, we need digital signatures - e.g. to watermark original images, videos, articles, etc in an era of deepfakes.
On the contrary, "Progress" is a poor justification for complexity. To justify change, especially change that adds complexity and cost, there needs to be a problem that needs solving or an opportunity to make things better, where better means "cheaper" or "easier" or "simpler" or "fails less." Progress that doesn't make things better for somebody isn't progress, it's Juicero.
If there isn't any notarization fraud out there causing expensive problems, then spending a bunch of effort to make notarizations better isn't solving any problems but is adding complexity and cost.
Managing electronic signatures (e.g. DocuSign & file storage) is a 10x improvement for me compared to printing, signing, mailing or faxing, and file cabinets. The complexity & reduced costs are definitely worth it. YMMV.
DocuSign is a very weak signing system: signatures it produces are forgeable by anyone getting even a temporary access to an email (eg sitting on an unlocked computer or grabbing an unlocked phone), and the graphical part is something anyone can't replicate twice, unless you use one of their fonts making it even more easily forgeable. I don't even remember seeing an option to say that a particular email should always use a specific form (eg drawing of a signature).
Basically, compared to hand-written signatures, they are strictly less secure and a demonstration of how technology makes forgery easier.
Would you like it if your bank accepted transfer orders through DocuSign?
There are strong electronic signatures which are as safe as a signature can be: iow, a question of who generated the key (an issue with keys provided by official cert authorities) and how is it kept safe at rest (basically, how much care a user takes of them).
DocuSign is, in general, neither of these. I am sure there are less convenient options with DocuSign than the email based one, but I've only ever been asked to "sign" by attempting to draw my signature using a mouse or their own font.
I'd rather have someone attempt to forge my handwriting which experts can usually detect, and which requires a bit more sophistication: my concern is not about them being validated, but that instead if I claim how that's not my signature, I can easily provide a bunch of past signatures to an expert to prove my point.
There are free software and free hardware tokens which can generate secure certificates to use for encryption or signing. I would probably trust those best.
I have been asked to e-sign pretty much every building/home leasing document involving myself in the past few years in the US. I am sure that this is also the case for thousands, if not millions, of other Americans.
Sure, but do you have any indication cryptography is involved in this process? In my (limited) experience as a consumer, they just take some existing PDF and add marks on top of it.
Here in Norway, I've had to use my banks 2-factor BankID[1] to sign my loan, house purchase contract etc. According to their documentation[2] it absolutely relies on cryptography, including SEID-SDO[3]
Usually the distinction made is between electronic signature (e.g. you scrawled your mark on a piece of paper, scanned it and now the software lets you paste that image on signature pages) and digital signature (cryptographic)
The ESIGN Act makes no distinction in the US between whether you cryptographically sign or digitally draw, etc., defining a signature as "an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record."
- "electronic signatures", which can be any electronic data used to sign, like a drawn signature
- "advanced electronic signature" (AdES), usually a type of digital signature (XML-DSig, PDF signature, etc.)
- "qualified electronic signature (QES), which is a digital signature created by a certified signature device
QES is legally equivalent to a "wet signature", but in my experience rarely used because of cost. AdES is much more common for high-trust scenarios like loan applications. For low-trust like package delivery, a signature (or smiley) drawn on a touch device will usually do.
AdES is mostly an technical standard that specifies how to use existing PKCS and IETF standards to produce eIDAS conforming signature, timestamp or “seal” (ie. timestamped signature) and how that should be mapped onto CMS (CAdES), XML-Signature (XAdES) and PDF (PAdES). How legally binding the result of that process is then depends on things like QSCTs, their LoA used in that and such things. And then there are various carveouts, for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
> for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
AFAIK that is not true. In CZ national law, there is also recognized electronic signature (RES, "uznávaný elektronický podpis"), which may be either QES (per eIDAS, "kvalifikovaný elektronický podpis"), or just AdES based on certificate from qualified CAs (per national law, "zaručený elektronický podpis, založený na kvalifikovaném certifikátu").
If you use QSCD to generate CSR and get it signed by right CA, you get QES, but if you use just 'openssl req' to generate CSR and get it signed by right CA, you get RES that is not QES.
The point is that the CA has no way to determine that the CSR was generated by Qualified Device and will just sign it. My view of all the talk about Qualified Devices in eIDAS exists mostly to force QCAs to use normal enrollment process with CSRs instead of their random home-grown processes that result in PKCS#12 file containing private key generated who knows where and who knows how.
Yes, and in fact contract and invoices are bad examples because they involve exchange of something from both sides so denying them is very often a futile task. Better examples would be things like wills and deeds but because they are good examples they have careful witnessing and verification requirements :)
> Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off.
More and more people in the legal world want to move away from scanned signatures, faxes and other "legacy" elements. Managing paper (and keeping it safe for the time you legally have to store it) is a massive expense for companies. Fires or thefts at vaults are rare but they do happen (not to mention natural disasters like floods), and you don't want to be affected by a breach that ruins stuff as, say, real estate deeds simply because of the headache that entails to get them replaced.
In contrast to that, a digital deed can be replaced very fast, no matter if the company or the government loses their data center to a disaster.
> It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic signature solutions don't necessarily solve it.
Oh there absolutely is. Particularly in America, where all you need to create a bank account and a line of credit is the name of a person, their SSN and some other details that have long since been leaked to some dark web forum and a forged signature.
With a requirement for a digital signature, a criminal would additionally have to phish their target's digital signature as well - either by convincing the target to make the digital signature or by stealing it via a RAT. Yes, that's possible, but the human element adds a significant cost increase as the criminal now needs a callcenter somewhere in India, Turkey or other places known for being a scammer heaven.
> It's pretty uncommon for there to be a dispute about the fact of signature
Well, I disagree. It looks quite common to me.
You just won't see it on contract disputes, because that kind of argument is a criminal matter. But false contracts, authorizations, transactions and whatever are really common.
And for thousands of years humans got on with no written contracts at all. That doesn’t change the fact that as society evolves there are good reasons for agreements to evolve with it. I’m sure the first hundred years or so of written contracts there were people rolling their eyes at the idea and others “doing it wrong”. It’s possible (likely?) we’ll reach a point where strong properly implemented digital signatures are considered table stakes. This stuff is hard but probably worth it ultimately.
> This stuff is hard but probably worth it ultimately.
I think you're understating "hard."
What about the large proportion of contracts that are still signed in paper? (All of those waivers you fill out at the doctor's office? Paper. Buy a car? Paper. Mortgage? Paper. Hire a contractor for your house? Paper.) Is your scheme going to render those invalid? Are we outlawing paper agreements?
Consider also:
* Many people do not have a computer or smartphone.
* Any scheme (particularly one that does not involve pretty hardcore identify verification) is going to suffer from most of the same limitations as a regular e-signature, in that either side can claim that it wasn't actually them who clicked the button.
* Technology changes rapidly and the entities that are most involved in contracts change very slowly.
* Corporations have a huge incentive to push back on anything that adds friction to customers signing contracts.
Do you think we'll really push through all of that, just to fight the extremely uncommon circumstance where a party denies that they signed a contract? Especially where cryptographic signatures wouldn't even fully solve the problem? I think it's unlikely.
The Gazette (the publication of legal record in the UK) does sign things cryptographically: Eg, for example: https://www.thegazette.co.uk/notice/4301705 (see the signatures at the bottom right). Not sure what actual legal function this serves though.
It's been said repeatedly that high-level business deals (think: Manhattan real estate) are done with handshakes, because if you're not worth your word, you're done in the business.
You might fight over the terms, but once you say "ok" you're not going to fight over "that wasn't me who signed it".
Does this affect the security of password-protected Office documents as well? I think there's lots of valuable information locked up with simple Excel or Word passwords.
I expect not, Office last century previously had a very simple password scheme (broken essentially instantly with modern tools) and then a poor one (take a couple seconds to break typical passwords) before I think settling on a more modern design where brute force isn't practical for a decent password.
It's possible they threw that away to use this approach but seems unlikely
They are still using AES256 with 16 bytes of salt as far as I know.
It's good security but it's not like you can rate limit attempts or anything and password bruteforcing has gotten pretty good lately. You also have to wonder if there isn't a skeleton key of some kind hanging around, too.
Aren't 256 bit AES keys computationally infeasible to crack? Assuming the rng and implementation aren't broken somehow, the best known attack is 2^254.3 operations to brute force a 256 bit key.
You’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.
It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over.
It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get over it, we just can't make that work, a fancy stretching algorithm won't make terrible passwords good. "Correct Horse Battery Staple" type passwords maybe are improved with stretching, you can imagine 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up. But in most cases humans don't need to memorize these passwords at all, so we can use a 32 hex digit password for example which is more than enough even though it's not 256 bits.
> 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up
My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s considered outrageously insecure in the infosec world - anyone with a few thousand dollars to spare on cloud computing can crack.
> a fancy stretching algorithm won't make terrible passwords good
A properly tuned password-hashing algorithm like Argon2 should take about 1 second per hash, and can be configured to eat as many cores and memory as you expect the attacker to have/you feel like dedicating to hashing. Let’s assume you dedicate 2 cores to each hash (a relatively conservative value) - that same 54 bits of entropy now takes an average of 71 million years to crack[^2]. You’d literally be better off trying to brute-force the full AES-256 key space, after the key derivation step (which is the whole point of Argon2 and similar algorithms).
Dangerous advice like you’ve just spouted is against every single password hashing guideline out there - please trust the cryptographic community, they do in fact know what they’re doing when designing algorithms (or at least they know better than you).
[^1]: 2642 MBps per core (https://calomel.org/aesni_ssl_performance.html) = 165 million 128-bit blocks per second per core = 1.32 billion 128-bit blocks per second -> 6.82 million seconds to try 2^53 combinations (50% chance of success) = roughly 2.6 months
[^2]: 1 hash per second per 2 cores = 4 hashes per second -> 2.25e15 seconds to try 2^53 combinations = 71 million years
You're describing a (weak, but whatever) rationale for the stretching algorithms used to protect a client-server system such as on the web. On the way there you get a bit confused about how exponential numbers work and convince yourself that you can brute force a 256-bit AES key in less than 71 million years. Look at bit closer at your arithmetic there.
But, Office isn't a client-server setup, it's desktop software. So the encrypted file, and the software, live on somebody's five year old work laptop. They are not running a tuned brute force kernel, they are general purpose software, and so unsurprisingly they'll take much longer than your estimate from a brute force kernel on chosen hardware.
Now you've made Kirsty the assistant secretary moan that opening the encrypted Excel sheet takes "forever". Guess what they do about that? Did you guess they adjust the tuning slightly to ease it off? Nah, that's a Microsoft internals parameter, Kirsty's team just stop using encryption altogether, game over.
The "guideline" you're talking about is reasonable for web sites and similar systems as a poor alternative or adjunct to e.g. WebAuthn, but it doesn't make much sense for systems like Office.
This smells a lot like the XML Signature Wrapping Attacks known to affect SAML. In essence, the attack fools the signature check into thinking that it's checking the signature of a different document than the one it's given.
They tested XSW attacks against OOXML and couldn't find any, but yes, this line of attacks and XSW both sort of follow from the malleability/flexibility of XML. It's generally not secure to build signature systems "inside" of XML.
"Signed documents" are a joke and everybody knows it. As the XKCD goes:
How to use PGP to verify that an email is authentic:
Look for this text at the top
-----BEGIN PGP SIGNED MESSAGE-----
If it's there, the email is probably fine
The abstract only mentions it offhandedly, but I think the least emphasized bug in their paper is actually the most important, because it really drives this point home:
"We discovered that on macOS, it is sufficient to include a sig1.xml without any content to force the application to show a security banner stating that the document is protected by a signature"
There are plenty of use cases. Like having your code signed, but putting a license key or access tokens or endpoint URLs into the unsigned part. That way you can sign binaries with your heavily guarded key, but still have some web server give people individualized binaries that don't have to ask for information (better UX if you install it once, or a big deal for software meant to be rolled out across many machines).
Of course software can abuse it by loading code from the unsigned portion, but that requires code in the signed portion to be complicit. In that case the signature still does its job of telling you exactly who was responsible for that fuck-up.
We do this where I work, and we HEAVILY verify all information that comes in from the unsigned/unauthenticated parts of the code. Not only types checks, but regex checks, and other validations. And if there's something there that shouldn't be there our program will kill itself. We don't even show any error prompts or anything just incase.
Signed OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the "Package Info" section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from "document.xml".
Here are the attacks, as I understand them:
1. OOXML doesn't sign content-types.xml. It also doesn't sign the literal contents of document.rels.xml, but rather appears to parse it and sign the values from the file. So: you can add arbitrary files to a signed OOXML bundle. That shouldn't matter, because none of those new files will be referenced by "document.xml", which is signed. But: there are files that Word will render without references, like "people.xml" (which describes the authors of a document); you can add that file after signing, and its content can take over the whole document render.
2. Document styles are stored in "styles.xml". You can create an OOXML file without a "styles.xml", sign it, and then later add an unsigned "styles.xml"; since the binding between "document.xml" and "styles.xml" is implicit and not cryptographically verified, if you're clever about the original document you have signed, you can use styles to change the meaning of the document later.
3. There's a tricky attack involving the interaction between .DOC and .DOCX that I don't totally follow, but the gist is: you can get a benign .DOC signed, and then write a malicious .DOCX file, and scrape the signature from the .DOC into the .DOCX file, along with the contents of the .DOC. Signature verification will follow the contents of the .DOC, but the render will be of the .DOCX.
4. There's apparently a nasty implementation bug where the verifier doesn't check to make sure that the hashes in the signature manifest are related to the signature itself, but rather just that the hashes are valid. So you can take an XML signature from any other source (a SAML token, for instance) and splice it into a self-signed OOXML file, replacing the signature but not the hash manifest. Both will verify independently.
5. You can take any signed OOXML Excel spreadsheet and inject a malicious .DOCX into it. Then rename the file from ".xlsx" to ".docx". Word will open it, prompt you to "repair" the file, and then render it as if it was signed.
The core issues here seem to be:
1. Never sign XML.
2. Never sign a file/bundle format that gives you as much flexibility as OOXML does: being able to add and remove files after a signature was applied without invalidating that signature is the root of most of the attacks in the paper.
3. When you're trying to do signatures over something as complicated as Microsoft Word documents, it's not enough to have a coherent model for signing the structure of the file format --- which, it looks like, was the brief for the designers of OOXML signatures; your model needs to take into account the behavior of the whole program ("people.xml", styles and "styles.xml", "document repair"). You can imagine a team at Microsoft that understands how signatures work getting the assignment to design this feature, and coming up with it based only on the documentation for the file format, because Word itself is a beast, and who wants to spend a year figuring out how it works?
4. You have to test these things. Attack #4 is a table stakes vulnerability that could have been a unit test for how simple it is.
There's also Attack #6, which doesn't get front-line billing in the paper but I think does a great job exemplifying how much of a security theater this whole product space of "signed documents" is:
"We discovered that on macOS, it is sufficient to include a `sig1.xml` [file] without any content to force the application to show a security banner stating that the document is protected by a signature"
I did digital signature work for an ARINC spec, which sounds a bit like OOXML, and I have a slightly different take, although to be clear I spent about six months getting a prototype to function, and three more years making it performant and bullet proof.
A couple years ago I wanted to link the spec to my resume and found it was not freely available. Now I’d like to see a copy to verify whether in retrospect I missed anything.
Among the decisions I made:
- provide no metadata until the signature has verified.
- implement your own file extraction logic, use the same logic for locating elements and assets
- don’t touch the file system until the signature has verified
- implement metadata functions using the same code used for locating elements
- use prefetch for xml namespaces, disable network requests
- implement a wrapper around getElementByID, throw an error if multiple elements are ever found (including searching from the root element).
- only extract files and elements that were signed
- canonicalize paths
- implement multiple warnings for impending cert expiration
- be very, very careful if you allow multiple signatures
- watch out for one team demanding requirements that prevent their counterparts from operating
- get used to saying, “no”, but offering workarounds
"XML" is ambiguous. You have to understand what exactly you're signing, which the average notary or whatever doesn't know. And you have to know what you're verifying, which is equally difficult.
Office documents are (extremely complicated) XML; so it's hardly surprising that they adopted a signature scheme that involves signing XML. But this sounds cowboyish; along the lines of "No reputable security expert was harmed in the creation of this signature scheme".
I wasn't saying you were ambiguous; I meant that "XML" can mean the system of nodes that is an XML document; a string that is a representation of that document; and the specific string that was parsed to create the document.
An infinite number of strings can describe the same document, because there is the concept of ignorable whitespace when parsing XML. So "XML" is ambigous because the acronym could mean any of several things; and ambiguous the other way, because XML allows multiple string representations of the same object.
[Edit] So I don't know how you can sign an "XML document"; the only thing I know how to make a signature for is a specific serialization of that document. May be someone's invented a way of signing the abstract document object, but I haven't heard of it.
This is pretty convenient for writing utilities to parse MS Office documents correctly on platforms such as Windows Server Core or Linux, where the actual Office applications are not installed.
Care must be taken because the format isn't "just" XML in a Zip container. Large documents can be fragmented and interleaved..
What's sad is that the format is 90% of the way there to a really good generic document container format. It solves many common problems, such as streaming decode and incremental saving. It also "solves" signing, but as we can all see, 90% secure is 100% insecure.
A modern version would be akin to the Docker container format: JSON metadata inside a gzip file referencing binary blobs with relative paths and SHA signatures.
is there a rationale for doing the signatures like they do? do they need to support multiple parts of the document signed by different people? I think a model where you just sign a blob of data seems much more straight forward and doesn't have any of these problems. the blob signing model does have some problems. for example lets say in the blob signing model for OOXML you would just sign a zip file that has all the xml files. the problem is the person doing the signature could try and craft the zip or the files in such a way that the document renders differently for different people. this is a problem but it is not as bad as the problem where someone who is not the author can create a new document based on an existing signed document because the signature scheme is very difficult to implement correctly.
The PDF ("sec23summer...") has metadata creation/modification timestamp of 20221004165319Z (October 2022). So presumably the paper was written last October and released for Usenix 2023.
(Reference [12] is from Usenix July 2022. See "Prior work" in the introduction).
October 4th 2022, according to the PDF date (and according to the "We have not received any feedback from OnlyOffice as of October 4th, 2022" in the PDF).
Per the call for papers [https://www.usenix.org/conference/usenixsecurity23/call-for-...], that means the paper would have been submitted for review by June 7, 2022, accepted for publication as of September 2, 2022, and had the final ("camera-ready") version uploaded by October 4, 2022.
The conference itself won't take place until August of this year.
I remember reading most of those back at the time they were written.
The main one I recall for claims of not being open was that the drafts at the time had markup for marking things such as "use Word 6 line spacing" and "use WordPerfect 7 paragraph wrapping" or similar. The claim was that since those formats and behaviors were not openly documented having elements for them made OOXML not open.
That was a questionable claim for a couple reasons.
First, that markup was not there for use in newly made documents, and new word processors (including those from Microsoft) were not expected to implement it--they were expected to ignore it.
What it was there for as archiving.
For example at the time WordPerfect was pretty much the de facto standard for legal documents. Many legal publishers and large law forms stored all their documents as WordPerfect files, and had tools to manipulate those documents outside of WordPerfect. Those tools were based on reverse engineering of the WordPerfect formats.
These places had large archives of WordPerfect documents. Suppose they wanted to move to a more current, better documented archive format such as ODF or OOXML. It would be possible to write a converter that would turn a WordPerfect document into an ODF or OOXML document and change their internal document tools to understand ODF and OOXML, but since Star Office's and Microsoft Office's formatting options were not a superset of WordPerfect's that conversion would be lossy.
The straightforward way to deal with that is to find some way to add some extra data when you do that conversion to record what WordPerfect formatting options that you could not map to ODF/OOXML were in effect at a given point in the document. Make your tools understand the extra data your converter adds and then your tools can reproduce accurate copies of the originals when needed.
There were multiple parties that would be doing that. It would be silly for them to each come up with their own way to add that extra data. Some might make it custom tags. Some might make custom attributes. Some might do it with comments. Or CDATA. It would be much nicer if all the people who were extended ODF or OOXML to archive WordPerfect documents used the same way to add that extra information. That would make it easier if they ever wanted to exchange archived WordPerfect documents.
And that's what things like use "WordPerfect 7 paragraph wrapping" were: Microsoft saying "You all who have reverse engineered WordPerfect and want to mark in your document archives that some document uses some WordPerfect specific formatting, mark it this way". They did this for a bunch of older word processor and spreadsheet formats.
Second, I believe they took this out of a later draft.
It usually comes down to creating some complex formats where signatures are allowed to sign sub-parts of the information. This is an extremely fragile design, and should probably be considered broken unless proven otherwise.
Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous.