search

daisy / ace-gui

Ace by DAISY App, the official graphical user interface for the EPUB accessibility checker developed by the DAISY Consortium, available for the Windows, MacOS and Linux desktop operating systems.
MIT License
18 stars 6 forks source link

Remove installation/security warnings by using an Extended Validation Code Signing Certificate (MacOS: done, Windows: todo) #15

Closed rdeltour closed 4 years ago

danielweck commented 5 years ago

https://www.electron.build/code-signing

rdeltour commented 5 years ago

Status of the Apple certificate progress

The objective is to enroll in the Apple Developer Program as an organization.

For this I need:

Once DAISY is finally enrolled in the ADP as an organization, I will be able to add our Apple ID to it, and to get a certificate.

I'll update this comment as the process moves forward!

danielweck commented 5 years ago

Thanks Romain! :) PS: s/APD/ADP

rdeltour commented 5 years ago

Status of the Windows certificate progress

On Windows, according to the electron-builder doc:

To sign an app on Windows, there are two types of certificates:

  • EV Code Signing Certificate
  • Code Signing Certificate Both certificates work with auto-update. The regular (and often cheaper) Code Signing Certificate shows a warning during installation that goes away once enough users installed your application and you’ve built up trust. The EV Certificate has more trust and thus works immediately without any warnings. However, it is not possible to export the EV Certificate as it is bound to a physical USB dongle. Thus, you can’t export the certificate for signing code on a CI, such as AppVeyor.

We'd need to buy a cert from the following authorities, which are trusted by Windows: Symantec, Certum, Entrust, GlobalSign, Comodo, DigiCert. The cost seem to be around 300/400 USD per year.

Certum provides an Open Source Code Signing Certificate which is much cheaper (~30 USD). But I'm not sure it fits our needs. One of the difference with the standard certificate is that the open source one is not "cross-certified by Microsoft". Looking deeper, it seems it doesn't support Microsoft's Authenticode technology. I don't know if it's an issue for us…

Also, the Certum certificates seem to rely on a physical USB token and cryptographic smart card. So it's not ideal in our distributed environment. They do propose cloud-based certificates (a bit more expensive).

For now, I'm asking around if DAISY has any existing certificate plan or services that we could use for Ace.

I'll update this comment as the process moves forward!

danielweck commented 5 years ago

For Windows, a USB device is required to transport and authorize the cryptographic information related to the certificate (secure hardware token). The shipping delay may therefore be consequential. Further, using Windows virtual machines in order to build and test the Ace app (which is my current setup / workflow) might be problematic when using a USB crypto key.

Regarding costs, the base price at Certum goes from 25 EUR to 69 EUR due to the need for the hardware device, but this is still reasonably cheap (note that the certificate would only be valid for a year). However, note that a proper EV certificate costs 359 EUR per year at Certum (or a bit less when buying 3 years upfront). Such EV cert would be needed to cover "Deleting the Microsoft SmartScreen Filter® system message" (trust based on instant reputation), otherwise the non-EV certificate (for open-source software) only "Eliminates system messages like: "Unknown publisher" and "Unsafe software" (trust builds up over time ... I'm not sure how that works in practice).

https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-1001.html

https://www.certum.eu/en/cert_offer_cert_comparision_cs/

Note that with Certum, the Open Source option does not provide the option "Certificate cross-certified by Microsoft". This, I think, is okay, because we do not need to sign low-level kernel software. See:

https://docs.microsoft.com/en-gb/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

danielweck commented 5 years ago

Ah, Romain beat me to it :) So yes, Certum is not the only option, see: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate

DigiCert (ex Verisign?): https://www.digicert.com/order/order-1.php

Symantec (which seems to rely on DigiCert authority): https://trustcenter.websecurity.symantec.com/process/trust/productOptions?productType=EVCodeSigning&flavor=MSAuthentiCode&application_locale=VRSN_US&newLanguage=en

Comodo: https://ssl.comodo.com/code-signing-certificates https://comodosslstore.com/codesigning.aspx https://comodosslstore.com/code-signing/comodo-ev-code-signing-certificate

Sectigo (replaces Comodo?): https://sectigo.com/products/signing-certificates/code-signing

Ksoftware (Sectigo sub-CA) https://www.ksoftware.net/code-signing-certificates/

GlobalSign: https://www.globalsign.com/en/code-signing-certificate/microsoft-authenticode/ https://www.globalsign.com/en/code-signing-certificate/ev-code-signing-certificates/

