Changes between Version 1 and Version 2 of CertSig


Ignore:
Timestamp:
Sep 4, 2008, 7:48:15 AM (16 years ago)
Author:
atisu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CertSig

    v1 v2  
    1 foo
     1
     2= Verifying application signatures using X.509 certificates =
     3
     4Beside the project owned executable signing keys (code_sign_public, code_sign_private), OpenSSL RSA keys and X.509 certificates (in .pem format) may be used for signing and verification. This page describes how it can be done.
     5
     6== The .sig file ==
     7
     8The .sig file beside any aplication binary may hold either the "traditional" signature of the file created with sign_executable, or a mixed version, or only signatures to be verified using certificates. When using either mixed or certificate only version, the .sig file should have the following structure:
     9
     10{{{
     11<signatures>
     12    <entry>
     13     <thesignature>
     14%SIGNATURE_CREATED_WITH_OPENSSL%
     15    </thesignature>
     16    <subject>%SUBJECT_OF_CERTIFICATE%</subject>
     17    <type>%MD5_OR_SHA1%</type>
     18    <hash>%HASH_OF_CERTIFICATE%</hash>
     19    </entry>
     20    <entry>
     21      ...
     22    </entry>
     23    ...
     24</signatures>
     25<file_signature>
     26%SIGNATURE_CREATED_BY_SIGN_EXECUTABLE%
     27</file_signature>
     28}}}
     29
     30This structure needs to be filled with the following values:
     31
     32 * %SIGNATURE_CREATED_WITH_OPENSSL% - a signature created using an OpenSSL RSA key and the MD5 hash function
     33 * %SUBJECT_OF_CERTIFICATE% - the subject of the certificate belonging to the key used to sign the binary
     34 * %MD5_OR_SHA1% - should containt either 'md5' or 'sha1'. Currently not used, it is assumed that the signature was created using the MD5 hash function.
     35 * %HASH_OF_CERTIFICATE% - should contain the hash of the certificate belonging to the key used for signing.
     36
     37update_versions will know which type of signatures are in any .sig file and add them to xml_doc (in the database) correctly.
     38
     39== Creating certificates and keys ==
     40
     41This example will describe how a self-signed certificate can be created. For production sites, no self-signed certificates should be used.
     42
     43Firs step is to create an RSA key using OpenSSL issue the following command:
     44
     45{{{
     46openssl genrsa -out my.key 1024
     47chmod 400 selfsigned.key
     48}}}
     49
     50To create a certificate signing request using the key use the following:
     51
     52{{{
     53openssl req -new -nodes -key my.key -out selfsigned.csr
     54}}}
     55
     56It will ask for some information: country name, state name, locality name, organization, organization unit, your name, email address and a password which is optional.  From the request the self-signed certificate can be created:
     57
     58{{{
     59openssl x509 -req -days 365 -in selfsigned.csr -signkey my.key -out selfsigned.cert
     60}}}
     61
     62This will create a certificate named "selfsigned.cert". To view the metadata incorporated in the certificate
     63issue the following:
     64
     65{{{
     66openssl x509 -noout -text -in selfsigned.cert
     67}}}
     68
     69
     70== Signing code and getting information from the certificate ==
     71
     72To sign a file issue the following command:
     73
     74{{{
     75openssl dgst -md5 -sign my.key -out %MYFILE%.sig %MYFILE%
     76}}}
     77
     78This will sign the file %MYFILE% and put the signature in %MYFILE%.sig. This signature file cannot be used yet by BOINC, since it expects a padded and hex converted format. Crypt_prog has been extended to be able to convert between OpenSSL and BOINC formats:
     79
     80{{{
     81crypt_prog -convsig o2b %MYFILE%.sig %MYFILE%.sig.boinc
     82}}}
     83
     84The content of %MYFILE%.sig.boinc can be used to put in the .sig file (to be put in the '%SIGNATURE_CREATED_WITH_OPENSSL%' part).
     85
     86=== Getting the subject of a certificate ===
     87
     88The command
     89
     90{{{
     91openssl x509 -noout -in %MYFILE%.cert -subject
     92}}}
     93
     94will print the subject.
     95
     96=== Getting the hash of a certificate ===
     97
     98The command
     99
     100{{{
     101openssl x509 -noout -in %MYFILE%.cert -hash
     102}}}
     103
     104will print the hash.
     105
     106
     107== Configuration for the Core Client ==
     108
     109Using certifiates for verification on clients id disabled by default. The client configuration file (cc_config.xml) has two parameters which control the use of certificates:
     110
     111{{{
     112<cc_config>
     113  ...
     114  <options>
     115    [ <use_certs>0|1</use_certs> ]
     116    [ <use_certs_only>0|1</use_certs_only> ]
     117    ...
     118  </options>
     119}}}
     120
     121Setting use_certs to 1 will enable the use of certificates, and setting use_certs_only to 1 will allow only the verification of application files using certificates.
     122
     123The client will look for certificates in its data directory in a directory named "certificates/". The certificates should be put there and renamed to %HASH_OF_CERTIFICATE%.<0..X> (e.g.: 72d63c7d.0 ). OpenSSL expects them to be in this format. Numbering should start from 0, and if the hash of two certificates are the same, one of them should be renamed to %HASH_OF_CERTIFICATE%.1 and so on.
     124
     125
     126
     127== Limitations ==
     128
     129 * the <type> field in .sig is not used currently, it is assumed that the hash was created using md5
     130
     131