Code signing

[Anton_Huizinga]

Well, since it is adviced to sign your plugins for use in AutoCAD 2016, I have tried to find answers to my questions about this subject. Unfortunately I have even more questions and less answers, so maybe you all can help.

1. In the help files is stated that if you sign your plugin, then it can be loaded from outside the trusted locations and without the security message box. Somewhere else in the help files is stated that you get a dialog with the question to trust or not trust your application when loading. What is true, if I sign my plugin, will it get loaded without any warning dialog? Or do users have to trust it once?

2. Somewhere I've read that the ApplicationPlugins location under "Program Files" is fully trusted. I've tested it with an unsigned plugin, and it works. I've noticed that Autodesk plugins are installed also under "Program Files" or "Program Files (x86)". Is that the new policy to install all plugins there? What is the reason to accept this location with unsigned plugins, and why should we actually use one of the several other locations for plugins? If I change the install path of my plugins to "Program Files", do I have to change it in AutoCAD 2017 again? I don't get the reason about this inconsistent system.

3. If I buy a code signing certificate, I see different prices and different type of certificates. What level or what kind of certificate do I really need? Global Sign has two certificates, Standard and Extended. They compare the Standard with the VeriSign certificate, but I assume they should have compared the Extended variant. The Standard costs $229 and the Extended $410. The VeriSign certificate costs $499. Yearly.

4. Somewhere in the help I've read that AutoCAD can't use strong names. So I cannot use the certificate with strong naming? I cannot set the signing option in Visual Studio but I always need to post process the signing? It is all new for me, so I hope to get some directions 🙂

[owenwengerd]

---

@autodaug wrote:

Well, you can get a warning dialog if the installer is not running with admin privilege, or if there is Group Policy in effect to control installing to the cert stores. But otherwise, if we're talking about a normal "Software Publisher" certificate (not a Root or Intermediate CA one), then you should be able to install it to the Trusted Publisher store without causing any warnings or dialogs.

---

I see. Yes, in that case the problem is not as severe, as most users will not have changed their default cert store security configuration. Regardless, requiring the publisher cert to be trusted separately from the CA adds an additional burden on both end users and plugin developers with zero or negligible benefit toward the stated goal of reducing the risk of malware. As evidenced in the way web browsers work, the best UX for reducing malware risk in the general case is an unintrusive (negative assent) "untrusted" filter rather than an intrusive (positive assent) "trusted" filter.

[autodaug]

---

@owenwengerd wrote:

requiring the publisher cert to be trusted separately from the CA adds an additional burden on both end users and plugin developers with zero or negligible benefit toward the stated goal of reducing the risk of malware. As evidenced in the way web browsers work, the best UX for reducing malware risk in the general case is an unintrusive (negative assent) "untrusted" filter rather than an intrusive (positive assent) "trusted" filter.

---

Thanks for advancing the discussion, Owen. True, we have added more burdens in the name of security. It's difficult to avoid, as we've seen in all parts of society lately.

I agree that your example of browsers' use of blacklists (negative filters) is a useful part of a security policy. But I don't think it's enough by itself to prevent malware. New threats and targeted attacks can get in and do their damage way before they make it to the blacklist.

You might also be thinking of a "curated" app store where the curator (us) vets and certifies all submissions from developers. That would be another kind of negative filter, and it has some appeal. But it would be a lot more costly and time consuming and would restrict vendors' ability to post releases themselves where and when they want to.

Another thing about browsers, as you know, is that they use digital signatures to verify Java and ActiveX plug-ins, etc. Likewise, Windows uses them to verify driver downloads. You can turn this stuff off, but I believe the trend is to tighten the screws more with each new release.

You can even set a Group Policy in Windows to require a valid signature before loading any exe or dll. Perhaps some customers out there are already running this way.

About whether code signing reduces the risk of malware infection, we can debate that. I would argue that bogus files have a way of getting through the best defenses and policies. So having a reliable way to guarantee the code's chain of custody is very helpful.

But I've gone on long enough - here's another interesting post which mentions how your publisher certificate can develop a reputation and become a quality brand itself:

http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-...

[owenwengerd]

---

@autodaug wrote:

I agree that your example of browsers' use of blacklists (negative filters) is a useful part of a security policy. But I don't think it's enough by itself to prevent malware. New threats and targeted attacks can get in and do their damage way before they make it to the blacklist.

---

I avoided the terms blacklist vs. whitelist purposely, because I wanted to focus on intrusive vs. unintrusive. Let me try to rephrase: Filtering by CA only is a very effective way to block almost all malware, as evidenced by the way web browsers work. Whatever additional anti-malware benefit you get by filtering also by publisher is not worth the UX cost, IMO.

BTW, I'm glad to see you sticking your neck out a bit to debate the issue here.

[autodaug]

I see what you're saying. In order to get a publisher cert, you have to provide some identifying and contact info to the CA (Comodo or whomever), and just that obstacle is enough to make AutoCAD users "reasonably safe". And the amount of additional safety obtained by us requiring users to affirmatively trust the publisher is not worth the intrustion. That seems like a reasonable position - I guess for now we're erring on the side of caution.

[lecartuchen]

Hello,

Any updates on this? Quote from you

...”There's been some discussion internally about whether we can make this easier for developers who distribute via our App Store. It might make sense to add signing as one of the App Store's services - but it's just an idea at this point..”

Appreciate it.

thanks,

[autodaug]

Hi, no new developments on that front, as far as I've been able to find out.

The App Store manages app downloads for many other Autodesk products besides AutoCAD, and it's not under the control of the AutoCAD group.

Hopefully in the years since this thread started, the process of signing apps has gotten a little cheaper and easier.

[ntclmain]

Update information in 2023:

From April 1st, 2023, price for Code signing certificates has increased by ~4 times

On May 25th, I bought a 3-year Sectigo OV Code-signing at the price of 142$

Now, it has increased to ... 678$/3 years!

*

As mentioned in the article here https://signmycode.com/blog/code-signing-certificates-price-hike-up-to-3x-to-4x, 

"According to the official announcements, from May 15st, 2023, organizations will receive Standard Code Signing Certificate’s private key only in an HSM (Hardware Security Module). As the CA’s cost and efforts increase to provide a cryptographic key in a hardware token, it leads to a hike in the certificate’s price to cover expenses."

From the mentioned date, no one will be able to receive a private key through the web-based mechanism. And the sale of software-based OV certificates will also get eliminated."

*

Maybe this will be the end for individual user's code signing certificate (?)

[Anton_Huizinga]

The prices rise indeed, maybe there are providers with a cheaper solution. 

I am not sure if it is needed when publishing via the App store? Aren't the plugin locations not marked as secure folders?

For commercial plugins it is obvious that they must be signed. Maybe one solution for individual hobby programmers is to become commercial programmers and ask some money for their plugins.

[ntclmain]

Hi,

I'm afraid we can't find any cheaper provider.  Previously, Sectigo (or formerly Comodo) provides cheapest Code signing certificate.

I've seen many most download Apps, both paid and free, without digital sign. 

If the App is not signed, user will get a warning "Security-Unsigned Executable File" when running App for the first time; even if the core .dll file is installed into a trust folder.

*

For commercial Apps, a digital sign is recommended but not required by Autodesk App store.  You can see lots of most download paid unsigned App like this or that

[_gile]

Hi,

I Did not sign my plugins on the Apps Store.

I'm not going to pay for applications that I'm offering for free...