Add support for using the smartcard connector app from a web page

[xtralogic]

Currently the connector app accepts connections only from Chrome apps or extension and implements client whitelisting based on the extension id. To accept connection from web pages the connector app's manifest.json needs to include "externally_connectable" key. For the connections coming from web pages the extension id is null, so whitelisting mechanism needs to be updated to use the client web page origin URL, which is available in sender.url (see chrome.runtime.onMessageExternal.addListener). The whitelisted url format should allow for wildcards, e.g. *.domain.com

[emaxx-google]

Hi, thanks for filing this. This is in plans, although not yet in active development, since we're trying to find a way to limit it only to trusted web pages (for which being on the allowlist might not necessarily be a sufficient criteria alone). We'll share the details once it's fleshed out with security.

[hcldan]

Any updates?

[emaxx-google]

Nothing to share yet. An internal team in Google is still working on a security model for exposing such "sensitive" APIs.

[hcldan]

@emaxx-google Would you (google) like to collaborate? I'd like to help where I can, if I can.

[emaxx-google]

@hcldan This effort is still in the design stage, so unless you have specific ideas of how this can be designed, any concrete steps (like pull requests / change lists) aren't possible at the moment, unfortunately.

Basically, the challenge here is that a regular web page is considered to be an unsafe environment for accessing such a security/privacy sensitive API as PC/SC smart card access. The open web doesn't offer sufficient trust boundaries. Folks in the Chromium project are trying to find a reasonable and maintainable architecture that would allow the page to declare (and prove) its conformance to stricter security boundaries, and gate access to sensitive APIs like PC/SC only to such pages.

[hcldan]

"regular web page"?
I mean there's a lot of development going on for PWA's where google is doing things in a secure way. An https origin with a trusted certificate chain that's allow-listed by user opt-in or admin policy push isn't enough?

[hcldan]

And to that effect... it would be great if this entire extension was merged into chrome-proper so I could use it in a PWA. Could even prompt to allow access to it like NativeFileSystem does.. etc.

[emaxx-google]

I'm not a stakeholder on that topic, but, yes, security teams reviewed the proposal to expose PC/SC to "regular" PWAs and explicitly declined it. Definitely not in all, but in many aspects a PWA is like a regular web page. Admin policies or user prompts weren't considered to be sufficient security measures - because both are unreliable signals about whether the admin/user actually understands the risk and acknowledges it.

[hcldan]

I understand their focus on security. Scoped access would be fine. Provision a key I can encrypt/decrypt from that origin only and give me apis to access the cert, sign, and en/de-crypt.

Are all of these discussion happening behind closed doors?

[emaxx-google]

I see where you're coming from. But not sure how such scoped access would map to PC/SC though - would we need to emulate a device that pretends to have only one certificate? That sounds tricky (especially at the APDU level), and also not a feature request we've heard before.

Some other APIs/technologies offer scoped access in a natural way. FIDO is one good example - not sure if you could work with it? Another is chrome.platformKeys/chrome.enterprise.platformKeys - currently it only supports TPM-backed keys though (integrating it with smart cards was attempted a few years ago, but got stuck due to security concerns around potential cross-protocol attacks). Another option is WebCrypto.

Are all of these discussion happening behind closed doors?

I've checked a few chromium.org bugs and docs - seems like so. I know that's unfortunate, but there's nothing I can do about changing the processes; probably it's a consequence of this topic being both "work-in-progress" and "security-sensitive".

[hcldan]

Well I know I can create and persist origin scoped keys in indexeddb...
I don't get access to the key itself (export = false) , just a key object I can use with webcrypto. That would be a start. If the SC keys tagged with my origin are the only ones allowed, and I can use webcrypto apis to use them... I think that's all I would need.

Re: FIDO - WebAuthn doesn't do crypto, only auth. Already looked here. Re: WebCrypto - Yes I would use that, but I want the key stored securely on the smartcard.

I don't need full PC/SC interface... I just need the operations that one would typically use it for. Some minor key management (origin scoped) sign stuff encrypt stuff decrypt stuff

Hopefully using the webcrypto apis and the same kind of key object I can already work with there and serialize into indexeddb.

[emaxx-google]

I'm not aware of plans to wire up WebCrypto with smart cards (and I imagine this would be a nontrivial project, at least due to the amount of information that WebCrypto abstracts away). My question was whether a locally stored would be suitable for your purposes - but seems like you need SC integration.

If other options listed above don't work for you, I'm not sure about other alternatives besides having a companion application that would do crypto for you. I.e., on Chrome OS, this companion would be an extension that talks PC/SC to the Connector, and on desktop OSes this would be a native application that uses smart card primitives provided by the OS and exposes them to the PWA via native messaging.

[emaxx-google]

This issue is closed, but note that the allowlist of web pages that can talk to the Smart Card Connector is still empty. This is still blocked on getting the corresponding trust guarantees implemented in Chrome.