From what I understand about digital signatures, when code-signing exe's it the "signer" modifies the PE itself. I noticed that it adds the certificate content to the end of the PE and also (obviously) adds some kind of reference to the headers.
My question is: How secure is this ? Wouldn't someone capable of reverse engineering the executable be able to forge that onto his own executable thereby forging a digital signature ?
Code signing is a public-private key operation. The signing operation calculates a hash of the .exe file (minus the bits where the signature is stored), then encrypts the hash with the signer's private key.
On client-side validation, the client will redo the hash calculation, and decrypt the stored signature using the public key. If the two hashes match, then the exe has not been tampered with.
The only bits of the file are are encrypted are the signature - everythign else is stored in the clear. Nothing stops you from ripping apart the exe and stuff it (or parts of it) into another .exe.
Signing is not there to prevent theft - it's there to detect tampering.
Related
Lets say you have a windows executable (driver or usermode app), and you want to :
Verify if the digital signature is OK and file is not corrupted (same as when you go to the digital signature tab and it says the certificate is OK)
Find which company signed the file. Therefore I am not talking about the root of the certificate chain (Which is the CA most of the times), I am talking about the bottom certificate in the chain, which is the company that signed the file, i want to get the name of that company.
I found two APIs, WinVerifyTrust And CertGetCertificateChain, But I'm not sure how to use them for this task, or if they can help me with this or not.
Lets say you already have the handle to the file that you want to check, and have read it in a buffer as well, how do you use these to check the certificate afterwards? The documentations are very vague.
Verify if the digital signature is OK and file is not corrupted
For more details about how to Verifying the Signature of a PE File, I suggest you could refer to the example: https://learn.microsoft.com/en-us/windows/win32/seccrypto/example-c-program--verifying-the-signature-of-a-pe-file
Find which company signed the file.
I suggest you could try to use CryptQueryObject function (wincrypt.h).
For more details I suggest you could refer to the Doc:https://learn.microsoft.com/en-us/troubleshoot/windows/win32/get-information-authenticode-signed-executables
And you could refer to the Thread:Read and validate certificate from executable
I am a new developer working on an open source application and I am trying to figure out how one signs a program.
I understand why code signing is a thing, and I know how to get a certificate (from a CA or individually), but I can't find anything explaining the actual process of signing itself once you have your private key.
How does one sign code with a signing certificate? Specifically, do you sign the source code, the built executable, something else entirely? Do you run a specific app, or include something in the code?
related but discrete question: What to do with the code signing certificate?
You have a code signing certificate which contains a private key and a public key.
You calculate a cryptographically save checksum of your code and data, encrypt it with your private key. You add the encrypted checksum and your public key to your code.
Now anyone can calculate the same checksum of your code, decrypt the encrypted checksum with the public key, and compare them. If they match, then it is proven that the code was supplied by someone who has your private key. If they don't match, then it is proven that this code is not the same as the on of which you encrypted the checksum.
To be useful, the operating system would perform this kind of test before any application is allowed to run. And the public key would be signed with well known private key owned by the OS supplier, and would likely be accompanied by data that can be used to identify the owner of the public key.
Obviously EvilHacker could create malware and code sign it. So the fact that it is signed is meaningless. But you would also have the identity of EvilHacker, or the operating system wouldn't start the application. So the operating system will never allow you to run a hacked application or one where the owner of the public key is not known to the creator of the OS.
The second worst a hacker can do successfully is to completely remove the code signing and give you unsigned hacked code - the OS will likely ask you whether you want to run unsigned code or not, or not allow it at all.
The worst a hacker can do is either to con the os owner to accept EvilHacker's code signing certificate, or steal a code signing certificate and create malware that is actually correctly signed.
I'm working on a .NET PDF signature application that allows signing with a SmartCard (Belgian ID). In addition, I'd like the signature to support LTV.
I've followed the instructions and examples from iText, and it seems to work well. Acrobat Reader DC indicates that the signature is valid, and offers LTV.
There is an practical issue however: the included CRL is too big. 14MB on my test ID. This means that, for every signature, 14MB needs to be downloaded which slows down operation and significantly increases the file size of each signed PDF.
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality, however simply removing the CRL and including a OcspClientBouncyCastle instance didn't do the trick. Is the OCSP that is given to SignDetached used to check whether the certificate is revoked at time of signing instead?
A related question concerns the LTV "support" itself. As I mentioned, Acrobat Reader only indicates that the file supports LTV when the CRL is included. Checking at the online service http://dss.nowina.lu/validation (EU reference) seems to indicate something else however. There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data"). As such, I was wondering if it is even needed to include the CRL for LTV?
Suffice to say I'm confused :).
Btw, 2 more warnings from that same verification service that I can't seem to solve: "The 'issuer-serial' attribute is absent or does not match!" and "The signer's certificate is not supported by SSCD!". But maybe thats for another question.
Thanks in advance for any help.
I had a look at your sample document. It does not conform to any LTV profile, merely to T-Level, i.e. it is timestamped.
In detail
The PDF signature is implemented merely by embedding a single CMS container using subfilter ETSI.CAdES.detached which contains
the certificate chain of the signer certificate in the CMS container certificate set
C=BE,CN=Belgium Root CA2
C=BE,CN=Citizen CA,SERIALNUMBER=201103
C=BE,CN=Donny Tytgat (Signature),SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);
a signed Adobe RevocationInfoArchival attribute containing a single good OCSP response for the signer certificate; the response is signed by
CN=Belgium OCSP Responder,C=BE
which has the id-pkix-ocsp-nocheck extension;
a signature time stamp signed by
C=BE,SERIALNUMBER=2014,O=Belgium Federal Government,CN=Time Stamping Authority
Thus, the signature conforms to Baseline T-Level as
A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service
Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually
existed at a certain date and time.
(section 7 - Requirements for T-Level Conformance - ETSI TS 103 172 V2.2.2)
where B-Level conformance is defined as
This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil.
The current clause specifies compliance requirements for short-term electronic signatures.
This clause actually profiles
PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures
that do incorporate signature-policy-identifier) signatures.
(section 6 - Requirements for B-Level Conformance - ibidem)
(Additional requirements also are fulfilled.)
It does not conform to LT-Level which requires:
The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the
validation of the signer, and CA certificates used in signature. This set includes all certificate status
information required for validating the signing certificate, for validating any attribute certificate present in the
signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already
incorporated to the signature.
(section 8 - Requirements for LT-Level Conformance - ibidem)
as there is no revocation information concerning the CA certificate or the TSA certificate.
Thus, it can also not conform to LTA-Level as
A PAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more
document-time-stamp has been incorporated
Concerning other questions
I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality
Given an appropriate PKI infrastructure that is possible. Unfortunately, though, neither the CA not the TSA certificate contain information on a OCSP responder responsible for them. Thus, either the Belgium citizen PKI does not provide OCSP services for those certificates or it merely does not make that provision public.
BTW, this is what the Diagnostic Tree remarks
<Message Id="0">OSCP Uri not found in certificate meta-data !</Message>
are about which you get when verifying your signature using the http://dss.nowina.lu/validation service.
There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data").
This user interface layout has misled you, as mentioned above there are more requirements for LTV-related profiles.
I have another question to security in the web.
If I understand it correctly certificates are for identify who you really are. So the man in the middle attack isn't possible.
But when I see this image:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/800px-Digital_Signature_diagram.svg.png
I think a man in the middle attack is possible. You could split the Signature, the certificate from the data. Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
What I also not understand in this picture is where the certificate gets checked, on the verification side.
thanks.
SCBoy
Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.
The problem is that the receiver will then look at the fake signature and see that it does not match the certificate of the real sender.
You can only create signatures that match a given certificate when you have the correct private key for that certificate (even though the certificate itself is public, that is the magic of asymmetric cryptography). This private key is being kept secret by the owner of the certificate (the original sender of the message).
The man-in-the-middle is prevented by distributing trusted certificates in advance.
You have to trust the authenticity of the certificates, either by trusting them directly (root certificates) or by trusting a chain of signatures on the certificate leading up to one that you trust.
If the man in the middle can make you believe that his fake certificate is the real deal, then the whole system fails.
I would like to verify a signed executable. The requirement is to validate that the executable itself is valid and where it came from (probably from the subject of the cert). The cert type is PKCS.
I found a similar posting here,
Validate Authenticode signature on EXE - C++ without CAPICOM
The Microsoft documentation, among others, appears to point to CertGetCertificateChain, but the examples tend to work with certificates that are in a store. Does anyone know how to validate a signed executable using CertGetCertificateChain and related API's?
I asked this question some time ago. I had your exact requirements. There's sample code in there that will help you. Have fun!!
Can you elaborate? the question you linked to seems to provide all of the answers you should need.
You state that "the examples tend to work with certificates that are in a store", which I take to mean that the executable needs to be signed with a certificate that chains to a root certificate in the machine's trusted store.
This is true; there's no way around that, otherwise there is no way way to trust that the signer is who he says he is, and no way for the provider to revoke the certificate if it's being fraudulently used.
So, WinVerifyTrust is the right way to validate a signed executable. It's a terrible API so be careful. CryptQueryObject and related apis will give you more information such as the name of the person or company that the certificate was issued to.