The RFC links helped.
I am able to do decrypt the encrypted digest and match it with the DigestInfo
as explained in rfc2315.
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
Digest ::= OCTET STRING
I typically get back 35 byte decrypted digest which matches with sequence above.
I am also able to validate counterSignatures in similar fashion.
Now I am trying this with various Authenticode executables and one small issue
that I found is: For some authenticode executables, the counterSignature
encryption only considers the bytes of the Digest OCTET_STRING i.e. it does not
consider digestAlgorithm field. Because of this, the decrypted counterSignature
is 20 bytes long (size of sha1 hash) instead of 35 bytes mentioned earlier. It
does match with bytes of the Digest OCTET_STRING.
Is this expected behavior? How do I programmatically check this behavior? If
the size of decrypted counterSignature is equal to size of the hash, assume
that digestAlgorithm field is not considered?
Thanks.
-Prasad
On Sep 16, 2014, at 10:51 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
On 16/09/2014 12:22, Prasad Dabak wrote:
> Hello,
>
> I am currently focusing on matching various digests that we talked
> about earlier in the thread.
>
> 1. Computing the hash of the executable (excluding the areas as
> defined by MS) and matching it with the value stored in
> spcIndirectData. This is straight forward and figured out.
> 2. Computing the hash of spcIndirectData and matching it with with
> "messageDigest" stored in AuthenticatedAttributes. I realized that the
> sequence and length bytes need to be skipped before computing the hash
> of the spcIndirectData? Is this documented anywhere?
This is specified in the PKCS#7 standard (RFC2315), in particular,
PKCS#7 specifies that when there is a non-empty contentInfo field
in the PKCS#7 structure, which part of that should be hashed. In
this case that contentInfo is a Microsoft-defiend spcIndirectData,
but the calculation is unaffected. This should also be built in
to the PKCS7 functions (I hope).
> 3. Computing hash of AuthenticatedAttributes and matching it with
> decrypted version of encryptedDigest. I am struggling to get this.
> Which portion of AuthenticatedAttributes should be considered for
> computing the hash? Further when I decrypt the encryptedDigest using
> the signer's public key, I get back a 256 byte value. This doesn't
> look like a SHA1 hash like in case (1) and (2). So what type of hash
> it is? Can someone elaborate OR point to documentation that elaborates
> on this?
This is specified in the PKCS#7 standard (RFC2315). This should
also be built in to the PKCS7 functions (I hope).
By the way, the rules for checking the timestamp countersignature
(but not its effect on checking the outer signature) is specified
in RFC2985 section 5.3.6. The rules for parsing the SigningTime
attribute used inside timestamp contersignatures (and elsewhere
with less trust) are in RFC2985 section 5.3.3.
>
> On Sep 09, 2014, at 10:18 AM, 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 <mailto: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 <mailto: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!
> > >
> > > <mailto:majord...@openssl.org >
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
