0

I've had looks to existing subjects but it usually gets heavily complicated while I'm new to this kind of stuff and I'd prefer to understand concepts first in order to understand better concrete solution.

I have a client/server application and I'm wondering about its design since every client will be able to generate files (through an interface) to send them to server, but I want the server to be able to say whether or not the file was created with the interface or handly-crafted by a malicious user.

Any existing commons methods? I wondered about hashing the file or using creating my own blockchain but I'm not familiar with this kind of data structure yet, and I've heard it needs some starting time before it really gets kind of "unbreakable", otherwise it's too easy to break.

I've found a page which is about "data tampering", it says the best may to protect from tampering is to restrict access, and that I should use a firewall, but my application will have an online and an offline mode as well, and I need to make sure every file created with connection being established is detected as "corrupted" by the server when the client connects and try to send the file to the server.

|improve this question
  • This question is a bit too unspecific (i.e. broad) and confusing. But in general: anything purely generated by a potentially untrusted client cannot be considered trusted. But if the data are created by some service which is fully under your control (which excludes offline mode with untrusted clients) then you can add a digital signature to the data and can later verify that signature against the data to make sure that nobody has tampered with these. Such service under your control might also be tamper resistant hardware at the untrusted clients side (like a smart card). – Steffen Ullrich May 13 at 8:34
  • Thank you for your answer, my problem is that any client must be able to create a file while offline and when he turns the online mode on to send it to the server it should verify whether or not the file was modified between the moment the file was created and the moment it's sent to the server, but I'm making a draw to make my question more easy to understand then I will edit and add it to my post. – Axel Carré May 13 at 8:54
0

As long as you have a proper SSL in place 95% of your risk factors are eliminated. Because your data-stream is encrypted, a MiM cannot read what you are sending or modify any data in it without completely corrupting what is received on the other side. In order for the file to be intercepted for modification, the attacker would need some manner of malware on your local machine at which point, most origen validation processes become a moot point if your attacker knows what he is doing.

That said, your best bet to prevent externally modified files from being opened by your program is to add tracking codes for each file. The tracking code could be some product of the file's Hash and a verification key generated by your program. That way, even if an end user tries to figure out how to sidestep your upload procedure and push his own file, it won't have a valid key and your program will know not to allow it to be opened. But, as Anders pointed out, this is not a full proof method.

|improve this answer
  • But the client program must know the secret key, so it could be reverse enginered. Once the key is out, your protection is gone. – Anders May 23 at 10:41
  • This is true. Pretty much any method that a client uses to authenticate a file can be reverse engineered with enough effort though; so, while a complex layered approach would help a lot, in the end a client machine will send you what it wants to send you. – Nosajimiki May 23 at 15:32

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.