Are There Reasons to Sign Files Transported via TLS?

Question

Is there any reason to digitally sign transferred files in the following scenario? I.e. an additional signature for the transferred file that is independent of the transport. E.g. an RSA or ECDSA signature of the file itself.

An end device downloads the file via https from a backend system. The end device possesses a certificate to authenticate itself to the server who uses a PKI based certificate to authenticate itself to the client. The client only accepts certificates based from a specific certificate chain.

The files would be signed by the same backend system that the end device downloads the file from via TLS.

It seems that I get authenticity and integrity already from TLS. I don't care about non-repudiation. Is there any good reason for the additional signature on the single files?

Answer 1

TLS ensures integrity of data while in transport. If the file was "generated" by the server without the need for any external input data (e.g., Adobe PDF files can be "generated" on the fly, by combining document templates with other data / metadata), and the server is your "final authority" on the matter, and you've deployed defenses against SSL/TLS MITMs, then you probably don't need any further digital signatures.

If you consider other scenarios such as these below, you would need proper digital signatures signed at each point in the document (or file)'s lifecycle where you need to ensure integrity:

1. The origin of the file is not the server itself but another user - who stored / uploaded it into the server? In this case, would you like to be sure that the file is "as it was originally sent by the first user?" or even "as it was originally created by its author?".
2. The file was generated from external input. e.g., a document from a document store where it was stored after due process (e.g., a registered document) with or without additional annotations. In this case, even though the file was generated by the server, the original data may need integrity guarantees embedded in the document. It is possible to do this by signing just the underlying data - not necessarily the file itself.
3. If it is a device to device communication and there are no other external factors - even then, typically you will have components that originate the data -> some 3rd party components -> transport (usually a 3rd party component) -> recipient with similar stack in reverse. Now your originating and receiving components may or may not want to trust what happens in between (including the possibility of SSL/TLS MITMs) - and hence want "end to end" integrity guarantees; not just transport integrity.

Conclusion: Do you trust every single component between your originating component and your receiving component? If you do, then you're fine. If not, you want to sign the data/file when it's leaving your control and make sure you got it without changes when it reaches your control at the destination.

PS: Points 1 & 2 came up when we were designing the MCA21 system for company registration & annual returns filing (www.mca.gov.in). Point 3 came up in a startup where we were designing a large network of firewalls coordinating their defense.

Answer 2

If the document is used immediately after reception and is not kept for future reference, the digital signing is useless because TLS already guarantees authenticity and integrity during the transfert.

But as soon as the document could be kept for a later use, a digital signature will guarantee that is has not be tampered since reception. Said differently, TLS only protects the document during the transmission, while a signature protects it all along its life. Whether is makes sense here really depends on you use case.