Adding Chrome OS (with smart card) support via a non-native browserpass-native replacement

[fmeum]

Unfortunately, browserpass cannot be used on Chrome OS since this platform lacks support for native messaging. I am the author of smart-pass, a fork of an earlier version of browserpass, which gets around this issue by offloading the work done by gpg to a smart card (e.g. a Nitrokey or YubiKey). Smart card support is available for Chrome OS thanks to the official Smart Card Connector app.

Now that the shiny new version 3 of browserpass is out (thanks a lot for that!) and provides a documented protocol for communication with browserpass-native, I think that it would not be too difficult to convert the functionality provided by smart-pass into a Chrome OS extension replacing browserpass-native on that platform.

The rough plan for this would look as follows:

1. Develop a Chrome extension that speaks the browserpass-native protocol and provides the functionality of the native helper, for example by fetching .gpg files from Google Drive and decrypting them on a smart card.
2. Change hostAction to make it speak to a configurable, whitelisted non-native extension that provides the functionality of browserpass-native.

If there is interest in Chrome OS support along this route and the resulting extension could become part of the official family of browserpass repos, I would try to carry out the work needed to make it happen. Please let me know what you think.

[maximbaz]

Hey, nice project 👍

I think making Browserpass attempt to speak to a different "host" isn't that big of a deal, my main concern would be functionality differences and future maintenance (simply because no maintainers have Chrome OS, so it would be hard to ensure a new release isn't breaking anything there).

Functionality-wise, I can see there are some differences between Browserpass v2 and smart-pass, could you clarify if these differences caused by a limitation of the technology, or something you just haven't gotten around to implement?

For example:

smart-pass is based on browserpass and compatible with one of its two storage formats for passwords.
...
Example: If the user john@doe.com uses the password 123457 on mail.example.com, smart-pass would look for a folder mail.example.com containing a file john@doe.com.gpg with the encrypted password.

Is there something fundamental that is preventing to retrieve the username from the contents of the gpg file?

The UI is also slightly different judging by the screenshot:

Is all of this something that you would like to preserve, i.e. become part of Browserpass main extension?

---

If the current Browserpass UI would require no changes, and a native host replacement would be able to support every bit of the functionality that the main native host supports, and all we'd have to do is to extend the function that speaks to native host, we should consider this (although still not sure about maintenance, will it limit us developing native host in the future, if we won't be able to extend and test the ChromeOS alternative).

If the native host functionality cannot be matched, if the UI will need to be changed, if this would require new functionality (such as allow to enter PIN, some extra settings to control PIN caching), I'm not entirely sure merging two extensions would be a good idea in general.

[fmeum]

Thank you very much for the quick reply!

Functionality-wise, I can see there are some differences between Browserpass v2 and smart-pass, could you clarify if these differences caused by a limitation of the technology, or something you just haven't gotten around to implement?

There is a single limitation, which is not specific to Chrome OS but rather to the use of smart cards, which applies equally well to the current browserpass when used with a gpg key on a smart card: Decryption operations are comparatively slow, and sometimes even require a user gesture (e.g. with the Yubikey's "required touch" functionality enabled). Hence "just decrypt all the files and search through them" is an approach that will never be viable using smart cards. Luckily, browserpass (so far) only has to decrypt a single file per login, which allows me to use it successfully with smart cards and touch confirmation.

Every other shortcoming of smart-pass is solely due to me focusing almost exclusively on the core functionality (smart card support). This is also why I would ultimately like to see smart-pass integrated into another extension: I know my way around smart cards, but neither have the time nor the skill to provide a UX as polished as that of browserpass. I could of course fork every release of browserpass and patch in smart card support, but that does not sound like a reasonable approach in the long term.

Some minor issues might arise because Google Drive does not natively support globs, but I am pretty sure that this can be worked around.

The UI is also slightly different judging by the screenshot:

Is all of this something that you would like to preserve, i.e. become part of Browserpass main extension?

No, quite the opposite is true, I would actually not want to change anything about browserpass' UI. Off the top of my head, there is a single UI-related point (apart from the likes of additional settings on the options page) which demands attention, see below.

If the current Browserpass UI would require no changes, and a native host replacement would be able to support every bit of the functionality that the main native host supports, and all we'd have to do is to extend the function that speaks to native host, we should consider this (although still not sure about maintenance, will it limit us developing native host in the future, if we won't be able to extend and test the ChromeOS alternative).

As I said above, I believe that this is possible right now. Of course, if you were to introduce full-text search through all .gpg files in the store at some point, this functionality would probably not be usable for smart card users, whether on Chrome OS or not.

Regarding maintenance: I would plan for the new extension, let's call it browserpass-smart for now, to consist of three parts. One would handle the messaging protocol, one would retrieve files from a remote source such as Google Drive (or anything else someone would like to see support for on Chrome OS) and one would communicate with the smart card. The first two would not be Chrome OS-specific and could be tested in Chrome on all platforms. The latter can unofficially be tested on Linux and Windows, since Google's Smart Card Connector app does run in Chrome on these platforms. But the code for smart card communication would be comparatively stable, as it would really only need to change when a new key type is added to the OpenPGP smart card protocol.