Thawte: https://www.thawte.com/code-signing/content-signing-certificates/microsoft-authenticode/

Resellers: https://cheapsslsecurity.co.uk/sslproducts/codesigningcertificate.html https://codesigningstore.com/code-signing https://store.wotrus.com/

DaveGunn commented 5 years ago

Both the GlobalSign certificate types appear to offer Azure Key Vault storage options, which presumably would be much faster and would provide the central storage solution we need. https://www.globalsign.com/en/code-signing-certificate/

danielweck commented 5 years ago

Romain, also note that the Ace app will need to pass Gatekeeper on recent versions of MacOS, so there are additional notarization steps in addition to code signing: https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/ (useful article from early June 2019)

danielweck commented 5 years ago

Dave, good point about the Azure Key Vault. However because of 2FA (Two Factor Authentication) I wonder if a mere developer like myself will be able to access the crypto key / code signing certificate "owned" by the DAISY account.

DaveGunn commented 5 years ago

I've not used it before, but I would anticipate access being made available through the O365 credentials - but if it requires more I'm sure we can resolve that.

danielweck commented 5 years ago

Another aspect to be aware of: timestamping. We might want to make sure that code signing certificates remain valid after the duration for which they were purchased (1 to 3 years). This way, in the future, even if the Ace app has not been updated for a while (and the cert would normally have expired), users will continue to be able to install the app and use it.

danielweck commented 5 years ago

Also note that Lets Encrypt unfortunately cannot issue Code Signing Certificates (OV or EV) due to prioritizing automation in order to be cost effective (i.e. no human verification of identity / trust). https://community.letsencrypt.org/t/do-you-support-code-signing/370/18

danielweck commented 5 years ago

Certum actually provides a cloud-based crypto service which removes the need for the USB secure token. The SimplySign app must be used to operate the system: https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-on-simplysign.html

danielweck commented 5 years ago

I have contacted Certum. In the meantime, here are some useful reads: https://markheath.net/post/code-signing https://blogs.msdn.microsoft.com/ieinternals/2015/01/28/authenticode-in-2015/

DaveGunn commented 5 years ago

The EV certificates cost a little more, but removing the MS smart screen warning is probably worth it when we can then apply the certificate across all DAISY tools. Note the open source certificate linked above is NOT Microsoft certified - so won't achieve the intended objective. App access to the certificate management might be too restrictive for us to fully benefit from the certificate. Centralised key storage makes a lot more sense for flexible use by a number of people.

danielweck commented 5 years ago

The EV Code Signing Certificate is definitely the best option in that regard: instant trust assertion, removal of all warning messages on Windows (SmartScreen when downloading, as well as UserAccountControl when installing). Caveat: this requires a hardware token (i.e. secure USB key provisioning of the crypto package) in order to offer further guarantee that the private information used to sign products cannot be used by unauthorized entities. Consequently, the certificate cannot be exported and used in Continuous Integration scenarios, or in automated build workflows locally on via virtual machines. Certum's product line now provides a cloud authentication service (and a local app named SimplySign) which is meant to be an alternative to the physical hardware device for the purpose of establishing identity. However, I am pretty sure that the same build workflow limitations apply, due to the provisioning method requiring human intervention (I have asked them for clarifications, waiting for reply).

