Re: Chartering work has started for a Linked Data Signature Working Group @W3C

> Here are several attacks that I believe can be carried out against the 
> algorithms in https://w3c-ccg.github.io/ld-proofs/#algorithms.

None of the attacks work, details below.

> Attack 1 is probably difficult to do and doesn't get much, but it does get
>  consumers to believe that a producer signed something the producer didn't.
>  The producer creates a file  containing relative IRIs that serializes G if
> the base IRI is the retrieval IRI in the context where the consumer's
> verification algorithm will be run. The producer then signs this file, with
> the base IRI this retrieval IRI.  The consumer's verification function will
> succeed on the signed file.  But when the consumer actually deserializes
> the signed file the retrieval IRI may be different from the retrieval IRI
> that was used in the verification algorithm.

Invalid. You have created a vulnerability by not following standard
cryptographic best practices.

This attack presumes that the victim will verify signed data, throw that
verified data away, and then use unsigned data instead.

This is a well-known general attack on any sort of cryptographic system and is
why you shouldn't do this.

You should only work with data that has been verified. In your specific case
above, you should use the expanded IRIs that are returned by the signature
verification algorithm... not ones you construct yourself.

> Attack 2 is less difficult but requires something like the JSON-LD @context
>  mechanism.   A producer signs a document that has a remote context that is
>  under the control of a third party.  The consumer verifies the signed 
> document, which is successful because the first time the consumer asks for
> the remote context the same information is sent, and sent as expiring 
> immediately.  The third party then sends different remote context the next
>  time the consumer asks for it so that when the consumer deserializes the 
> signed document the consumer sees an RDF dataset that is not what the
> producer signed.

Invalid. If the RDF Dataset is not what the producer signed, the signature
fails verification.

> Attack 3 depends on the presence of multiple proof nodes.  Suppose the 
> original graph already contains a proof node.  The producer signs this
> graph. The consumer, as part of the verification process removes all proof
> nodes and tries to verify the signed document minus the proof nodes.  The
> verification of the signature fails because the proof node in the original
> graph is not present.

Invalid. You're not distinguishing between set-based and chain-based signatures.

If you're doing this as a set-based signature, all proof nodes are removed
before signing (and verification)

If you're doing this as a chain-based signature, then all proof nodes will be
preserved in order if the algorithm is implemented correct.

> Attack 4 also depends on the presence of multiple proof nodes and exploits
> a flaw in how the verify hash algorithm is specified. Suppose an opponent 
> creates a fake signing of an original graph. The opponent then signs the 
> "signed" graph.  The consumer then takes the proof nodes out of the graph
> that the opponent has signed.  The create verify hash algorithm is given
> two proof nodes but only expects one and only verifies the opponent's
> signature.  The consumer then deserializes the graph it received and
> believes that the fake signature has been verified.

Invalid. You're presuming that signature verification happens in a vacuum and
all signers are interchangeable and valid.

In the real world, this is never the case. You are typically expecting a
number of signatures from a number of parties. If you don't get the signatures
from the parties you're expecting, you fail to verify.

> Attack 5 is similar to attack 4 except that the false information is added
>  afterwards.  Suppose a producer signs a linked data document. Then an
> opponent adds an extra signature, either fake or real.  The consumer then
> takes the proof nodes out of the graph that the opponent has modified.  The
> create verify hash algorithm is given two proof nodes but only expects one
> and only verifies the producer's signature.  The consumer then deserializes
> the graph it received and believes that the signature the opponent inserted
> has been verified.

Invalid. Why does the verify hash algorithm "only expects one" signature?
Again, you're presuming that signature verification happens in a vacuum and
all signers are interchangeable and valid. This is almost never the case...
you expect certain signatures to come from certain issuers, and if you don't
get the signatures you're expecting, you fail closed.

None of the attacks above are valid attacks, for the reasons specified above.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Thursday, 3 June 2021 21:02:39 UTC