Jump to content

How to validate a Program or Sequence is not corrupted and came from us


Recommended Posts

How to validate a Program or Sequence is not corrupted and came from us:

Every EXE that you get from LOR (that has been created in the last 2-3 years) should have a digital signature. This signature, which cannot be forged or changed in any way, assures you that a file has come directly from us and has not been modified or tampered with.

How to check a software download:

Once you have downloaded our installer from our website (or have extracted the Sequence/MotionPak installer – see below), using Windows, find the file and RIGHT click it – then select PROPERTIES

1.png
 

Once you have selected Properties another window will show up:

2.png

Go to the ‘Digital Signatures' Tab

3.png

That is our signature. If the file was modified in some way, that signature will not be present. 
If you highlight it and select Details:

4.png

At the top you will see ‘This digital signature is OK’. That should prove the file came from us. If you want to be 100% super-duper sure, press the ‘View Certificate’ button:

5.png

It will show that Entrust, a company to whom we pay a lot of money to prove we are who we are, vouches for this certificate and that it is valid. 

We have to maintain our trust with Entrust to make sure our certificate remains valid. Should we fail, entrust can revoke our certificate and it will say our certificate is no longer valid.

If any modifications are made to the file after it is signed the signature will no longer be valid and will be missing. Here I added one space to the end of the installer code - a minor change that should have no effect at all. But notice that there is no digital signature any longer:

6.png


All of our programs that are installed onto your computer are also signed. If you open where the programs were installed (which should be “\Program Files (x86)\Light O Rama”) you can right click on any of the applications in there and verify they are signed the same way. Signatures can also be found on our library files as they are also programs that can be run (.DLL and .OCX).


All of these signatures verify that what you have is genuine LOR software that has not been modified.

Sequences and MotionPak validation:

Sequence and MotionPak installers are also signed, but they require 1 more step because they are in distributed in compressed ZIP folders. After you download the file, right click it and select Extract All


7.png


Just press OK and when extracted Windows should open a new window with the installer shown: If not, Use windows to go to the location the EXE was extracted to.

8.png
Now the same steps apply as above (right click, properties, digital signature…)

One of the reasons for signing everything is that improves the 'reputation' of code. Virus scanning software likes to see that files are signed by a trusted authority - since that can prove exactly who signed it and that it is most likely not going to be a virus or other harmful software. However, some virus software will still occasionally flag our programs as a virus - something called a 'false positive'. If you get a warning about one of our programs, the first thing to do is check the signature. If it is there and correct, you are assured that it came from us, is not modified, and will be virus free. You can then disable your virus software temporarily or white-list the program in question. Please consult with the manufacturer of your anti-virus on how to do that.

 

9.png

Link to post
Share on other sites
  • 2 weeks later...

Additional date/time stuff:

Recently Microsoft was posting about one of their certificates getting ready to expire in Windows and why you shouldn't delete it.  That made me think that I should also say something about our counter-signatures and how our programs - even long after our certificate expires are still signed and can be trusted.

Remember that signatures rely on trust.  And not just trust, but an entire CHAIN of trust.  Certificates (what are used to generate and validate signatures) are issued based on a hierarchy.  In our example, we are at the bottom.  Our certificate is issued by someone ABOVE us - in our case, Entrust.  If you trust them, then if they say it's OK you can trust us.  If you do not trust them, the chain is broken.  Above them can be another certificate holder who vouches for Entrust (and possibly others) being trustworthy.  That can go on for quite some time until you reach the ROOT certificate.  If at any time someone revokes a certificate, every thing singed from that level DOWN is no longer trusted.  They are all what are known as 'fruit of a poisoned tree'.

Windows comes with many (in my certificate store there are 77) 'Trusted' root certificates pre-installed.  That's why you don't have to explicitly tell Windows 'You can trust LOR's signature'.  Our certificate was issued by someone (Entrust) that can trace it's lineage up to a root certificate already installed in Windows and that certificate is trusted.  [FYI:  You can look at the certificate store on your computer, and you will find Entrust's root certificates]

Now NOTHING stops me from creating my own root certificate and becoming my own CA (that is 'Certificate Authority').  I can certainly create and sign/vouch for other certificates in that chain.   The issue there is the certificate I created is not going to be part of Windows trusted certification authorities.  My signature is pretty much worthless.

FYI:  There are times where self-signatures are a good thing, so don't dismiss them out of hand.  For example, your workplace may issue you a certificate that they generated to allow you to access their servers.  That is perfectly acceptable.   Only you can determine trust, so if YOU trust the company you got the certificate from (which I hope you do since they give you your pay check), use it.

Which brings us to the real topic I want to discuss:  What about if you want to verify something was actually signed with a valid certificate that had a valid chain of trust at the time it actually WAS signed?  For example, our certificate expires in 2023.  But what about if it is 2024?  What stops me from changing the date on my computer to something in 2023 to generate a valid signature?  In 2024 can you still trust something that was signed in 2020 with a certificate the expires in 2023?

That is where the 'counter-signature' comes into play.  When we sign our code one of the things we do is ask another trusted company to countersign - IE add some information to our signature that even we can't modify.  In many cases (like ours), this countersignature validates that we actually signed the file on the date we say we did.

Sure, I can turn the clock back and sign a file.  BUT when the signing process asks for the countersignature things are not going to go right.  The first thing the countersigner is going to do is check that our certificate is valid.  For them it's 2024, our certificate expired in 2023. BZZZ.   It may countersign the file, but it will do so with a 2024 date and our certificate is invalid for that date - and no one (including windows) will trust it.

So why countersign at all?  I signed 5.5.14 in 2020, with a valid certificate.  Let's say it is 2024, but I did NOT countersign the file.  The certificate I signed the file with is expired - and so it is invalid and should not be trusted.  With the counter signature however, you still CAN trust the file - The countersignature proves the file was signed while our certificate was in fact valid.    Even though that certificate is now expired, as long as you trust our counter-signer they will vouch for the fact that it was valid at the time of creation.

In the example above, you can see the countersignature.  You can click on that and look at the details/etc.  You'll see it's chain of trust as well.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.
×
×
  • Create New...