If the native host functionality cannot be matched, if the UI will need to be changed, if this would require new functionality (such as allow to enter PIN, some extra settings to control PIN caching), I'm not entirely sure merging two extensions would be a good idea in general.

Additional UI is indeed needed for one thing: PIN entry. Since I would not like the smart card PIN to pass through extension messaging, I would suggest to have a simple UI for this directly in the browserpass-smart extension. Once per browser session, the user would "unlock" the extension by entering the PIN, and it would then provide the same services to browserpass-extension (and only this extension) as browserpass-native does. The PIN cache in browserpass-smart could then be configured (delete after x mins of inactivity, delete on screen lock, delete on user gesture/key shortcut...). All of this could be part of browserpass-smart, similar to how gpg-agent handles this natively, and not concern browserpass-extension itself.

Of course, I am open to suggestions on any of this!

[maximbaz]

There is a single limitation, which is not specific to Chrome OS but rather to the use of smart cards, which applies equally well to the current browserpass when used with a gpg key on a smart card: Decryption operations are comparatively slow, and sometimes even require a user gesture (e.g. with the Yubikey's "required touch" functionality enabled). Hence "just decrypt all the files and search through them" is an approach that will never be viable using smart cards. Luckily, browserpass (so far) only has to decrypt a single file per login, which allows me to use it successfully with smart cards and touch confirmation.

Of course, if you were to introduce full-text search through all .gpg files in the store at some point, this functionality would probably not be usable for smart card users, whether on Chrome OS or not.

Well aware of this as I'm using Yubikey myself, Browserpass will never change in this regard 👍

For this reason we for example don't consider url: fields inside password entries when deciding which passwords to show in a popup for a certain domain (because it would require decrypting everything just to draw a popup), and as I said it will not change.

Regarding maintenance: I would plan for the new extension, let's call it browserpass-smart for now, to consist of three parts. One would handle the messaging protocol, one would retrieve files from a remote source such as Google Drive (or anything else someone would like to see support for on Chrome OS) and one would communicate with the smart card. The first two would not be Chrome OS-specific and could be tested in Chrome on all platforms. The latter can unofficially be tested on Linux and Windows, since Google's Smart Card Connector app does run in Chrome on these platforms. But the code for smart card communication would be comparatively stable, as it would really only need to change when a new key type is added to the OpenPGP smart card protocol.

This proposal sounds quite interesting, but @erayd and I need to discuss this a bit more to make sure we thoroughly consider the consequences. For example, if that so happens that one part of the proposed new extension is not usable on Linux, this will make the entire extension not testable for us...

Just curious, how involved would you like to be in the development and maintenance of this new extension? There's no wrong answer, it's okay if you'd prefer doing something else, knowing if you are passionate about developing and/or maintaining that extension, if you will be available / interested in implementing features as they are developed for browserpass-native would simply help us evaluate the consequences.

No, quite the opposite is true, I would actually not want to change anything about browserpass' UI.
Additional UI is indeed needed for one thing: PIN entry. Since I would not like the smart card PIN to pass through extension messaging, I would suggest to have a simple UI for this directly in the browserpass-smart extension.

👍 👍 👍

[maximbaz]

And one more thought, are you aware of any other platforms where this would be useful, or we are targeting exclusively ChromeOS here, because Smart Card Connector is built for ChromeOS?

[fmeum]

This proposal sounds quite interesting, but @erayd and I need to discuss this a bit more to make sure we thoroughly consider the consequences. For example, if that so happens that one part of the proposed new extension is not usable on Linux, this will make the entire extension not testable for us...

I have used smart-pass together with the Smart Card Connector successfully on Chrome OS, Linux and Windows. While non-Chrome OS platforms are not officially supported, the SCC runs very reliably on them. On Linux, one only needs to stop pcscd and reconnect the smart card, on Windows, a different USB driver needs to be installed via Zadig (more info). The problem is that Chrome Apps are deprecated on these platforms and it is hard to tell for how much longer they will work.

Just curious, how involved would you like to be in the development and maintenance of this new extension?

I would try to develop a full port of browserpass-native, but could probably use some advice when it comes to the PIN entry UI and options. I would also agree to maintaining the smart card part of the new extension for the foreseeable future. I have already added support for smart cards to the official Chrome OS SSH extension/app, and the codebase would be almost the same, so this doesn't really add any maintenance burden for me. Whether I would also act as a maintainer for the Google Drive/protocol part of the extension for an extended period of time is something we could discuss.

And one more thought, are you aware of any other platforms where this would be useful, or we are targeting exclusively ChromeOS here, because Smart Card Connector is built for ChromeOS?

For as long as Chrome Apps still run on other platforms, the extension would serve as a replacement for the gpg dependency. It has the advantage of being fully plug&play with respect to multiple smart cards as card info is never cached and there is no need for secret key stub refreshing a la gpg --card-status.

[fmeum]

In order to provide more of a basis to the discussion about whether or not something like browserpass-chromeos is a good idea, I went ahead and drafted up the structure of a Chrome App clone of browserpass-native. It supports and validates the communication protocol and tries to mimic browserpass-native's behavior as closely as possible. It supports all actions, with the crucial exception that "fetch" will not decrypt the file contents before sending them back to browserpass-extension, but rather considers the content of the *.gpg files to be plaintext. Of course this makes it unfit for actual use, but should allow you to get a feel for the ergonomics and performance of everything the app would do except for the smart card decryption (and therefore PIN entry UI) functionality.

The app is available at https://github.com/FabianHenneke/browserpass-chromeos and can be loaded as an unpacked extension on all platforms. If you want to give it a try, the README contains a minimal patch that needs to be applied to browserpass-extension for it to communicate with browserpass-chrome.

[erayd]

@FabianHenneke Are you able to explain how you intend your demo to be set up? I've installed it and applied that patch, and changed no other settings - and all I get out of it is this:

I'm not expecting it to actually work, but I should still be seeing the list of credentials, right? Note that I do have custom store locations configured, if this is a factor.

[fmeum]

@erayd I'm sorry, having a custom store location already configured unfortunately breaks the more descriptive first error message I intended new users of the demo to see (before I provide proper documentation in the README). Chrome OS (or rather the chrome.fileSystem API on all platforms) does not support arbitrary file access. Please start the browserpass-chromeos app, for example from chrome://apps, and follow the instructions to authorize access to your stores.

@maximbaz Since #61 presumably introduces at least a few more actions, it is probably better to first agree on whether to go forward with browserpass-chromeos and have a version not supporting these additional actions reviewed. In that case, I would add support for the new actions later in order to simplify the decision and review process.

[erayd]

@FabianHenneke That worked, although I did have to delete all my custom stores before it was happy to work. Initial impressions - it seems to work well.

Currently discussing this with @maximbaz before we give you a final yes / no. However, my current thoughts are that this is probably a good idea, with the following conditions:

• The extension must be testable outside of ChromeOS, as neither @maximbaz nor I have a ChromeOS device. We both use Linux as our primary OS.
• You need to commit to maintaining it, and keeping feature parity with the native host app.

I would prefer that this be hosted as another repo under the browserpass organisation, to keep everything in once place. I'd also prefer if @maximbaz could handle the releases, so that releases can easily be synchronised (if necessary - this won't always be the case) with the native host app and the main extension.

