Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
For this file it shows SHA1:
But going into details the certificate looks like this:
I know SHA1 is an outdated algorithm but I'm not sure about this nested construction. Is this insecure? Which of the two parts matter, does it matter that one is SHA-384 and the other SHA-1 does it compromise it in any form?
The other answers correctly point out that SHA1 is not a watertight hashing algorithm: SHA1 is vulnerable to collision attacks. However, there are no known vulnerabilities to SHA1's preimage resistance nor second preimage resistance, which are properties regarding finding a hash collision for a specific hash/input (as opposed to finding a collision in two arbitrary hashes/inputs). So whether you can in practice trust this signature is down to whether its security relies on SHA1's resistance to collision attacks.
However, due to the certificate signing a specific SHA1 signature of an executable, collision attacks are not relevant. Collision attacks occur from the two hashes you're finding a collision in being free to change. This instead would require one to find a file which gives a SHA1 hash of the signed file's SHA1 hash—a much harder problem and one which SHA1 has no practical public attack for. Authenticode does not rely on collision resistance—only the preimage resistances.
So therefore, providing a malicious executable which has the same SHA1 hash as the SHA1 hash of the legitimate, signed executable is considered completely infeasible, and in practice you can consider this signature valid and the file safe.
As an additional note, SHA1 should still be phased out in software and libraries as it can be easy to unwittingly rely on a property of a hash function which you otherwise think you're not relying on. We should be ensuring that only hash functions with both preimage resistance(s) and collision resistance are supported going forwards in new software and updates. But this doesn't mean that, in this case, it's not providing the securiy guarantees desired.
It is not ok to use SHA1 authenticode signatures in 2023, they are not considered secure. Because of quite realistic SHA1 collision, the code might be tampered in the way that it will produce same SHA1 hash and it will look like the data was not tampered.
If you are the owner of this signature, you have to update your signing tools to use more secure algorithms, such as SHA256 or SHA384. If it was created by someone else, it may be reasonable to contact the owner and point to outdated signing practices.
Even if signed file is supposed to run on a systems where SHA2 is not supported, it is possible to attach multiple signatures, where first signature is SHA1 and another that uses SHA2 family:
Speaking about different hashing algorithms, the signature hash algorithm has no connections to hash algorithm in certificate, they are completely independent things.
As for understanding the 'nested construction', it might help to understand the sequence of operations in this process:
Phase to Phase created a key pair consisting of a private key and a public key.
Phase to Phase created a certificate signing request (CSR) consisting of their name, the public key created in step 1, and other information pertaining to their organization, and sent this CSR to Sectigo for Sectigo to sign.
Sectigo verified that the public key in the CSR that they received from Phase to Phase above in step 2 actually belongs to Phase to Phase. Then, Sectigo created a certificate containing this public key and other information from the CSR, then took a SHA384 hash of this certificate, then used their private key to sign the SHA384 hash. The result of this is the signed certificate whose image you posted.
Phase to Phase took a SHA1 hash of their program Vision951.exe, then used the private key that they created in step 1 to sign the SHA1 hash.
You downloaded Vision951.exe. To verify the integrity of this program, your OS used Phase to Phase's certificate (created in step 3 above). First, your OS verified that the certificate was signed by a certificate authority (CA) that it trusts (such as Sectigo). To do this, it verified the signature using Sectigo's public key. Your OS trusts Sectigo, therefore it trusts this certificate, therefore it trusts that the public key in this certificate actually belongs to Phase to Phase. Your OS then proceeded to extract Phase to Phase's public key from the certificate, then it used this public key to verify Phase to Phase's signature (created in step 4 above) on Vision951.exe.
So, there really is no 'nesting' here. Rather, a chain of trust is built, from the executable program; through the developer of the program (Phase to Phase); to the root of trust, which is the certificate authority (Sectigo).
All of the above is fairly typical, except for step 4. The SHA1 hash function is known to be vulnerable to collision attacks. Even though SHA1 has not been found to be vulnerable to second preimage attacks (which are really what matter when it comes to hashing for the purpose of signing, as pointed out in the answer by Alex W) - once a crypto algorithm shows any sign of weakness whatsoever, security people tend to run from it. See What are the implications of a SHA-1 collision being found? for more interesting reading on this subject.