If I understand correctly, the OV Code Signing Certificate (e.g. Certum's "standard" product) removes the UAC "unidentified publisher" warning, but the SmartScreen will continue to be triggered initially, due to trust needing to build-up over a period of time. This is compliant with Microsoft Authenticode for both user-level and kernel-level code. USB hardware token remains obligatory, or in the case of Certum there is the aforementioned cloud-based alternative.

The Certum's "Open Source" Code Signing Certificate seems to be a lightweight version of the "standard" OV Code Signing Certificate, in the sense that it is bound to an individual instead of an organisation, thereby requiring fewer checks to prove identity during the registration phase. I have asked Certum whether or not the user experience is the same as with their "standard" product (with respect to the the SmartScreen and UAC warning messages). There is some ambiguity with regards to the compliance with Microsoft Authenticode too.

DaveGunn commented 5 years ago

A hardware token seems to be required by most providers, with the exception of GlobalSign who support the Azure Key Vault. The reputation building process for Standard certificates isn't clear, and we risk not having sufficient instances to build the required "reputation". The challenge with EV will be the time it takes to pass the organization validation process for the certificate to be issued, but the longer term gain is probably worthwhile.

rdeltour commented 5 years ago

If I understand correctly, the decision-making is about:

  1. deciding on OV vs. EV certificate
  2. deciding on the certificate provider

And then each point can be broken down in smaller decisions:

  1. deciding on OV vs. EV certificate means:
    • [x] do we consider that getting rid of the SmartScreen warning is important? Yes.
    • [ ] do we know how long it would take to build trust with our estimate user base?
    • [x] is the cost acceptable? Yes (from what we heard from DAISY's C-level. to be confirmed before purchasing of course).
  2. deciding on the certificate provider
    • [ ] what are acceptable Cryptographic options? Ideally we'd like to avoid a physical cryptographic token. We then need to check if the given technology is compatible with our build workflow.
    • [ ] Certum provides EV Code Signing in the cloud. Would it fit our needs?
    • [ ] GlobalSign allows EV code signing certificates to be installed in Azure Key Vault. Would it fit our needs?
    • [ ] any other option?
    • [ ] compare the cost of the various certificate providers.
    • [ ] Should we compare all the certificate authorities?
    • [ ] Some certificates can be acquired from intermediaries (i.e. not directly from the CA) at a lower cost (for instance comodosslstore, ksoftware, etc…); is that an option?
    • [ ] do we buy for 1 year or more?

It seems to me we're moving towards getting an EV certificate. But there are still a few decisions to make and offers to compare. Thoughts?

danielweck commented 5 years ago

Some clarifications / confirmations received:

Most Code Signing Certificate retailers or Certification Authorities (including Certum) will not provide direct access to *.p12 or *.pfx files, i.e. to the private keys used for signing resources. This is standard practice. Only the public part of the certificate can be used directly. The private part is accessed via an authentication proxy, i.e. the signing keys are provisioned via a cryptographic engine that connects to a hardware or a virtual token (a-la Azure Key Vault, or Certum's SimplySign cloud solution).

This is fine, as far as we are concerned. The DAISY Ace GUI app installers are created using the ElectronBuilder set of utilities, which connects to the key provisioning subsystem via an explicitly-specified certificateSubjectName (see https://www.electron.build/configuration/win#WindowsConfiguration-certificateSubjectName ). This is not dissimilar to MacOS's KeyChain.

danielweck commented 5 years ago

I have received confirmation that the only difference between Certum's "Open Source" Code Signing Certificate and the "standard" product (besides the kernel-level software option afforded by the "certificate cross-certified by Microsoft" feature) is that the former includes "Open Source Developer" in the CN, but they otherwise have the same capabilities / limitations (i.e. basic Microsoft Authenticode, building reputation over time in order to gain SmartScreen trust).

danielweck commented 5 years ago

Also, the certificates issued by Certum are time-stampable, using Certum's own http://time.certum.pl or any other, e.g. http://timestamp.digicert.com

danielweck commented 5 years ago

So, it looks like the two top options are EV Code Signing Certificates from:

rdeltour commented 5 years ago

Apparently Sectigo (formerly Comodo CA) also offers a cloud option (PDF link) (called "Cloud Service Module" or "Code Signing on Demand"). The cost is 399 USD for 1 year, 897 USD for 3 years.

danielweck commented 5 years ago

Note that support for Azure Key Vault entails additional costs:

https://azure.microsoft.com/en-gb/pricing/details/key-vault/ https://azure.microsoft.com/en-gb/pricing/calculator/?service=key-vault

...so although GlobalSign appears to be slightly cheaper (assuming the taxes are at about the same level as Certum), there would be a financial overhead with the Azure account and the Key Vault transactions. Further, I am wondering about the potential difficulties in setting up Azure Key Vault on developers' environments, especially Virtual Machines).

avneeshsingh commented 5 years ago

Many times the software, especially the large software are distributed offline, and are also installed on computers without internet connection. Will this solution work for them.

rdeltour commented 5 years ago

Many times the software, especially the large software are distributed offline, and are also installed on computers without internet connection. Will this solution work for them.

Yes. The cloud solution is to sign the code (on the developers side), not to verify the signature (on the users side). As long as our certificate is issued from one of the Microsoft-approved certificate authority, that would work well offline if I understand correctly.

rdeltour commented 5 years ago

there would be a financial overhead with the Azure account and the Key Vault transactions

that might be included in the Azure package we already have.

We can describe a shortlist of solutions which we're confident would work for us, and then inform @DaveGunn and the management so that we can pick the best option wrt cost and infrastructure.

danielweck commented 5 years ago

Thank you Romain for the Sectigo PDF. The step-by-step instructions reveal what I feared: in order to sign our Electron app, we would have to introduce a manual step consisting in uploading the resource to sign, or alternatively the resource hash (in which case we would then have to integrate the signature digest back into the resource ourselves).

In other words, we would not be able to rely on ElectronBuilder's built-in support for signing (i.e. in-line, as part of the installer creation process).

rdeltour commented 5 years ago

in order to sign our Electron app, we would have to introduce a manual step consisting in uploading the resource to sign, or alternatively the resource hash

it seems they have an API, so it should be possible to ultimately integrate that in a custom build, if not in electron-builder itself…

DaveGunn commented 5 years ago

Just to confirm any Azure Key Vault costs would be covered by our existing Azure infrastructure account.

danielweck commented 5 years ago

Good to know Dave, thanks.

danielweck commented 5 years ago

Romain, good to hear about the possibility of using an API to securely communicate with the GlobalSign Code Signing service. In ElectronBuilder there is a "sign" step which can be used to invoke an external shell script (thereby bypassing the default Windows signing method which consists in automatically querying the key provisioning subsystem via the certificateSubjectName): https://www.electron.build/tutorials/code-signing-windows-apps-on-unix

danielweck commented 5 years ago

Another thing to note about obtaining an EV Code Signing Certificate: the DAISY organisational identity, as well as that of the person registering, will need to be asserted by the Certificate Authority in order to establish trust. We will therefore be required by the accredited retailer to provide documents that prove identity, which usually involves a Notary.

I am not totally sure about GlobalSign, but I imagine they do business in the USA, where DAISY has representatives. I think (based on the PDF linked by Romain) that the expectation is to have somebody from the management team registering and acting as the primary contact point + platform administrator. Then, developers like myself can obtain credentials to authenticate into the secure cloud signing solution.

Certum is based in Poland. Although they accept digital scans for their lower-tier products, I imagine the prerequisites for issuing EV certs are more stringent. I have asked about their SimplySign cloud solution, so I have a better idea of the key-provisioning + resource-signing workflow (and whether it is compatible with ElectronBuilder).

rdeltour commented 5 years ago

Romain, good to hear about the possibility of using an API to securely communicate with the GlobalSign Code Signing service.

Just a clarification: the PDF was from Sectigo (formerly Comodo), not GlobalSign. I don't know if GlobalSign also have an API, they probably do but this would need to be verified.

danielweck commented 5 years ago

Ah yes thank you Romain (typo on my part).

danielweck commented 5 years ago

As mentioned before, the process of applying for an EV Code Signing Certificate requires providing proof of identity, either via a Notary, or remotely by sending appropriate documentation, like Romain did to setup an Apple Developer Program for an organization (not an individual), DUNS number, etc.

Here are the instructions provided by Certum: https://www.certum.eu/en/support/cert_expertise_tsupp_cs_requaired/

danielweck commented 5 years ago

I now have confirmation that Certum's SimplySign cloud+app -based virtual hardware token system integrates well with the signtool command line executable (short video tutorial): https://www.certum.eu/en/support/cert_expertise_activate_cs_certificate_on_simplysign/

This is good news, it will integrate well with ElectronBuilder's default signing process on Windows, and can even be integrated as a custom step if we face issues with the default implementation. Basically, the virtual hardware token seems to behave just like a physical USB device.

I imagine that Sectigo's ad-hoc suite of tools (Code Signing on Demand (CSoD) + CCM Comodo Certificate Manager) operates in a very similar way, and that GlobalSign's Azure Key Vault provides a similar integration path.

danielweck commented 5 years ago

Another technical thing to note about Certum's SimplySign: the signtool command line instructions are based on the certificate's thumbprint (whereas ElectronBuilder integrates via certificateSubjectName), which means that we might indeed have to use the custom sign step in order to invoke our own custom script. Still, the process seems very simple using a temporary token.

I had another look at Sectigo's PDF (Code Signing on Demand (CSoD) + CCM Comodo Certificate Manager), and I don't see an integration path with signtool, so this might be problematic.

danielweck commented 5 years ago

The MacOS app / DMG code-signed with the DAISY certificate works when launched locally without any warning messages, but the app indeed fails to launch when downloaded from an external source (GateKeeper blocks it due to not being notarized):

“Ace by DAISY.app” can’t be opened because Apple cannot check it for malicious software.

This software needs to be updated. Contact the developer for more information.

Safari downloaded this file today at 00:45.

DAISYAceAppSignedNotNotarized

danielweck commented 5 years ago

Positive progress:

spctl -a -v /Applications/Ace\ by\ DAISY.app =>

/Applications/Ace\ by\ DAISY.app: accepted
source=Notarized Developer ID

The Gatekeeper message is now:

“Ace by DAISY.app” is an app downloaded from the Internet. Are you sure you want to open it?
Safari downloaded this file today at 01:53. Apple checked it for malicious software and none was detected.

(with the "open" button, so no need to right-click + open menu)

DAISYAceOk

danielweck commented 5 years ago

codesign -dvvv --verbose=4 /Applications/Ace\ by\ DAISY.app

=>

Executable=/Applications/Ace by DAISY.app/Contents/MacOS/Ace by DAISY
Identifier=org.daisy.ace
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1753 flags=0x10000(runtime) hashes=46+5 location=embedded
VersionPlatform=1
VersionMin=657920
VersionSDK=658432
Hash type=sha256 size=32
CandidateCDHash sha1=a2f037a9844147925510c5d6e2c9db64d22d78f5
CandidateCDHash sha256=ff61ac272a690ba6b2cb645a2a58b63a28d99a19
Hash choices=sha1,sha256
Page size=4096
CDHash=ff61ac272a690ba6b2cb645a2a58b63a28d99a19
Signature size=9064
Authority=Developer ID Application: US Fund for DAISY (SAMG8AWD69)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=19 Jul 2019 at 01:39:20
Info.plist entries=23
TeamIdentifier=SAMG8AWD69
Runtime Version=10.12.0
Sealed Resources version=2 rules=13 files=17520
Internal requirements count=1 size=176
danielweck commented 5 years ago

I tested the app with the default notarization entitlement com.apple.security.cs.allow-unsigned-executable-memory, all the features in the app seem to work fine.

rdeltour commented 5 years ago

Awesome! Thanks for the hard work Dan 👍🎉

danielweck commented 5 years ago

Related issue: https://github.com/daisy/ace-gui/issues/10

ways2read commented 5 years ago

I have a call with a Microsoft MVP on Thursday, who is helping out with code review and advice for the WordToEPUB proof of concept. I will be asking about code signing to remove the scary messages for the not so technical users of this tool. I've read this thread in preparation, and will report back. It may be that some learnings can be useful for ace-gui.

DaveGunn commented 5 years ago

A 3 year EV Code Signing Certificate has been ordered through GlobalSign Ltd. Verification will probably take a couple of weeks after which it will be available for use through the Azure Key Vault.

danielweck commented 5 years ago

This is wonderful news! Thank you for taking care of this. Let's hope this will integrate with the Ace App build workflow! :) Fingers crossed.

DaveGunn commented 5 years ago

The security around hosting a central EV certificate means it probably won't be a simple add-on process. We may need a VM build platform with access to the Vault - so obtaining the certificate is only step one in establishing a certification process.

labsforge commented 4 years ago

Hi Ace team! it seams we're on the same journey! what a tedious and horrible experience... It has been a good reading this issue, has we had hit the same walls too 😅 We also acquired the EV certificate from globalsign, and now we are trying to figure it out on how to integrate it with electron-builder.. if you have any progress on this would be very helpful! btw this should be featured on electron-builder docs, because it haves all the process of decision on witch certificate to buy and why, I wish I've seen this before..

danielweck commented 4 years ago

Hello @labsforge I am glad to hear that you managed to extract useful information from this messy / organic conversation thread! :)

We're using an ad-hoc environment variable SKIP_NOTARIZE to make sure that the afterSign NPM task (which is part of the electron-builder process) is not invoked when the app is built from the Continuous Integration server (in our case, Travis).

https://github.com/daisy/ace-gui/blob/41c3fb511165543d95e0ab7c39b273f3bf85f033/.travis.yml#L96

https://github.com/daisy/ace-gui/blob/41c3fb511165543d95e0ab7c39b273f3bf85f033/package.json#L143

https://github.com/daisy/ace-gui/blob/41c3fb511165543d95e0ab7c39b273f3bf85f033/package.json#L50

https://github.com/daisy/ace-gui/blob/41c3fb511165543d95e0ab7c39b273f3bf85f033/build/notarize.js#L6

Extra tip: in another project we also use the CSC_IDENTITY_AUTO_DISCOVERY=false environment variable to ensure that electron-builder does not automatically discover a locally-installed signing certificate (e.g. MacOS KeyChain) when building from a developer computer. This allows us to build production-grade apps (i.e. code-signed and notarized), as well as "preview" / test apps (not signed) on the same computer.