http://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx is the spec for the Authenticode PE signature format.
http://msdn.microsoft.com/en-us/gg463119 is the Microsoft PE and COFF Specification. Better download them now before they disappear, they appear to be deprecated in favor of Windows 8 format packages (of which I have no information). On September 9, 2014 10:18:18 AM PST, Prasad Dabak <pda...@icloud.com> wrote: >Thanks Jacob for your response. Very informative indeed! > >Thanks >-Prasad > >Sent from my iPhone > >> On 09-Sep-2014, at 10:05 pm, Jakob Bohm <jb-open...@wisemo.com> >wrote: >> >>> On 09/09/2014 09:01, Prasad Dabak wrote: >>> Thanks Jacob for an elaborate answer. Somehow I never received your >response to my registered email address, hence delay in responding. >> This time I have CC-ed you in addition to the mail list. >>> I have a few follow-up questions on your response. >>> >>> 1. So, "encryptedDigest" has no relation to the stored >"messageDigest"? I thought it's a encrypted version of the >messageDigest? >> As far as I recall, there is a chain of 4 digests. The first digest >> is calculated over the file and is stored in the spcIndirectData. The >> second digest is calculated over the spcIndirectData (the contentInfo >> of the the PKCS#7 structure) and is stored as "messageDigest" in the >> AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash >> is calculated over the AuthenticatedAttributes and is signed to >> produce the "encryptedDigest" in that same signerInfo. All 3 need to >> be checked to confirm that the file hash is actually (indirectly) >> signed by the encryptedDigest using the public key in the certificate >> whose name is listed in the signerInfo. >>> 2. I agree that it's better to do cheaper checks first e.g. I am >also matching PE checksum stored in the optional header. >> Indeed, though that is a very weak checksum (file size plus 16 bit >TCP/IP >> checksum of file). Also it is allowed to be 0 to indicate no >checksum >> (even if you set the checksum, it might be cleared if an >Administrator >> adds his own countersignature to all authorized programs on his >> computers, aka AppLocker). >>> 3. spcPEImageData is probably relevant only for signing that uses >page hashes? >> I never quite figured out where they store the page hashes. However I >> believe the constant semi-empty spcPEImageData with the >"<<<obsolete>>>" >> string is the traditional marker to indicate that the signature is >for >> a PE file, and not e.g. a document file with the same hashed >bytestream. >> >>> 4. PKCS7_verify is already matching the encryptedDigest, do we still >need to validate it ourselves? >> If it is, I am myself guessing a bit as to what that function does >and >> does not check. But note that it probably doesn't check the full >chain >> of 3 message digests, since at least the digest over the file itself >is >> inside a blob that the PKCS#7 standard has no opinion about. >>> 5. So, basically are are suggesting to look into the subject string >and see if we can find patterns like /CN=COMPANY-NAME... issuer: >/C=US/O=SIGNER_NAME....? How authoritative it is? I mean can someone >else have same COMPANY-NAME and PATTERN-NAME in their certificate? >> Actually, the subject is a data structure (a hierarchical list of >sets >> of tagged strings) and the relevant comparison would be to compare >those >> elements that don't change when getting a new certificate from the >CA. >> It is the CAs responsibility to make sure the don't issue >certificates >> to the wrong people, and if they make a mistake they are expected to >> quickly add the bad certificate to their published CRL, which is why >> you need to check the CRL before trusting the certificate. An >> additional check is to make sure the CA that issued the intermediary >> certificate that issued the "COMAPNY-NAME" certificate is actually >one >> of the (few) CAs that "COMPANY-NAME" is going to buy certificates >from. >> This protects against fake certificates issued by smaller CAs that >> you aren't going to use anyway. >>> >>> In my case, I am the one who is signing the executable using my >certificate and a "cross certificate" issued by Microsoft and I want to >programmatically ensure following things. >>> >>> 1. Code is not tampered since it was signed (matching messageDigest >with computed hash) >> Actually matching digest in spcIndirectData with computed hash. Plus >> consistency checks to make sure the signature is actually for a PE >file >> and was not otherwise doctored. For instance there should be no >bytes >> in the file after the end of the signature blob. >>> 2. Verifying the digital signature (PKCS7_Verify) >>> 3. Confirming that the executable is signed by my company >certificate. >>> >>> I am stuck on part (3) and don't see a clean way apart from matching >strings in subject field? If I hard-code the public key in my >verification code, I will need to update it when I switch to a newer >public key? >> Yep, that is why careful matching against various Distinguished Name >> fields is needed. >> >>> >>>> On Sep 06, 2014, at 09:44 PM, Prasad Dabak <pda...@icloud.com> >wrote: >>>> >>>> Hello, >>>> >>>> Given a signed Windows portable executable, I want to >programmatically verify two things using openssl APIs >>>> >>>> 1. Verify the digital signature. >>>> 2. Confirm that the executable is signed by a specific company >using that company's public key. >>>> >>>> It seems that part (1) can be done by parsing the signedData >attribute in the portable executable, extracting the hashing algorithm >and digest stored there, re-computing the digest of the executable >using the same hashing algorithm and match them. >>>> >>>> I have following questions. >>>> >>>> 1. The signData contains messageDigest (unencrypted) and >encryptedDigest (encrypted). Is it enough to match messgaeDigest with >the computed digest? OR we also need to decrypt the encryptedDigest >using the company public key and match that as well? >>>> 2. What does PKCS7_Verify exactly do? I looked at >https://www.openssl.org/docs/crypto/PKCS7_verify.htmland I understand >that it verifies certificate chain. However, it's not clear to me as to >what exactly it does with respect to signature verification? >>>> 3. I am assuming that I require to do both (1) and (2) in order to >verify the authenticode signature? >>>> 4. What is the best way to verify if the executable is signed by >specific company using that company's public key? >>>> >>>> Any inputs will be greatly appreciated! >> >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com >> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 >> This public discussion message is non-binding and may contain errors. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> >> >______________________________________________________________________ >> OpenSSL Project >http://www.openssl.org >> User Support Mailing List >openssl-users@openssl.org >> Automated List Manager >majord...@openssl.org >______________________________________________________________________ >OpenSSL Project http://www.openssl.org >User Support Mailing List openssl-users@openssl.org >Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
