0

I am writing a software that records and stores data files.

I want to digitally sign and time stamp these files so that I can assure that it's Contemporaneous and Attributable (to comply with 21 CFR part 11 regulations and ALCOA C+ guidelines). This means I want to be able to prove that the file was recorded by a certain user and prove that the file was created/modified at a certain time.

I have some questions regarding the validity of the implementation I have in mind:

Implementation:

Digital signature

  • I was planning to generate a RSA pair of keys.
  • I would create the hash of the file (using a strong hash generator) and encrypt with the public private key.
  • I will call the encrypted hash the "signature" and save it inside the file.
  • At this point I assume that the file is "Attributable" and it can be validated using the author private public key.

Timestamp

  • I will send the "signature" (encrypted hash of the file) to a TSA
  • The TSA sends me a hash which will be my timestamp signed by the TSA.
  • I save this hash inside the file.
  • At this point I assume that the file is "Contemporaneous" and can be validated only by sending this hash to the TSA.

Questions:

  1. Is this implementation conceptually correct?
  2. Does this implementation comply with most standards (assuming that I use good hash and RSA keys generators and TSAs)?
  3. Is it possible to have a trusted offline timestamping (to account for computers that cannot have internet access or temporary lost connection)?
  • 2
    Why do you feel you cannot use a standard solution instead of implementing your own? – Stephane Jan 9 at 12:42
  • 3
    If your data files are composed of bytes written to a storage device, it's a conventional file, and a standard solution will work. You can study the process of signing, not bother with the implementation. – ThoriumBR Jan 9 at 13:02
  • 1
    If you have zero experience, that's a VERY good reason not to implement something yourself. Have a look at GPG and PKCS: and pick the one that fits your environment the best. Then find a reputable library that implement digital signature with secure timestamping (most do) and use that – Stephane Jan 9 at 13:25
  • 1
    It seems you might want to consider using ASC X9.95 (which is an expansion of the RFC 3161 idea for TSAs). Then your timestamp authority is verifying both the data and the time of data commit, basically wrapping all your requirements together (as best as I can tell). Quick wiki primer: en.wikipedia.org/wiki/ANSI_ASC_X9.95_Standard . Otherwise, yes, your general idea is correct. You sign a file which is used to prove that the file has integrity (hasn't been changed since the signer signed it) and you timestamp, with a trusted authority, the signature to prove WHEN that was. – Ruscal Jan 9 at 16:22
  • 1
    @cinico There are multiple schemes at that point. I've seen software use alternate streams so that primary payload is in stream[0] (which is what most software uses) but the sig-stamping is in stream[1] (or n if you already have more sterams). Some (very many, actually) file types have meta-data positions that are for this purpose (most every file time if you include "could be used for, even if not designed"). And then there is the descriptor file approach. Most of my stuff appends sig to main file (the above is signed as, then the above -inc sig- is time stamped at) which TGZ and GPG do. – Ruscal Jan 9 at 22:35
3
+50

So, in general, your thought process is correct.

  1. Create the digital content Document and save it.
  2. To prove that Author last saved Document they would sign the file with their asymetric key
  3. To prove when Document was saved you would cryptographicly time-stamp it with the help of a trusted Time Stamp Authority.

At any point in the future anybody can validate that the file is the same as it was at a point in time (unchanged since step 3) by validating the timestamp hash with the help of the TSA.

At any point in the future anybody can validate that the file is unmodified from when the Author saved it (unchanged since step 2) by validating Document's signature using Author's public key.

At the core, this seems to be what you are thinking about and yes this is how it does work. And yes, an implementation along these lines does comply with every standard that I am aware of (I work in the USA, but not with the FDA) for proving authenticity of documents across a time domain; including digital contracts (it provides proof of identity and proof of time signed). Though if you are attempting to use this for any purpose where compliance is mandatory then you should take the entire matter up with legal council. Let me be clear: I am not a lawyer and nothing I say should be construed as legal advise or a recommendation on a legally acceptable course of action for you and/or your company. If that is what is required, make sure that you and/or your company bring in your/their own lawyers to ensure you are compliant.

OK, now that the CYA is out of the way we need to look at implementation. You have a data payload for which you wish to guarantee authenticity. This isn't uncommon and is something we all deal with regularly ("verify the file hash before installing", "verify the message signature with my public key", etc). It is a known solved problem in our world. For verification of integrity of the payload, a hash of the payload is computed for comparison. For verification of authorship of a payload, the hash is computed and then cryptographicaly encrypted (using the Author's private key) -- a method we refer to as "signing the document". While you verify the integrity by making sure the hashes match, you check the authorship by decrypting the "signature block" using the supposed Author's public key -- this gives you the file integrity hash that you then verify as before.

