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.
- the asset has a name and a version
- the named, versioned asset contains a Unix Timestamp giving the time it was first published
- 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:
- a 256-character key.
That 256-character key is then used to derive from the asset itself:
- a 16-character slug
That 16-character slug is then inserted into the named, versioned filename and becomes a canonical part of that filename:
Wherever Remote Script 2.4 is hosted on the web, it will always have the filename:
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.