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.
Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
41–50 of 158 posts
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#42> 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…
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 :)
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#43Earlier quoted context omitted.
Sounds like a useful feature to me.
I mean, aside from bypassing the whole point of having them.
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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#44Earlier quoted context omitted.
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. eIDAS was intentionally formulated to allow such signature services, making the whole thing quite pointless from a security perspective.
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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#45Earlier quoted context omitted.
I mean, aside from bypassing the whole point of having them.
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).…
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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#46Earlier quoted context omitted.
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. eIDAS was intentionally formulated to allow such signature services, making the whole thing quite pointless from a security perspective.
> 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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#47Earlier quoted context omitted.
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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#48> 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…
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. [0] https://en.wikipedia.org/wiki/EIDAS
>Emails don’t provide that legal value.
In Italy there is an officially legislated signed email service that has legal value
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#49I can’t find a date for this paper, there is nothing on the web page or PDF
It's listed as a summer deadline accepted paper for USENIX Security 2023: https://www.usenix.org/conference/usenixsecurity23/summer-ac...
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.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#50Earlier quoted context omitted.
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.