How to verify that a legitimate (but unknown) remote asset from an unknown source has not been compromised and that its integrity remains intact?

Question

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:

4. a 256-character key.

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

5. 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.

Answer 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.

Answer 2

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.