2

I have a desktop application that uses a kind of package format to load a blob and do something with it. To ensure the authenticity of the blob, I would like to add a digital signature. I researched the topic and there is one thing I do not understand.

If I distribute the public key with the package (having it available online counts as distribution) an attacker can just replace that key with his own public key and spoof a signed package (since the only way for me to validate the signature is to check it with the public key). Am I missing something? How can I sign a package in a truly secure way?

Improve this question

4 Answers 4

Reset to default
2

Digital signatures do not create trust; they just move it around and concentrate it. You are right: if you distribute the public key with the package, you have gained nothing.

What digital signatures give you is the ability to handle your trust separately. You still have to find a way for verifiers (the "desktop applications") to make sure that a given public key is indeed the right public key from the authentic signer. But a public key is somewhat shorter (typically a few hundred bytes), can be shared (you can sign several blobs with the same key), and can be distributed in advance (you can "give" the public key to the verifiers before signing the blobs -- even before knowing how many blobs you will ultimately sign).

Public key is not the only source of trust. Indeed, the code within the application which uses the public key to verify signatures on data blobs must also be part of the "trusted realm"; if an attacker can alter that code, he can replace the verification code with something which just always says "that signature is good". Come to that, he could also plant a virus or a keylogger in the application. So not only you have to start trust somewhere, but the problem is not exactly new either.

Therefore we may assume that you already solved the issue of making sure that when a user gets the application on his desktop system, he gets the "right one" and not a maliciously modified variant. There are several ways (e.g. Web distribution through HTTPS; or installation performed on-site by your personal). This leads us to the following solution: embed the public key within the application itself.

Operating System vendors have done that for years, to enable safe system updates. When a Windows decides that it must download and install an update, it actually verifies a digital signature on the update blob before applying it, and it does so relatively to a public key which is already embedded in the Windows code.

(The system can be made more complex with certificates if you want to support key rollover without a software update.)

Improve this answer
1

The idea of digital signature is to protect data from being change by somebody else in the middle without receiver could check (not by sender or receiver). If you want to protect the data so the client (receiver) can’t change it your options are limited.

Because you are going to use same private/public key for all of your clients you could compile public key into the code (not external resource file), so hacker would have to decompile your code to change it. But if he would decompile your code he can remove the check of the signature altogether.

Aaron

Improve this answer
4
  • If one is going to modify the code and change the signature one can easily change the cert in the code as they do it.
    – ewanm89
    Oct 27, 2011 at 11:01
  • That exactly what I wrote
    – AaronS
    Oct 27, 2011 at 11:04
  • You just modified it, it's still not a solution. It provides no security benefit to code modification, also a hacker could change the code to bypass the signiture check if that's included in the code.
    – ewanm89
    Oct 27, 2011 at 11:06
  • Again, that exactly what I wrote, but what ever
    – AaronS
    Oct 27, 2011 at 11:29
1

Is this for a particular operating system?

Most operating systems have some sort of system built in, as does java and some other crossplatform solutions where the operating system or bytecode interpreter has a root CA key installed in it for this purpose. Or they have a distribution method where the OS vendor will sign the package when it gets put into that distribution system (most linux distros for example).

Improve this answer
6
  • 2
    He is not talking about signing SW distribution package, rather to sign some data that his program uses. Because it is desktop application it can be decompiled and the signature check removed in any case.
    – AaronS
    Oct 27, 2011 at 11:28
  • Yes, what AaronS says is exactly my concern. I discussed this with a friend and he also said that a CA should be used to prove the authenticity, but in any case, the attacker could replace the checked public key in his OS and we are back to square one. BTW to answer your question, it is a cross-compiled Qt/C++ application currently targeting Windows and Linux. (currently there are only windows builds).
    – Tamás Szelei
    Oct 27, 2011 at 12:00
  • @Tamás Szelei - What exactly are you trying to avoid? In the question you sound like you are worried about an attacker being able to spoof the data. They would only be able to modify their local copy of your application.
    – Ramhound
    Oct 27, 2011 at 12:57
  • @Tamás Szelei - What do you care if they modify the local copy or even spoof the data.
    – Ramhound
    Oct 27, 2011 at 13:05
  • I don't want to disclose the details of the app, but it is important to have that data unaltered.
    – Tamás Szelei
    Oct 27, 2011 at 13:28
1

This is why most people use certification authorities to demonstrate the validity of the signature.

There are things you can do to limit your exposure without having to pay for someone else to sign your certificate for you - particularly since (presumably) you are distributing the application as well as the package:

  1. build the key into the software - while this does not prevent an attacker from modifying the key, this is only an issue if the application is distributed via the same channel as the container package

  2. run your own certification authority - implications are similar to the above method - but allows you to use more than one signing certificate

But these are not a substitute for the trusted CA approach.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .