1684849 - Mac Big Sur: PKCS#11 Does not open password popup for requesting password

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Nicolas B. Pierron [:nbp]]

Attachment: Mojave/Big Sur side-by-side identical action: lack password popup on big sur.

Tested on Mac Big Sur and the Mac Mojave version, the certificate can be loaded on Mac Mojave but not on Mac Big Sur.

• Using the same Firefox profile on both computers.
• Same certificate.

Mac Big Sur's Firefox does not request the PKCS#11 ECC password as expected, and fails as-if no password were entered.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

From Slack:

"I can’t reproduce this on Nightly or Beta when using a Safenet/Gemalto eToken and the same website. Is this happening on an M1 device?"

"The issue happens on Big Sur (M1) but not on Mojave (x64). Both are on stable Firefox."

Going to assume this is a hardware/ARM64 issue until proven otherwise.

Comment 2

[Kevin Jacobs [:kjacobs]]

Re: comment 1, I tested this on Big Sur (x64), which worked as expected (edit: confirmed that stable works too).

It would be helpful to know the following:

1. What is reported on both machines under about:preferences#privacy -> Security Devices? Is there a difference between machines?
2. If the token/smartcard shows up on both machines in that list, can you select it and click "Log In"? Does the password prompt appear, and does login work?
3. If Security Devices shows that the module is loaded but login fails, are any errors logged in the browser console?

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Kevin Jacobs [:kjacobs] from comment #2)

Re: comment 1, I tested this on Big Sur (x64), which worked as expected (edit: confirmed that stable works too).

It would be helpful to know the following:

1. What is reported on both machines under about:preferences#privacy -> Security Devices? Is there a difference between machines?

Yes, there is a difference.

Mojave (x64):

• "Gemalto USB Shell Token V2" is listed under "ChamberSign PKCS#11" top-level entry.

Big Sur (M1):

• Nothing appears under "ChamberSign PKCS#11" top-level entry.

Removing the entry "ChamberSign PKCS#11" from Big Sur (M1) does not let Firefox adds it back.
We can select the *.dylib file, but it fails to add it, with [fr] "Impossible de charger le module" alert message.

Q: Could it be that the *.dylib is an x64 executable library, while Firefox code is an Arm64?

2. If the token/smartcard shows up on both machines in that list, can you select it and click "Log In"? Does the password prompt appear, and does login work?

The connect button does not become clickable because the "Gemalto USB Shell Token V2" entry does not appear on Big Sur (M1).

The smartcard is well detected by a tool which reports it on both Mojave (x64) and Big Sur (M1) as:
Label: ECC eID
Maker: Oberthur Technologies
Model: IAS ECC 9-250-99

Comment 4

[Kevin Jacobs [:kjacobs]]

Thanks!

Q: Could it be that the *.dylib is an x64 executable library, while Firefox code is an Arm64?

That was my suspicion, or potentially some other incompatibility in the Gemalto library. Does anyone know if Rosetta 2 supports mixing x86_64 and arm64 instructions in the same process?

It might be worth trying osclientcerts [1] (rather than trying to load the Gemalto module directly) as a workaround.

[1] https://blog.mozilla.org/security/2020/04/14/expanding-client-certificates-in-firefox-75/

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Kevin Jacobs [:kjacobs] from comment #4)

It might be worth trying osclientcerts [1] (rather than trying to load the Gemalto module directly) as a workaround.

[1] https://blog.mozilla.org/security/2020/04/14/expanding-client-certificates-in-firefox-75/

Thanks,

We will try tomorrow to:

• Set security.osclientcerts.autoload to true in about:config.
• Otherwise, to copy the installed version of Firefox from Mojave (x64) to have an emulated Firefox. (I suspect this might work, as the smartcard was working after the transition from Mojave (x64) to Big Sur (M1))
• Or, downgrade Firefox to a version when we did not have the Arm64 support.

Would anyone know if there is a way to force the x64 code to be emulated instead of using the Arm64 version even when available?

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #5)

We will try tomorrow to:

• Set security.osclientcerts.autoload to true in about:config.

We tried using this preference, but we were not prompted to enter the password when visiting the website.

• Or, downgrade Firefox to a version when we did not have the Arm64 support.

So far we are using 83.0 as a workaround, and disabled the automatic update, while waiting for a compatible version of the *.dylib files.

Comment 7

[Nicolas B. Pierron [:nbp]]

The best work-around so far is to:

• Open Finder
• Go to Applications
• Right click on the Firefox icon
• Click on "get Info"
• Select "Run under Rosetta"

Which would force Firefox to be emulated, and allow the smartcard library to be loaded dynamically.

Comment 8

[Dana Keeler (she/her) [:keeler]]

My understanding is there isn't anything Firefox can do here.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

Haik, would this be addressable by out-of-process PKCS#11 modules?

Comment 11

[Haik Aftandilian [:haik]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #10)

Haik, would this be addressable by out-of-process PKCS#11 modules?

It would allow us to use the technique we used for Widevine where the arm64 browser could spawn an x64 pkcs#11 process and as long as there were no compatibility problems, theoretically it should work. For this particular need, I'd first recommend running the browser emulated (see User Story instructions) and trying to get the module author to provide an arm64 version.