How hard to hack are S3 Last-Modified timestamps?

Question

Context: There are many reasons for wanting a very trustworthy timestamp on a document, as discussed in many other questions here such as this one I wrote in 2010. E.g., in an election auditing context, one thing we're interested in is a cheap, quick, secure way to publish hashes of ballot images (or batches of them) in a way that commits to their existence at a particular point in time. Such timestamped hashes can be used in later audits to help secure the chain-of-custody of the paper ballots.

One recent recommendation I heard was to simply publish the hashes in S3 buckets, claiming that objects are immutable and provide a creation date (called "Last-Modified" unfortunately), as discussed at S3 LastLodified timestamp for eventually-consistent overwrite PUTs - Stack Overflow

That seems like a plausible approach. But in reality, how hard to hack are S3 Last-Modified timestamps? Often things like this depend on the implementation and benefit from an informed threat analysis. I'd assert, e.g. that an Amazon insider with lots of access could change a timestamp somehow. If nothing else, they could change the implementation, though it could get very messy. Hacking the API servers might be another approach.

Can anyone shed light on whether there are attacks that can be mounted by outsiders that would change a timestamp? Given the value of hacking an election, or covering a hack up by hacking the audit also, I'll stipulate that I'm interested in everything from script kiddies to advanced persistent threats by nation-state actors.

I'd also be interested in insights on how hard insider attacks might be.

For bonus points, compare the hackability of this S3 approach to my current favorite low-overhead,seemingly hard-to-hack approach these days: Stellar timestamps via STELLARAPI.IO

Answer 1

The structure of AWS S3 makes it impossible to overwrite an object and maintain the same timestamp. There is no interface to modify the timestamp. If a file is overwritten, the timestamp changes. I am not sure if they use RFC 3161 to ensure that timestamps cannot be modified without detection.

See https://en.wikipedia.org/wiki/Trusted_timestamping

Probably the better idea is to use S3 Object Lock, which stores objects using a write-once-read-many (WORM) model.

See the Cohasset Associates Assessment of the security compliance of S3:

It is Cohasset’s opinion that Amazon S3, when properly configured and when Object Lock mode is set to Compliance, retains records in nonrewriteable and non-erasable format and meets the relevant storage requirements set forth in the above Rules. Each record is protected from being modified, overwritten or deleted until the applied retention period is expired and any associated legal hold is released.

Thus, it is probably best if the election data is protected with WORM type operation. But from my experience, it is not at all easy to do anything with AWS that is not already part of their interface. The only thing that really needs to be stored in WORM mode are the hash values of ballot image data, so others can check it. The nice thing about S3 is that the hash values (etags) for any file are easy to read in the HEAD metadata. I only wish other file systems had similar hash value tracking of files, without needing to calculate it. When files are uploaded to S3, best practice is to provide the ContentMD5 value so it can be checked when it is uploaded. It won't allow uploading if the calculated hash value does not match. This is different from the s3 etag which is the MD5 of a list of MD5 values of blocks of data.