Again, this is a solved problem with various schemes in existence to perform it. One of the most common is Pretty Good Privacy (PGP). The PGP standards include a full definition of how to create good cryptographic keys (a required pre-req for signing) and how to properly sign a message. At this point you get into the discussion of Opaque Signatures (where the signature and payload are combined into a single output) and detached signatures.

With an Opaque Signature you will only have one file in the output. It is a combination of the data payload from the original file, and the signature block. While this works well when you are also encrypting the payload (so you'd have to perform a separation and decryption to use the data anyway) its usefulness in scenarios where there is a desire to directly consume the data by an external program varies depending on if that program will be OK with the signature block. For textual messages an Opaque Sig normally isn't an issue. For binary files it will all depend on the software you want to use the file with.

Contrast that with a Separate Signature, where a secondary "signature file" is created to live side-by-side with the original (payload.data and payload.data.signature). This method increases your file count since there are new files for each signature, but the original file will still be able to be opened/viewed in it's intended software without any extra modifications or allowances. This makes the separate signature the more common method for binary files that remain in use. Separate Sigs also have an advantage when using a Time Stamping Authority; you only have to time-stamp the .signature file, reducing the size of the file being transmitted to/from the TSA.

And that then brings us around to the TSA's role in all of this. The thing about a Time Stamp Authority is that they should be near-universally trusted, external and unaffiliated to the parties they provide timestamps for, and impartial in their review of any action. The TSA's role requires them to be neutral across the domain where they are required to provide actionable data. That means if you only need a TSA to provide internal audit timestamps but those aren't required externally, then you can run your own internal authority. But if you need to be able to prove to an outside party that something is accurate as of a given date/time, then the TSA used should be external to both of you (to prove neither of you are tampering with the results). What the TSA actually does is take a file/data, add a timestamp (and, often, information about who requested the time stamp), and then sign the whole thing. So in the end, you may have payload.data, payload.data.signature, and payload.data.signature.timestamped (in some cases .signature is superseded by .signature.timestamped as the final file can provide both functions; other places may need to keep both.)

But this brings up the issue on offline time-stamping. And the answer there is, no. Using a TSA is, by its very nature, asking an external auditor to verify the time something happened. Using an offline TSA (I'm reading it here as: "I self-timestamp the documents without using an external party") breaks the entire reason for performing timestamping at all -- having an unbiased external party verify the time. Otherwise you might as well use the "last modified on date" from the filesystem; you can change your system clock and fake the modified date as easily as you could change the clock and fudge your own internal timestamp. (again, consult your lawyers, but if you're trying to comply to FDA standards then I'm going to assume you're trying to make proofs to an external regulator of some sort) So, no, an offline (or an internal, or an affiliated-to-you) TSA would not fulfill its purpose when trying to make proofs to external entities.

And, finally, a thought about something that came up in the comments (and I briefly touched above). There was some consideration about the fact that this balloons the number of files associated with a project. And, while the .sig and .time files may be small in size, it certainly does. One thing to look at if this is a consideration is what kind of files are being verified, how often in their lifecycle a time stamp is needed, and if they are individual & separable or a group of files in a single project. Most often such signatures and timestamps are applied to final output (or major checkpoint, but not to works in progress); so you don't need tons of these files for points-in-time, just the very few to handle when you need an authority signature. And, often one will look for this kind of authenticity verification for a project and not individual files. If that is the case, it may be prudent to bundle the files together in a single container (zip, tar, etc) and then perform the signing and timestamping on that container. Then you'd have two files: a single archive file for each completed project, and a .signature.timestamp to verify it.

  • This is a really good answer. More than I could expect. Thank you so much. – cinico Jan 10 at 16:47

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.