Re: Signing and Verifying RDF Datasets for Dummies (like Me!)

On Wed, Jun 09, 2021 at 01:45:10PM -0400, Peter Patel-Schneider wrote:
> On Wed, 2021-06-09 at 13:10 +0200, Eric Prud'hommeaux wrote:
> > On Tue, Jun 08, 2021 at 08:21:31PM -0400, Peter Patel-Schneider
> > wrote:
> > > On Tue, 2021-06-08 at 23:13 +0200, Eric Prud'hommeaux wrote:
> > > > On Mon, Jun 07, 2021 at 08:31:17PM -0400, Peter F. Patel-
> > > > Schneider
> > > wrote:
> > > > > On Mon, 2021-06-07 at 22:49 +0200, Eric Prud'hommeaux wrote:
> > > > > > On Mon, Jun 07, 2021 at 03:37:44PM -0400, Peter Patel-
> > > > > > Schneider
> > > > > > wrote:
> > > > > 
> > > > > [..]
> > > > [...]
> > > > Do you agree that in order to do so, they'd have to expand the
> > > > document more than once, and carry the conclusion of a valid
> > > signature
> > > > over from the first expansion?
> > > 
> > > For the receiver seeing a different graph than what the sender
> > > signed
> > > this double expansion is needed.  However, double expansion is
> > > required
> > > given the algorithms in https://w3c-ccg.github.io/ld-proofs/
> > 
> > I see only one expansion in signing and one in verification.
> > Together,
> > they total two, but any change to the context that affects the signed
> > triples with result in a failed verification. The only place to
> > inject
> > a well-timed context change would be if either signing or
> > verification
> > demanded multiple expansions.
> 
> But the receiver needs to perform two expansions.  The first happens
> when the receiver runs the verify algorithm.  The second happens when
> the receiver uses the transmitted document to construct the RDF
> dataset.  These two operations can be separated by an arbitrary amount
> of time and can be done in different environnments with the result that
> the recceiver constructs a different dataset from what the verify
> algorithm verified.
> 
> And remote contexts and other environmental concerns can be constructed
> and manipulated so that the verify algorithm sees what the originator
> signed and thus returns true but the receiver constructs something
> different.  This can happen by accident, such as when a remote context
> is updated, or by an opponent, for example by modifying a transmitted
> document to inject a remote context that is modified between
> verification and construction.

Some libraries probably double-expand by default, and you're right,
that's neither efficient nor safe. That deserves some text in the spec
and a test endpoint that tries to exploit it (e.g. it maps
`p`=>`http://a.example/p1` on the first GET,
`p`=>`http://a.example/p2` on the 2nd, etc).

If someone finds it much easier to implement their library with
double-expansion, it can still be safe to double-expand if the
documentLoader overrides cache pragmas for the duration of a
verification. By default, the Digital Bazaar stack works with local
copies anyways so you have to go to some effort to create Manu's
"footgun".


This issue is further evidence that a WG product would increase
security and community understanding around security issues. Most of
the obvious ways ways to sign JSON-LD introduce this sort of
vulnerability. No WG leads to any of:

0. No action: most folks won't consider dereferenced evaluation
   vulnerabilities present in JSON-LD pipelines that don't include
   some verification.

1. standard JWS over JSON-LD doc: this signs the JSON tree but not the
   RDF expansion.

2. Homegrown signature stacks: likely to include atomic operations
   that separate verification from expansion (for e.g. populating a
   store) is subject to your timing attack.

A WG product can raise awareness of these issues for these issues
across all JSON-LD pipelines (or any dereferenced evaluation
pipelines) and provide recipes and tools for securing them.


> [...]
> 
> peter
> 
>

Received on Friday, 11 June 2021 07:33:24 UTC