The fact that Chrome apps are deprecated on non Chrome OS platforms worries me. This is probably my biggest concern right now, as it would result in myself and @maximbaz being unable to test it. I do have an old Dell laptop I might be able to get a third-party version of Chrome OS onto, which may be a workaround - will give that a shot and let you know.

[fmeum]

@FabianHenneke That worked, although I did have to delete all my custom stores before it was happy to work. Initial impressions - it seems to work well.

Since browserpass-extension settings are not synced between devices and custom store locations without prior authorization will never work on Chrome OS, I just decided to assume the user starts with no stores, but it would of course be possible to just ignore these stores instead of aborting with an error.

A third-party version of Chrome OS could be a viable option for testing purposes. I'm somewhat optimistic though that Linux support is not going away too soon since no date has been communicated yet.

I would commit to maintaining browserpass-chrome (but would let @maximbaz do the webstore releases/release signing, which is a definite plus for me since he is already a very trusted figure). If for some reason I should no longer be able to keep feature parity with browserpass-chromeos anymore at some point in the future, I would at least try to keep up until the next major release of browserpass-native and only then fall back to maintenance only. Keeping feature parity in the face of #61 will be a great test, but due to the availability of isomorphic-git and openpgp.js I'm pretty confident that it can be achieved.

I would like to reserve the right to be somewhat opinionated though, as I believe it is very important to keep all browserpass-*s both safe by default and at a reasonable level of complexity. For example, I would prefer not to implement support for ECC keys on smart cards since this combination (to the best of my knowledge) lacks crucial security guarantees when used with pass.

[maximbaz]

Just want to apologize for the big delay with #61, guys if you want to resume this discussion (and/or start implementation), I'm all for it - we can deal with new changes brought by password generation later.

[fmeum]

I finished a first feature-complete version, which is now available at FabianHenneke/browserpass-chromeos. I maintain a patched fork of browserpass-extension with Chrome OS support at FabianHenneke/browserpass-extension.

When you have the time, just take a look and let me know what you like and what you would prefer to be done differently. I could then improve the UI, add comments,.. You can take your time though, I will have less time to work on this in the future anyway.

I have made preparations for adding support for #61 via isomorphic-git and openpgp-js. This includes a database for public keys that can either be extracted from a smart card or added from a file. It shouldn't take me too long to implement the rest when #61 should finalize.

A noteworthy omission is the lack of support for ECC keys. These are not only somewhat painful to implement (the card only takes care of the key exchange part), they also have the UX drawback of requiring additional information for decryption that does not seem to be available from the card. I would probably defer adding support for this until #61 makes public key management necessary anyway.