[HN Gopher] Every Signature Is Broken: Insecurity of Microsoft O...
___________________________________________________________________
Every Signature Is Broken: Insecurity of Microsoft Office's Ooxml
Signatures
Author : pseudotrash
Score : 282 points
Date : 2023-06-12 12:34 UTC (10 hours ago)
(HTM) web link (www.usenix.org)
(TXT) w3m dump (www.usenix.org)
| hannob wrote:
| 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.
| robertlagrant wrote:
| I don't see why that's fragile? E.g. JWTs work this way.
| kevincox wrote:
| No they don't. JWTs sign the whole token.
| robertlagrant wrote:
| They sign the header and payload. The third section is the
| signature itself.
| g_p wrote:
| 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.
| kevincox wrote:
| 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.
| robertlagrant wrote:
| This is possible with anything, though. If your
| verification code trusts the input, that's bad. That's
| not a structural weakness of the JWT format.
| growse wrote:
| > This is possible with anything, though. If your
| verification code trusts the input, that's bad. That's
| not a structural weakness of the JWT format.
|
| What's the purpose of the algorithm field in the header
| if clients shouldn't trust it? It's "input", after all...
| maccard wrote:
| There's a difference between trust and blindly trusting.
| kevincox wrote:
| That is effectively "the full token". It is pretty
| difficult to sign the signature.
| robertlagrant wrote:
| It is, but that is the topic at hand:
|
| > Signatures should really just be applied to whole files
| or data structures, everything else should be considered
| dangerous
| tptacek wrote:
| They're also notoriously fragile!
| lambda wrote:
| 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!
| mati365 wrote:
| Isn't the file part of the file system which can be file too?
| Basically everything everywhere is broken.
| GranPC wrote:
| People typically do not share documents, such as signed
| contracts, by providing an image of their entire filesystem
| containing the signed file.
| est31 wrote:
| 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.
| leni536 wrote:
| Isn't docx literally a zip file?
| GranPC wrote:
| 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.
| fatfingerd wrote:
| 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?"
| bee_rider wrote:
| Did they give any justification?
|
| 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.
| fatfingerd wrote:
| 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.
| bee_rider wrote:
| Interesting!
|
| 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.
| cratermoon wrote:
| 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.
| tptacek wrote:
| 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.
| neilv wrote:
| 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? :)
| tptacek wrote:
| 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.
| nightpool wrote:
| 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"
| denton-scratch wrote:
| > Never sign XML
|
| "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".
| tptacek wrote:
| I don't see what's ambiguous here. I'm saying: never sign
| anything XML-encoded. Never use XML signatures.
| denton-scratch wrote:
| Heh!
|
| 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.
| urbandw311er wrote:
| I can't find a date for this paper, there is nothing on the web
| page or PDF
| hovav wrote:
| 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.
| zwp wrote:
| 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).
| gnfargbl wrote:
| One of the authors lists the paper as 2023 on their homepage
| [1], and the naming of a preprint [2] suggests summer 2023.
|
| It's a recent paper.
|
| [1] https://casa.rub.de/en/research/publications/detail/every-
| si...
|
| [2]
| https://www.usenix.org/system/files/sec23summer_235-rohlmann...
| proto_lambda wrote:
| USENIX '23 will take place in August.
| layer8 wrote:
| 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).
| D13Fd wrote:
| > 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.
| layer8 wrote:
| 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
| CrampusDestrus wrote:
| >Emails don't provide that legal value.
|
| In Italy there is an officially legislated signed email
| service that has legal value
| dfox wrote:
| 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.
| necovek wrote:
| Append-only stores of record predate "blockchain" by
| _decades_ : a distributed trust/consensus algorithm is
| the real innovation in Bitcoin.
| ogig wrote:
| 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.
| cedilla wrote:
| I agree, in Europe digital signatures are very common now.
| Although at least for me it's almost exclusively PDFs.
| tpurves wrote:
| 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.
| [deleted]
| ClarityJones wrote:
| 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.
| TheNewsIsHere wrote:
| 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
| D13Fd wrote:
| 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.
| riceart wrote:
| Without cryptographic techniques that is all easily
| forged.
| toast0 wrote:
| 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.
| wongarsu wrote:
| 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.
| jacoblambda wrote:
| > 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).
| c00lio wrote:
| EIDAS isn't worth the paper (pun intended) it is written on,
| if insecure "click a link in an email"-signature schemes such
| as https://help.eversign.com/hc/en-
| us/articles/6664408666013-Is... can claim compliance...
| layer8 wrote:
| 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.
| c00lio wrote:
| 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.
| consp wrote:
| > 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.
| layer8 wrote:
| 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.
| rtb wrote:
| 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.
| 1MachineElf wrote:
| 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.
| necovek wrote:
| 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.
| psychphysic wrote:
| 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.
|
| [0] https://www.lexisnexis.co.uk/blog/banking-and-
| finance/gordon...
| justincormack wrote:
| "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.
| zzbn00 wrote:
| As an interesting edge case, in an auction contract can
| be formed without words either: it is formed on the "fall
| of the hammer"
| https://www.legislation.gov.uk/ukpga/1979/54
| denton-scratch wrote:
| 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!
| necovek wrote:
| 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.
| bombolo wrote:
| In italy we have PEC, which is legally regulated signed
| emails
| bogeholm wrote:
| I've found the per-country overview of general legality of
| digital signatures on DocuSign [0] quite informative.
|
| As an example, in DK an email constitutes a valid contract
| for most purposes.
|
| [0] https://www.docusign.com/products/electronic-
| signature/legal...
| necovek wrote:
| Even if I spoof it? ;)
| londons_explore wrote:
| > Emails don't provide that legal value.
|
| In general, agreeing to something by text in an email is as
| legally enforceable as a signature.
| logifail wrote:
| > In general [..]
|
| ...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 (OBB) 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)
|
| https://www.railjournal.com/news/austrian-court-annuls-
| stadl...
| c00lio wrote:
| 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.
| D13Fd wrote:
| > 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:
|
| https://en.wikipedia.org/wiki/Statute_of_frauds
|
| https://en.wikipedia.org/wiki/Uniform_Commercial_Code
| pid-1 wrote:
| Not American, but DocuSign is becoming quite popular in my
| country and was deemed as a legal way of signing documents by
| courts.
| marcosdumay wrote:
| > 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.
| mschuster91 wrote:
| > 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.
| MangoCoffee wrote:
| when i was young i worked for a e-mortgage software company.
| our flagship software allows customer to sign online or on a
| electronic signing pad.
|
| the whole legality is based on Electronic Records and
| Signatures in Commerce Act signed by Bill Clinton.
| eduction wrote:
| 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.
| D13Fd wrote:
| > 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.
| Avamander wrote:
| In some countries digital signatures are used in vast majority
| of cases, paber being the rare fallback (and nobody scans or
| faxes those).
| zzbn00 wrote:
| 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 :)
| prepend wrote:
| I really like how preview has an image signature feature now
| and it seems to pass whenever people need a doc signed.
|
| The occurrence of fraud is so low, it's better to just have non
| crypto signatures for legal docs and then contest when
| necessary.
| galleywest200 wrote:
| 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.
| loeg wrote:
| 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.
| tialaramex wrote:
| 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)
| phrz wrote:
| 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."
| kjetil wrote:
| In the EU (and EEA), eIDAS distinguishes between
|
| - "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.
| dfox wrote:
| 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)
| magicalhippo wrote:
| 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]
|
| [1]: https://www.bankid.no/bedrift/bankid-signering/
|
| [2]: https://confluence.bankidnorge.no/confluence/pdoidclc/
| techni...
|
| [3]: https://www.nets.eu/developer/E-Signing/overview/Pages
| /Signe...
| loeg wrote:
| That's interesting, thanks, but I am specifically
| interested in the US (like the thread I was responding
| to).
| magicalhippo wrote:
| Sure, I just like to bring an outside perspective when I
| can.
| bombolo wrote:
| Uh? I have a smart card that I can use to digitally sign stuff.
| Fully regulated by law in italy. A scanned signature is not
| valid for us.
| CobrastanJorji wrote:
| 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?
| beambot wrote:
| "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.
| prepend wrote:
| Technology should be weighing the benefit against the cost.
|
| It's not that techno-notaries wouldn't have benefits, it's
| that they wouldn't have much benefit over the current
| system.
|
| Also, digital notaries aren't required to do things like
| signing images or even documents or commits or whatever.
|
| I would just hate if all my documents requiring a notary
| suddenly required enotaries.
| CobrastanJorji wrote:
| 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.
| beambot wrote:
| 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.
| prepend wrote:
| I just sign the pdf with preview and save it off to a
| folder. Works great.
| necovek wrote:
| 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?
| fireflash38 wrote:
| It really comes back to that xkcd - https://xkcd.com/538/ -
| doesn't it?
|
| Systems designed by and used by humans will always have at
| least one fault - the humans involved.
| ERUIONKP wrote:
| [flagged]
| nailer wrote:
| I've heard the same for Windows code signing certs - that's it
| possible to modify the payload and have the signature still
| apply.
| Avamander wrote:
| There's also the padding vulnerability CVE-2013-3900 that still
| isn't mitigated by default.
| ioquatix wrote:
| Sounds like a useful feature to me.
| dijit wrote:
| I mean, aside from bypassing the whole point of having them.
| wongarsu wrote:
| 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.
| tankerkiller wrote:
| 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.
| ipython wrote:
| In the Authenticode spec, there is an unauthenticatedAttrbutes
| structure, the contents of which does not affect the resulting
| signature.
|
| Dropbox's installer used it a while ago (maybe still, haven't
| checked): https://news.ycombinator.com/item?id=8204454
| password4321 wrote:
| https://news.ycombinator.com/item?id=8203164
|
| > _These attributes are not part of the signedAttributes which
| is used to actually authenticate the signature_
|
| https://learn.microsoft.com/en-us/archive/blogs/ieinternals/...
|
| > _unverified data within the PKCS #7 blob itself which will
| not be taken into account when verifying the Authenticode
| signature_
| 666satanhimself wrote:
| [dead]
| munchler wrote:
| 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.
| tialaramex wrote:
| 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
| jabroni_salad wrote:
| 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.
| meepmorp wrote:
| 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.
| mplewis9z wrote:
| 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.
| tialaramex wrote:
| 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.
| mplewis9z wrote:
| > 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
| jabroni_salad wrote:
| That math challenge assumes that the attacker will want
| to try all keys.
|
| In reality, they are going to run rockyou.txt against it
| and just move on if that isn't sufficient.
| nightpool wrote:
| "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"
|
| BEGIN PGP SIGNED MESSAGE indeed.
| benmmurphy wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-12 23:00 UTC)