Keybase’s browser extension subverts its encryption
palant.de
palant.de
The browser extension is not their main product and they explicitly say so. The author is completely dismissing [0] the entire product just because of a side project, which in the worst case scenario could be fixed by the community by submitting a patch.
It is also strange that the author seems to feel the need to reinforce the sensationalism of this post by linking something completely unrelated to Keybase.
Also, where are the quotes on this post coming from? Where is the rest of the communication?
There is really nothing to see here.
[0] - "Initially, I planned to take a closer look at the crypto in Keybase, to see whether I can find weaknesses in their implementation. But that’s off the table now."
[1] - "But as experience shows (https://palant.de/2018/07/11/ftapi-secutransfer-the-secure-a...), the claim “end-to-end encryption” doesn’t automatically translate into a secure implementation."
The author is completely dismissing [0] the
entire product
Fool me once, shame on you; fool me twice...
To me it reads like there's nothing preventing this bug report from deserving a bounty.
* Content spoofing / text injection
* Issues related to software or protocols not under Keybase control
* Reports of spam
* Vulnerabilities affecting users of outdated or unpatched browsers and platforms
Do I agree with their (alleged) actions? NO! But as I know several folks at Keybase personally, I’m sure there’s another side to this story and I’m willing to give them some benefit to the doubt until I hear otherwise.
I didn’t. It was a generalized statement about the bounty terms, not directed at any one person.
The extension is very much an official Keybase product and recommended heavily on their end. Why should I waste more time on a product where valid security issues are being dismissed? It isn't even so much about not being paid, as: if they don't care about such edge cases subverting their end-to-end encryption, what do they care about?
And BTW, I also don't like the option to upload private keys. I mean, no sane person would ever do that. It's not that hard to copy keys to multiple devices, if that's really necessary for your work flow. Me, if I used mobile devices, I'd use dedicated keys, because those things are so readily pwned.
> there were technical reasons why iframes didn’t work, though I forget the details
It could be that there is one or a couple of engineers at Keybase who made this decision and are also the same entity that replied to the bug bounty. It feels like they haven't thought it through properly or brought it up for proper discussion inside the organization. Let's hope that they remedy this and adjust their general approach to this if this gets enough attention.
On the other hand, even if this is addresses, unfortunately it's an indicator that other compromises in this category are done in other parts of Keybase.
Then I found out that they're not using popular and audited libraries like OpenPGPjs instead... writing their own!
But more serious and nested "secure" communication would be wiser done elsewhere.
I presume this is a typo, but if so it's a grave one.
The naming is very transparent, the intent is that we can give everybody our public keys, they're public, while our private key must remain secret.
(I like to use the U2 Lyric "A secret is something you tell one other person, so I'm telling you" to keep straight the difference between secret keys, which we must share with somebody else, and private keys, which we shouldn't share with anybody, although DH means in practice you may never need to explicitly "tell" anyone the secret keys in hybrid systems)
[Edited because I made the same dumb typo]
Of course, it goes against orthodoxy to share/upload your private key, but I'm not sure I've ever seen a good rebuttal to Filippo's post.
It seems to me though that you're reducing the entropy of your key from the 2048 bits or whatever to the entropy of your key phrase, which would normally only be some 100 or so bits (if you have a decent one) - but I'm not informed enough to judge the details. However, it seems to me that Filippo is, and he did upload his private key (encrypted) - so how bad is that, really? Anyone got some substantiated insights there?
[1] https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv...
2048-bit RSA gives you only ~112 bits of security.
For the record I don't have a private master key in any online connected devices. GnuPG works well in an air-gapped scenarios. Does Keybase client? Or does it require constant phoning home?
As best I can tell they have rolled their own mostly closed source crypto solution from day 1.
Modern cryptographic algorithims rarely get broken, but keys get stolen by malware all the time. Instead of moving the keys out of system memory and thus out of reach of malware they just add layers of obfuscation to a key that is going to be decrypted into system memory. Mixing unrelated strong ciphers is likely to yeild nothing but a false sense of security at best and yeild malleability attacks at worst.
If you take your key and encrypt it 3 times, or 200 times, it is still moot if it by design it ends up plaintext in system memory.
You don't see anyone else doing this sort of nonsense mix and match security for a reason. Their threat profile is fundimentally broken if they think attacks on modern crypto primitives are more likely than malware on an end users system.
Right, but if the social network website can modify the HTML that the Keybase extension is injecting, then surely it can also modify the iframe's URL to an attacker-controlled one? Or, for that matter, replace the event handler on the "Keybase Chat" button itself before it even gets clicked?
I'm not an extension developer, so there might be APIs available to extensions or restrictions on webpage JS that I'm not aware of, but I suspect the only secure way to do this (if you don't trust the page you're embedding in) might be to have the extension communicate with the native Keybase app, which then opens a chat window with the appropriate user, similar to how the 1Password browser extension works.
Keybase could minimize that by showing the user's name and/or logo in the iframe. Barring another vulnerability, the site shouldn't know who is logged in into the extension, so they shouldn't be able to fake that.
In general I find Keybase to be a step forward in user experience and two steps backwards in terms of actual security. They just don't seem to care about the latter at all and have not demonstrated any cooperation with standards bodies like the OpenPGP working group where members have expressed interest multiple times in adding generic URL uids to the openpgp public key itself to replicate and decentralize the idea of social media based trust bootstrapping (the one good idea from Keybase in spite of terrible execution). Instead they insist on their complex proprietary walled garden system that does not integrate with existing keyservers and throws everything on the bitcoin blockchain for reasons.
Keybase has become the IE of crypto and I can't take any security project seriously that even -integrates- with them.
For the record it soon may be possible to use native GnuPG through the browser extension:
> Installer: New optional module "Browser Integration" to register GnuPG as backend for Mailvelope 3.0.
Source: https://www.gpg4win.org/change-history.html
But given Keybase's track record I already know they're not interested in that.
Guess what, other people like me just realized that Keybase was not designed to be used like that and didn't use the smart-card together with Keybase.
I guess you can fault them for not saying that explicitly but since the made no mention of smart-cards and didn't evolve the security model in that direction it was pretty clear that that was not what they were about and therefore I did not expect it to be optimal to be used like that.
Honestly, the OpenPGP world has so competently failed at usability and is only adopted by the most hard core of nerds. Even I have stopped using it for the most part.
And that it is two steps back in security overall is just not true. Maybe in some individual features that you care about, but not in general.
And the same thing counts that always counted, crypto that nobody is using is not protecting anything.
The have mostly moved on from GPG any a different libraries now. The GPG is mostly a legacy feature.
There's only one thing that's worse. Crypto that people think is protecting them, but which isn't.
For the most part Keybase crypto is modern, effective and easy to use.
Don't you know? There's a rule that all cryptographic software must be arcane and obscure and virtually impossible to use correctly by anyone other than obsessive nerds.
Also there are projects in the OpenPGP world making very easy to use workflows and interfaces without centralizing or breaking standards. OpenKeychain for android is a fantastic example of this.
I use OpenKeychain on my phone and can sign files, access passwords, or decrypt email by tapping my yubikey to it. I can tap someone elses key to my phone to import their key to my addressbook. No terminals or fuss and at no point does any key come in contact with system memory of any device involved so I have strong assurances it can't be stolen even if my phone is totally compromised.
A big example of the 2 steps backwards of keybase: they use keys in system memory and abandoned any compatibility with the openpgp smartcard spec, yubikeys, etc. The industry is moving to smartcards for very good reason: malware is a thing and it can use/steal keys from system memory without user interaction. A key stored in a yubikey 4 OTOH never touches system memory and requires a physical touch for each operation.
You can have usability without throwing out security and standards. Keybase is just another in a long line of companies ignorantly throwing out any security features they don't understand using usability as an excuse for bad engineering.
It seems GnuPG and "the ecosystem" is slowly moving to WKD (Web Key Directory) as it is easier to deploy (e.g. kernel.org is using it).
If you put your binary key (gpg --export 36C8AAA9) at https://lrvick.net/.well-known/openpgpkey/hu/gfoh5t79df9raqt... tools would retrieve it automatically when using your e-mail address (gpg --locate-key $EMAIL). (I got the hash by running gpg -k --with-wkd 36C8AAA9).
This is supported by GnuPG, OpenKeychain and some e-mail clients: Enigmail, GpgOL (Outlook) would fetch your key in background when someone is writing an e-mail.
For details see: https://wiki.gnupg.org/WKD#Implementations
The spec: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
This seems pretty inaccurate.
* Lots of software projects sign their releases with PGP.
* Almost all Linux distributions sign their software with PGP. If you use Linux, your security relies critically PGP.
* Github has support for PGP, and I see people use it.
* My random server hoster happens to sign all their emails with PGP.
You could claim that all these systems are run "by the most hard core of nerds", but at that point the statement loses its relevance.
[0]: https://wire.com/
They are contributing to an IETF protocol (“MLS”) for E2E messaging, which is a long-term path to messenger interoperability.
Edit:
Relevant: https://tools.ietf.org/html/draft-barnes-mls-protocol-00
I remember when we had that before E2E was popularized, it was standardized, and then walled gardens broke their interoperability in the name of (claimed) better user experience and user numbers.
Is that a normal thing to do on github?
...this actually looks like a potential security weakness that was purged from the public space. (CWE-921)
http://lettergram.github.io/AnyCrypt/
https://github.com/lettergram/AnyCrypt
https://chrome.google.com/webstore/detail/anycrypt/hddfngccl....
It worked fairly well (haven't tested it in a bit), but I had to reverse engineer pretty much all the Keybase APIs at the time.
The thing is, the author is totally correct. I wrote mine as a proof of concept, and quite frankly was surprised that the Keybase chrome extension (even a year ago when I checked) had the same issue(s) my implementation did...
That being said, this isn't an "end-of-the-world" kind of thing, I think there are several easy solutions to this problem as the author pointed out. Personally though, only 3 people use my extension with me. I couldn't get anyone to use the Keybase extension.. so I really think they should just update that phrasing on their extension page (perhaps add a warning) and let it be.
I just signed up for keybase and was definitely steered towards installing the browser extension. I quickly uninstalled it because I found it annoying, though.
Keybase is fantastic.
i've been using keybase for 2 years now and have had no issue accessing my files through kbfs.
with keybase teams you can store secrets at rest and make them easy to access across your team.
the client loads 10x faster then slack and has nice ux.
How do you feel about someone else composing the message that "you" (your encryption software) are going to encrypt? Because that's what the article is talking about.
And I would think it is analogous to running kbfs on a machine with a virus or keylogger.
And one nice thing is your root key is still protected by a paper key which you can physically secure, and use to de auth any compromised device keys.
For the casual user who is just getting into keybase, social integration like this may be worth the risk in order to help onboarding new users. Once they start seeing the real benefits of using keybase, they can delete the extension and still make use of the good stuff.
Finally, keybase is open source right? They are a small team and might not have the resources to improve the extension, but just getting the first iteration out there might be enough to attract contributors who see its value and can improve its security.
I understand why Keybase principals don't want to do that, because the extension is an addon that probably doesn't do anything in particular for them as far as adoption goes. I'm not sure I understand why they continue to ship the existing extension, knowing that it's insecure.
And I don't see any excuse at all for editing the bug report on Github out of existence - that strikes me as sufficiently sketchy that I may no longer use Keybase at all, and certainly will no longer rely on it to be especially secure.
My reasoning is that you're given some encryption software (keybase javscript on its website or browser extension) but the software is changing all the time: it might get re-downloaded on a tab refresh, the extension might download a "new version" or whatever... So basically you're supposed to trust an always changing piece of code (can you be auditing every piece of javascript that you download? every version of that javascript?) and you running in a super-connected runtime (like a browser). What could possibly go wrong?
I am not an encryption expert at all, but I feel a lot safer doing my crypto on a regular environment (linux shell or whatever) and then sending the cyphertext via any other mean (web, email, whatever).
Back in the day you could use pidgin to chat on the Facebook chat, and it was possible (and relatively easy) to use the OTR plugin to have really end-to-end encrypted chats. But (guess what?) Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)
Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)
In the case of Caprine, it appears not to use any official API and is just scraping the web page for the right elements. This seems quite fragile and also a non-trivial body of code.
I wouldn't use a keybase key for anything that should be rendered eternally unbreakable, based on side-channel threat analysis alone. Private keys are not something that should be sourced from a website.