0

I am familiar with and see the benefits of Subresource Integrity (SRI).

I understand that with SRI, once you've added a script reference with the correct integrity attribute, if the remote script is subsequently compromised, then the SRI Hash will not match the remote asset and the remote script will not download.

That's an effective safeguard as long as the remote script was uncompromised at the point when you first referenced it.

But what if, at that point, the remote script was already compromised (and a new SRIHash generated to match the compromised asset)?

The asset must be able to self-verify. My principle concern here is self-verification.

That is, an asset needs to be able to authenticate itself in the absence of third-party verification.

(An SRIHash will verify that the asset is a data-match, but that doesn't help if a bad actor is able to alter both the asset and the SRI Hash.)

At the very least, we need more than just an SRIHash.

To verify the integrity of a new unknown remote asset from a new unknown source, when we cannot say for certain if either the remote asset or the remote source has not been compromised, we need something that cannot be plausibly altered without giving the game away.

Can this be achieved (?) by adding to the asset and the SRIHash the combination of:

  • a timestamp
  • a geostamp

N.B. I'm specifically talking about a legitimate asset which has been compromised, not a bad asset which was bad from the outset. I recognise there's nothing that can be done about the latter.

This is what I've come up with so far in terms of an unknown remote asset self-verifying its integrity:

The remote asset has a conventional SRI Hash.

  1. the asset has a name and a version
  2. the named, versioned asset contains a Unix Timestamp giving the time it was first published
  3. the named, versioned asset contains Lat and Long Geo-coordinates giving the location it was first published

The three pieces of data above are used to derive from the SRI Hash:

  1. a 256-character key.

That 256-character key is then used to derive from the asset itself:

  1. a 16-character slug

That 16-character slug is then inserted into the named, versioned filename and becomes a canonical part of that filename:

https://example.com/remote-folder/remote-script--2-4--39dsoe26shw82czm.js

Wherever Remote Script 2.4 is hosted on the web, it will always have the filename:

remote-script--2-4--39dsoe26shw82czm.js

Nearly all pieces of information (the SRIHash, the timestamp, the geo-coordinates, the 16-character slug) are referenced in the data itself so that everything can either:

i) be checked as identical by the computer (eg. Is the SRIHash in the attribute the same as the one listed in the asset? Does the filename duplicate the same 16-character sequence from the asset? Is the Asset Name the same as listed? Is the Asset Version the same as listed?); or else

ii) the technician referencing the remote script can be asked if they trust the asset's signature (eg, This data reports that it was published [in the middle of the Pacific] in 1981? Do you wish to continue?)

It occurs to me that a determined exploiter who wants to generate a 256-character key for their own compromised version, where the key is consistent with a plausible publishing time and location will need to manipulate the asset itself by inserting comments. Consequently a semi-automated check would also be required to verify that the asset doesn't contain any unusual comments.

Is this level of self-verification of integrity (using a timestamp and a geostamp) enough? Or is this too easily circumvented?

This is mostly as far as I've got on my own, but I'm happy to answer any further questions to clarify any detail I may have inadvertently left out.

32
  • Currently reading about Phil Zimmermann's concept of a Web of Trust but I don't think it's intended for precisely this kind of scenario. Feb 3 at 15:53
  • 2
    For a cryptographically-assured untampered history, perhaps this question would have been better submitted to crypto.stackexchange.com instead. Feb 3 at 17:05
  • 4
    @Rounin Let me make the point this way: remote-script--2-4--39fakymcfakehash.js I say that's the canonical file name. If you've never seen it before then how do you know that I'm full of it? Feb 3 at 19:20
  • 1
    We do all that already with separate file hashes. What are you buying us with this? Because you're costing us the ability to go back and hash files created and named before adoption of this scheme. Feb 3 at 19:29
  • 2
    I may be missing something but what does the geolocation identifier accomplish? I don't see anything here that prevents an attacker from using whatever geolocation they like such as the one that was used in the original hash. It's not like someone trying to subvert this scheme is going to tell you their actual location while they are perpetrating a crime unless they are really very stupid. Same goes for the timestamp too.
    – JimmyJames
    Feb 3 at 20:34

2 Answers 2

1

I'm trying to understand how it will be possible (I refuse to believe it isn't possible) to verify the integrity of a new unknown remote asset from a new unknown source, when you cannot say for certain if either the remote asset or the remote source has not been compromised.

Sure you can do this. It's called the Wayback Machine.

But all that will tell you is if the hash has been changed. There is no way to know if it was changed because the site hosting the hash got hacked to hide that the asset is compromised or if the legitimate asset author decided to sneak in a change without changing the version number.

And of course the Wayback Machine can get hacked, the legitimate asset author can turn to the dark side, and cosmic rays can flip your bits. Honestly, when this stuff works the way it's supposed to, consider yourself lucky.

1
0

So my understanding of SRI

  • you write a script
  • you generate the hash
  • you upload it to third party CDN
  • you reference the CDN version in your webpage, hosted by you
  • someone loads your webpage
  • the browser requests the script
  • the browser checks that the script it got from the CDN has the same hash as the link in your webpage.

Here the browser is checking that the script the CDN serves is the same as the one your webpage wants.

The scenario you seem to be asking about is different if I understand it correctly.

  • you write a website and want to use someone else's script which is hosted on a CDN
  • you link to the script and add the hash that the CDN supplies.
  • ...

Here the browser is doing the same thing. But you haven't checked that the script you referenced is actually the one you want.

You need to add a step at the beginning, where you download the script and check the source code does what you think it does, look for security problems and backdoors etc.

All of your ideas fall down when you only have the one source for all the data. Who is telling you what the file name and version should be, when it was published etc why is the middle of the pacific 1981 a red flag compared to anywhere/when else? why 2.4 and not 3.1?

You must have external information, that you trust, about the code that you expect, to compare against your untrusted source.

8
  • well they have to just trust whoever told them that link was good then
    – Ewan
    Feb 3 at 15:34
  • you could for example, meet the author in person and get them to give you the hash in the form of a paper note, which you then carry back to your desk being extra careful to avoid any "now you see me" style hijinks
    – Ewan
    Feb 3 at 15:37
  • 3
    do you see that what you are asking is the same as "i have been given a box, how do i know whats inside without looking?"
    – Ewan
    Feb 3 at 15:39
  • 1
    or really more like, "ive looked at the thing, but I dont know what i ordered. it is what i ordered?"
    – Ewan
    Feb 3 at 15:40
  • sure, I guess that would be like, i linked the wrong script and i get errors when i call it. it doesnt help if i make fake coins to send you. A bank would check the coin against a real coin and see if they are the same
    – Ewan
    Feb 3 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.