BOINC uses digital signatures to allow the client to authenticate executable files from the project server.
It is important that you use a proper code-signing procedure for publicly-accessible projects. If you don't, and your server is broken into, hackers will be able to use your BOINC project to distribute malware. This could result in the end of your project, and will negatively impact all BOINC projects.
- Choose a computer (an old, slow one is fine) to act as your "code signing machine". After being set up, this computer must remain physically secure and disconnected from the network (i.e. keep it in a locked room and put duct tape over its Ethernet port). You'll need a mechanism for moving files to and from the code-signing machine. such as a USB memory stick.
- Install crypt_prog on the code signing machine (it's easiest if the machine runs Linux or Mac OS X; Windows can be used but requires Visual Studio).
- Run crypt_prog -genkey to create a code-signing key pair. Copy the public key to your server. Keep the private key on the code-signing machine, make a permanent, secure copy of the key pair (e.g. on a CD-ROM that you keep locked up), and delete all other copies of the private key.
- To sign an executable file, move it to the code-signing machine, run crypt_prog -sign to produce the signature file, then move the signature file to your server.
- Use update_versions to install your application, including its signature files, in the download directory and database.
There are less-secure variants; e.g. you could keep the private key on a CD-ROM that is only mounted during signature generation, on a machine that is disconnected during signature generation. But we do not recommend this; a hacked computer could be running a hidden program that steals the private key and transmits it when the computer is connected again.
Changing your code-signing key
You can change your project's code-signing key at any point. To make this invisible to users, you must do the following steps (otherwise users will have to detach/reattach).
Note: the following requires server software from trunk as of at least 29 Aug 2014. The needed changes are in one function, send_code_sign_key() in sched/handle_request.cpp.
On your code-signing machine:
- Rename your current key pair to old_key_private_i and old_key_i for the next available i (i.e. old_key_0, old_key_1 etc. is the history of your public keys).
- Generate a new key pair, say code_sign_private and code_sign_public.
crypt_prog -genkey 1024 code_sign_private code_sign_public
- Create a "stripped" version (removing the trailing \n) of the public key:
head -c -1 code_sign_public > code_sign_public_stripped(this is needed because 7.0+ clients strip \n from the end of keys).
- For each old key i, sign both the original and stripped versions of the new public key:
crypt_prog -sign code_sign_public old_key_private_i > signature_i crypt_prog -sign code_sign_public_stripped old_key_private_i > signature_stripped_i
- Put code_sign_public and (for all i) old_key_i, signature_i, and signature_stripped_i on a USB memory stick.
- Sign all your app version files with the new key; put these signatures on the memory stick also.
On your project server:
- Stop the project.
- Use update_versions to create new app versions, using the new file signatures.
- Copy code_sign_public and (for all i) old_key_i, signature_i and signature_stripped_i from the memory stick to your project's keys/ directory.
- Start the project.
You might want to do this when your project goes public, you've started using an offline signing machine, and you don't want to force existing users to detach and reattach.