| | 1 | |
| | 2 | |
| | 3 | |
| | 4 | BOINC uses a public/private key pair for signing application code. Signing can only be done using the projects own key. By using certificates the signing process can be detached from the Project, and handled by a third entity (Application Certified). This allows several things: |
| | 5 | |
| | 6 | * The clients may choose to trust in certain Application Certifiers instead of trusting every application they get from a given project. |
| | 7 | * Applications may be automatically deployed on projects (no need to use the code signing key). |
| | 8 | * A chain of trust may be built for any application which allows to identify the entities responsible for any given application |
| | 9 | |
| | 10 | Whom is it useful ? Probably for most Projects the key based signing method is enough. In our case (SZTAKI) we are developed a method to interconnect different BOINC projects, and we needed to move not just work units but also applications belonging them between projects. Using the key based signing method would have required to store the code signing private key on the project's (networked) machine to be able to sign any incoming application, which represents a great security risk. Instead we chose to implement a new authentication method for BOINC in order to be able to move applications controlled between projects. |
| | 11 | |
| | 12 | |
