TurboSFV - Digital Signatures Overview Digital signatures are used to ensure that program files have not been changed after publication and that the software came from the publisher. They are based on digital cer­tifi­cates, which are issued by an authorized and trusted authority to a person or company, identi­fied by the authority. If an executable file is digitally signed, then a user can decide whether or not to run the file by checking the signature. For the validation of the digital signature, two parts must be checked: Digital signature: This is an encryp­ted hash value, pro­duced by a hash function for a file and encrypted with the private key of the underlying cer­tifi­cate. To verify a signature, the encrypted hash value will be decrypted by using the public key and the output must match the re-calculated hash value by using the same hash function. Certificate: A soft­ware comes from the publisher, if it was signed with the cer­tifi­cate of the publisher. Thus, it must be checked, whether the correct cer­tifi­cate was used and whether the cer­tifi­cate is valid. In particular, the issuer of the cer­tifi­cate, the owner, the certi­fication path, the serial number and the thumbprint must be validated.   This article was last updated on 2023-NOV-04, to reflect changes regarding the used cer­tifi­cate starting with TurboSFV v10.00. If you like this article, then please set a link to it. Digital sig­na­tures and TurboSFV All program files of TurboSFV, which contain executable code, are digitally signed, including the setup. The used cer­tifi­cate was issued for code signing ( enhanced key usage: 1.3.6.1.5.5.7.3.3 ). The following values are needed for the validation of the underlying cer­tifi­cate, which is used for digitally sign TurboSFV v10.00 and newer: Issuer: Certera Code Signing CA Owner: Jörg Krahe Certification path: Sectigo (AAA) USERTrust RSA Certification Authority Certera Code Signing CA Jörg Krahe Serial number: 00 8a 3c bb bf 7b b8 01 c6 83 4c 51 23 f4 b7 80 92 Thumbprint: (SHA-1, insecure) 36 ee 2d 00 82 c3 34 a9 96 b8 1f 84 af 45 ed 37 9d 9f 87 23 Alternative, secure thumbprints (checksums) of the cer­tifi­cate - not displayed by Windows: SHA3-256: 32b4b88f16cb90258669d09d034aca2bc1f1c97499cb4f7c3c7ad6119773f7b2 SHA-256: 971cfef1ee727a50c30ac831c9be296618e9e0a657772d56739e6b84926d0f53 Read below for further instructions how to calculate and use them. Used hash functions The hash function SHA-1 is used for calculating the thumbprint for the underlying cer­tifi­cate. Since 2005, successful attacks on SHA-1 are known, so that SHA-1 checksums can not guarantee security, when it comes to digital signatures and cer­tifi­cates. SHA-1 should only be seen as some kind of pre-check (if wrong, then failed - if correct, then check further). The secure alternative is a hash function from the SHA-2 family, such as SHA-256, SHA-384 or SHA-512 or even better, one from the SHA-3 family (SHA3-256, SHA3-384, SHA3-512). The executables from TurboSFV are signed with two digital signatures, one based on SHA-256 and another based on SHA-512. Windows should displays both, the primary signature, which is based on SHA-256 and the additional signa­ture based on SHA-512. Both hash functions are supported in newer Windows versions. The thumbprint for the cer­tifi­cate, which is displayed by Windows, is based on the insecure SHA-1. Thus, it can't be used alone to validate a cer­tifi­cate. Alternatively, a secure hash function (i.e. SHA3-256) could be used to identify a cer­tifi­cate (validation steps explained below). Validation of the digital signature Check existence of the digital signature The necessary information is located on the tab sheet Digital Signatures: Locate the file in the explorer, right-click on the file which opens the context menu and then select Properties. If you don't see this tab sheet, then the file isn't digitally signed or the signature was removed - the validation failed. In newer Windows versions, you should see one entry, where the hash function SHA-256 was used for the digital signature and another based on SHA-512. The value for Name must appear as displayed, the time­stamp indicates, when the file was signed (the value above should be treated as an example and will change for new versions of TurboSFV). Now select for example SHA-512 and click on Details. Digital Signature Details A new window pops up, which displays general information about the signature. The most important information on this page is the state­ment, that the digital signature is OK. The signature is OK, if the file has not been altered after signing: The calculated hash value, based on the selected hash function, matches the decrypted hash value in the signature, the certification chain is com­plete, and the underlying cer­tifi­cate (which can be a fake) is OK. Otherwise an error message is dis­played, marked with an error sign, for example: In this case, the signature is invalid. If you see any error message, then the validation failed. The field Name indicates, who signed the file and should exactly look as displayed. The field is taken from the underlying cer­tifi­cate, which now needs to be examined to ensure, that the correct cer­tifi­cate was used and that the cer­tifi­cate is valid (an attacker can sign a file with any cer­tifi­cate containing fake values). Take also a note of the signing time, because the underlying cer­tifi­cate is only valid for a certain period and must be valid on this date. Click on View Certificate for the validation of the used cer­tifi­cate. Validation of the cer­tifi­cate A new window opens, which has three tab sheets containing details about the cer­tifi­cate, which was used to sign the file. A cer­tifi­cate can be seen as a digital identity card, issued by an authorized and trusted authority to a person or company, iden­tified by the authority. Issuer and owner On the General tab, you see some basic information about the cer­tifi­cate. The purpose field should be filled as displayed and indicates, that the cer­tifi­cate was issued for code signing (technically taken from the field enhanced key usage in the cer­tifi­cate: 1.3.6.1.5.5.7.3.3). Any error message or warning like indicates a pro­blem with the cer­tifi­cate and the validation failed. Now review the two fields Issued to and Issued by, which must have the following values, else the validation failed. Issued to: Jörg Krahe Issued by: Certera Code Signing CA The time period indicates start and end date, in which the cer­tifi­cate is valid. A file must be signed within this period, the signing time is displayed in the Digital Signature Details. Serial number and thumprint Checking the serial number ensures, that the correct cer­tifi­cate was used, and not another issued by the same authority (assuming that the serial number is unique within the authority). A different thumbprint indicates a wrong or damaged cer­tifi­cate. Open the Details tab, ensure you have selected Show All: The serial number for the cer­tifi­cate is managed by the authority and should be unique. The cer­tifi­cate, which is used to sign TurboSFV v10.00 and newer, has the following serial number: Serial number: 00 8a 3c bb bf 7b b8 01 c6 83 4c 51 23 f4 b7 80 92 uppercase: 00 8A 3C BB BF 7B B8 01 C6 83 4C 51 23 F4 B7 80 92 This is a hexa­decimal number and can appear in uppercase letters in some versions of Windows. Now scroll down the list and select the field Thumb­print: The thumbprint is a SHA-1 checksum for the cer­tifi­cate: It's not a part of the cer­tifi­cate, but calculated, used and displayed by Windows. The cer­tifi­cate, which is used to sign TurboSFV v10.00 and newer, has the following thumb­print: Thumbprint: 36 ee 2d 00 82 c3 34 a9 96 b8 1f 84 af 45 ed 37 9d 9f 87 23 uppercase: 36 EE 2D 00 82 C3 34 A9 96 B8 1F 84 AF 45 ED 37 9D 9F 87 23 Also the thumb­print is hexa­decimal notated. As explained, the thumbprint is a checksum for the cer­tifi­cate, hence a checksum for all fields in the cer­tifi­cate. Because of the security issues with SHA-1 (see Used hash functions), the SHA-1 thumbprint alone can't guar­an­tee correct­ness. However, a wrong thumbprint surely indicates an error. If the Serial number or the Thumbprint doesn't match, then the validation failed. Now let's take a second and think about the thumbprint: If we could get a checksum for the cer­tifi­cate from a secure hash function (such as from the SHA-3 family), then it would be enough to validate that checksum, because it covers all fields in the cer­tifi­cate. Unfortunately, Windows displays only the insecure SHA-1 thumbprint - but nothing keeps us away from calculating a secure thumbprint by ourselves, so here we go. Alternative, secure and fast method for vali­dating the details of a cer­tifi­cate We calculate a SHA3-256 checksum of the underlying cer­tifi­cate and compare the result with a given one, provided by the software author. If both are the same, then we don't have to check special fields in the cer­tifi­cate, because we can trust SHA3-256. In particular, the following three steps need to be processed: Extract the cer­tifi­cate from the executable. Calculate a SHA3-256 checksum for the extracted cer­tifi­cate. Compare the calculated checksum with the one provided by the software author. In the picture above, which shows the details of the cer­tifi­cate, you may have noticed a little button: If you click on it, a cer­tifi­cate export wizard opens, which allows to extract the cer­tifi­cate from the exe­cutable. Click on next to select the export file format. In the dialog, select DER encoded binary X.509 (.CER) as the file format. In principle we could use any file format, but we must agree on one, otherwise we can't compare the check­sums. Further­more, Windows uses the same file format for calculating the SHA-1 thumbprint, so we are here in line with Windows. Click on next to specify file location and name, again on next to review your settings and click on finish to save the file. For calculating the SHA3-256 check­sum, you must have a checksum utility installed. Of course we use TurboSFV, in particular the Shell extension of TurboSFV, which helps us with the calculation of the SHA3-256 check­sum: Right-click on the exported file, select properties and navigate to the property page Hash. Select SHA3-256 as the hash algo­rithm. If you want to compare with the Windows SHA-1 thumbprint, then tag also SHA-1. The SHA-256 checksum is also mentioned here: The hash function is widely spread, but the underlying algorithm is less secure comparing to SHA3-256. Click on start, then copy and paste the results into a text document and compare the SHA3-256 check­sum with the following: SHA3-256: 32b4b88f16cb90258669d09d034aca2bc1f1c97499cb4f7c3c7ad6119773f7b2 SHA-256: 971cfef1ee727a50c30ac831c9be296618e9e0a657772d56739e6b84926d0f53 If the checksum matches, then the correct cer­tifi­cate was used, else the validation failed. As you can see, this method is quick, easy and secure. As a pre­condition, the software author must provide the original SHA3-256 checksum of the cer­tifi­cate. Now we still have to have a look on the certification path. Certification path The certification path needs to be reviewed, to ensure that the correct authorities are involved and that the certi­fication chain is complete. In newer Windows versions, the path should be built as follows: Certification path: Sectigo (AAA) USERTrust RSA Certification Authority Certera Code Signing CA Jörg Krahe Serial numbers: Sectigo: ‎01 USERTrust: 39 72 44 3a f9 22 b7 51 d7 d3 6c 10 dd 31 35 95 Certera: 21 66 f0 8a 51 eb fc ab cc 8f 44 30 91 a9 4b 0e Jörg Krahe: validated in previous step The top entry indicates the root authority in this chain. In Windows, a list of trusted root authorities is stored in the cer­tifi­cate store. Microsoft keeps this list updated via the Windows Update feature, but the list can also be managed manually by users (or programs) with appropriate privileges. The bottom entry indicates the cer­tifi­cate holder, all other entries are intermediate cer­tifi­cates. The cer­tifi­cates are trusted by their parent cer­tifi­cate, except the root cer­tifi­cate. For the certification authorities, Windows may display so called "friendly names", which can be different - thus the serial numbers of the underlying cer­tifi­cates are mentioned here as well for further examination. The certification path, which is displayed, is the result of an operation, where Windows tries to resolve the path from the cer­tifi­cate holder up to the root authority - depending on which cer­tifi­cates are available in the cer­tifi­cate store. The certification path is also called certification chain or chain of trust, and must not be broken. A broken chain, where the broken part of the chain is marked with a red error sign, can - for example - look like this: A broken chain means, that you can't trust a particular cer­tifi­cate and thus, you can't trust all child cer­tifi­cates in the chain, because they are issued by their parent. The validation failed. Now we also know why a certification chain must be complete: If not all cer­tifi­cates are displayed, we can't check whether or not a particular cer­tifi­cate was - for example - revoked meanwhile, and thus we can't trust all displayed cer­tifi­cates. An incomplete chain may look like this: Here, the root cer­tifi­cate isn't available in the Windows cer­tifi­cate store, thus the path can't be resolved. In this case, Windows might then display a warning in the cer­tifi­cate details on the general tab ... ... and thus an error in the signature details, because the signature is based on that cer­tifi­cate: Interpreting results   If you have successfully finished all steps, then you can assume, that you have the original file.   If at any point the validation failed, then most likely you don't have the original file and you shouldn't run it. If the validation failed for the setup program of TurboSFV. then download it from this website. If you have problems with validating the underlying cer­tifi­cate, then you should consult your administrator. You can also contact us as indicated under support.
Privacy Policy Copyright © 2007-2025 Jörg Krahe. All Rights reserved!