-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for pkcs#11 smart card (eg Yubikey) for OpenPGP #964
Comments
The standard is called PCKS#11. Need to double check that I'm not wrong and that Yubikeys indeed follow this one. There is various support on Chrome and Firefox, and it also depends on the host OS (I think). I believe it may even require to install a library on the host OS when using Chrome (eg a .dll on windows or .so on linux). This needs to be researched and prototyped to know for sure. |
Suggestions for a prototype:
Once it can do some basics, I can take over to finalize & integrate. |
Beta tester for Ubuntu / Chrome: https://mail.google.com/mail/u/0/#inbox/160a144b7c1ecd73 |
Hi , |
+100000 |
Sorry everybody, it's non-trivial. It seems to me there will need to be a solution for each browser, and for each platform. Please post your OS/version and browser, so that we get an idea of which one to start with. Mine is: Ubuntu 17.10 / Chrome |
Windows 10 / Chrome or Firefox |
Ubuntu 17.10 / Chrome |
Windows 10 / Chrome |
MacOS 10.13 / Chrome or Firefox |
Microsoft Windows [Version 10.0.17134.112] I also have a PixelBook running ChromeOS. |
MacOS 10.12.6, Firefox Nightly 62.0 |
MacOS 10.13.6, Chrome Version 68.0.3440.106 |
Always on latest stable release versions of MacOS and Firefox. |
Thanks everyone for the details! Going forward just OS and browser names, without versions, will be enough (because by the time we get to implementing this, all versions mentioned will be dated anyway). Ubuntu + Chrome |
One more user with Ledger: https://github.com/LedgerHQ/ledger-app-openpgp-card |
Debian + Chrome This feature might become a game changer for secure email communication |
On Android, the openkeychain supports this. In Windows, the latest version of gog4win seems to include some gpg/kleopatra plugin to interact with browsers ?? (Not sure what). That could allow on the browser the usage of external gpg (and off course, yubikey et all)... |
Thanks for the notes. This was never part of our Android app. K9 is completely unrelated. |
Is there any update to put this on a roadmap or otherwise as the issue has been open for more than a year at this point? |
Agreed, it would be nice to see this formally on a roadmap and considering
the growing popularity of such devices would be a great addition.
…On Fri, 18 Jan 2019 at 17:02, Chris Wiegman ***@***.***> wrote:
Is there any update to put this on a roadmap or otherwise as the issue has
been open for more than a year at this point?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#964 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABzcxzYDWz5IYPfkw90u5Nkpo4RZwmJqks5vEfAqgaJpZM4QuVdg>
.
--
Use this contact page to send me encrypted messages and files
https://flowcrypt.com/me/phillipmcmahon
P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.
|
I cannot put it onto a formal roadmap without having resources to get it done. If a community member can step up and create JavaScript APIs for the 4 actions described above, in an environment that I can test (ubuntu, chrome or firefox, Yubikey), we could possibly get this in sooner. |
Some update; Mailenvelope supports communication with local gpg, this is for Windows (not tested on Linux/MacOS) - would allow key management though GPG (and YubiKey). Is there any prototype of necessary API ? |
Out of curiosity did some more digging and it seems that there is standard being incubated called WebUSB, that could in future allow this use case natively without need of any middleware installed directly on the machine. For now, only Chrome supports this standard. Currently, I believe that only cross-browser solution is using middleware software installed directly on the OS that will bridge the gap between the HW and the browser. There are already some solutions for this like https://github.com/PeculiarVentures/fortify For me, unfortunately, the missing support of smart cards is a no-go as I don't trust storing my private keys directly on PC (#paranoia). |
@AuHau thanks for this info! I would much rather bet on a future browser standard than on a bunch of middleware that user has to install. In particular, I really dislike the idea of asking your regular Joe and Jane to install GPG ... (as suggested above).
This is encouraging. https://github.com/PeculiarVentures/fortify also looks sort-of acceptable, but being able to do it straight from the browser would really be great. In fact, I just created an empty MIT-licensed repo at https://github.com/FlowCrypt/webusb-openpgp and on behalf of FlowCrypt I'm putting up a $5,000 USD bounty for someone to fill it with quality code. I hope that we can find someone who is qualified to be working on security-critical software, or alternatively, I hope we can find a security researcher who can donate their time to do a security review when this project is done (possibly sharing part of the bounty with the developer, or doing a pro-bono review). Kindly, if anyone in this conversation has any experience with WebUSB or Yubikeys and wants to chip in with a little bit of wisdom, eg if such project seems feasible, whether the bounty amount seems appropriate etc etc, let's discuss this below. If you know a friend who can chip in some wisdom, please invite them here. Once we reach a consensus on a rough way forward and approximate specs, FlowCrypt will announce the bounty on our web, the repo and our Twitter. |
I use Chrome OS, Qubes OS (Fedora 28) and Ubuntu 18.04. |
Well at least we have a full thread of possible early testers, that helps. |
Glad, you find the information helpful! And really appreciate your interest and willingness to pursue this! During my digging, I also found already some work for CCID interface using WebUSB, so that might be a good inspiration to look into https://github.com/jbirkholz/webusbAuth Unfortunately, my domain of knowledge does not lay in this field, so can't really offer help here, but I will be at least cheering on the way! 👏 |
Few people have this type of expertise. If we're lucky maybe the contributors to that repo can share their experience. @jbirkholz or @frankmorgner - if this ping reached you - if you'd be so kind and take a look at a look at #964 (comment) to give us any feedback, that would be awesome and hugely appreciated. |
As far as I remember, WebUSB only works with a subset of USB device types. Specifically, CCID doesn't work anymore in recent chrome releases, though I can't find the note to that change anymore. Hooking into the js bindings of gpgme looks like your best option. This is exactly what Mailenvelope does. |
@frankmorgner thank you very much for your kind feedback! |
General notes follow I'm trying to avoid doing what Mailvelope does. That would be last resort if nothing else can be done. If this chrome issue affects us and it's an unintended bug, creating a clear repro case may increase chances of this getting fixed by the Chrome team. Or sponsor a 3rd party PR in chrome codebase, assuming their team is receptive to that, and it's not broken intentionally for other reasons. |
Why don't you want to use gpgme? Blocking CCID devices was an intentional move by the chromium team. It never worked ideally anyway, because, by default, when the OS' builtin smart card reader driver grabbed the USB device, which was then unavailable for the browser. |
We hope that encryption becomes a lot easier to use than it is today, allowing wider audience to benefit. That's the direction we are trying to push towards. For software that's meant to work from the browser, requiring user to install GPG, install gpgme, then pair that up with our extension is a big ask. Even if we could package a convenient self-contained binary for Windows, Mac and Linux that takes care of this, we are still requiring the user to install native app in order to use a web extension - something I'd like to avoid at all cost IF it can be done straight from the browser. I'm wondering what the status on Firefox is. That would have to be evaluated: https://wiki.mozilla.org/WebAPI/WebUSB |
It doesn't matter whether Firefox blocks CCID directly or not, there's always this race condition with the native driver. See https://github.com/jbirkholz/webusbAuth#os-specific-requirements for details on what the user would have to do to avoid this. Since smart cards (OpenPGP card) are somewhat integrated into each OS, you always depend on a native module. You may distribute gpgme along with your extension, if you want a one-click-installation from a user perspective. Currently, there is no Browser API for accessing standard hardware tokens (PC/SC). In the past there were different plugins for that, but none really succeeded. Accessing a device through WebUSB only makes sense when that device was specifically designed for that use. (I'm sure some smartass now screams: "There is a Smart Card Connector for Chrome, i.e. https://github.com/GoogleChromeLabs/chromeos_smart_card_connector!" But let's be honest: That's only an option for Chrome OS.) |
Got it, that sure adds some perspective.
With co-operation from a smart card / token vendor such as Yubico, Nitrokey etc, would it be feasible to develop a device that targets the OpenPGP ecosystem and relies on WebUSB in a way that just works & is not subject to race condition / conflicts, assuming WebUSB stays as it is today, or is WebUSB too limited even for that? |
Yes, WebUSB is easy and doable with vendor support. |
Arch Linux + Chrome/Chromium/Firefox |
Yes, please! |
Another user
|
Any update on this issue for hardware token? |
Unfortunately we probably won't make progress on hardware tokens this year. We're offering a mostly free product to end users, but when choosing roadmap, paying customers with larger deployments have a priority, and they will keep us quite busy with requests this year (which don't include hw token support). When we can catch our breath again and have time to do community work, I'd very much like to look into this. (Also, if a sizeable customer shows up who needs hw token support, then this could justify hiring additional developer to address this) There's also https://github.com/Nitrokey/nitrokey-webcrypt which we promised to support with a financial bounty as well as with dev effort, because they want to come up with a solution that talks to browser directly, without a local agent that user has to install. But it seems it will take some time before they have a workable solution. |
A user was wondering around when we're likely to start working on this
ref: https://mail.google.com/mail/u/human@flowcrypt.com/#inbox/FMfcgzGkZQKtzbnBHHCXwHwbdCVngvkC |
I know we won't be able to get to it in the next 12 months for sure. We won't know until we put it on the roadmap, which we haven't done yet. It could be 2 years but it could also be more. |
I recognize it might not be the easiest to implement, but lack of support for hardware keys is a massive limitation for a browser-based encryption platform. This needs priority, else FlowCrypt is essentially useless to anyone concerned about hardware-level attacks. I don't have the most experience in TS, but I'd be happy to help speed up implementation if given some direction :). Whoever's reading this, whenever you're reading it, have a good one!! |
Hello - you can see if you want to get involved in https://github.com/Nitrokey/nitrokey-webcrypt which is our preferred way to address this issue, once ready. |
If you got here looking for hardware token integration, please leave your email at: https://flowcrypt.com/docs/technical/security.html#hardware-tokens so that we can let you know when it's ready. Larger enterprises, please email us directly at
human@flowcrypt.com
. Anyone else, feel free to also leave a comment below.API needed for:
The text was updated successfully, but these errors were encountered: