Hacker News new | past | comments | ask | show | jobs | submit login
[flagged] Keybase iOS Has a Backdoor? (sneak.berlin)
154 points by sneak on Sept 29, 2019 | hide | past | favorite | 52 comments



Official response here - I work for Keybase.

This article isn't just misleading; it's entirely false, and the title is both highly damaging AND false. Someone below threw out the word "libel" here. I don't know about that, but it's incredibly frustrating to read this title on HN right now.

* THERE IS NO BACKDOOR HERE. Neither the especially scary kind suggested by the title (everyone assumes encryption breaking!), nor the coerced attestation kind suggested in the text.

* Put simply, KEYBASE HAS NOT BACKDOORED its apps and cannot coerce them into signing someone else's Stellar address into a profile.

Further, THIS USER VOLUNTARILY GENERATED A STELLAR PRIVATE KEY. What follows is the flow for generating a Stellar wallet and attaching it to one's profile. The author of this post went through this flow on Feb 4, 2019:

1. Visited the "wallet" tab in the app

2. read a brief description of Stellar in a modal.

3. Saw our disclaimer in a modal (not hidden - printed out front) about how scary cryptocurrency is, how it's permanently attached to your identity, and how it's important to backup your private key if you plan on leaving Keybase.

4. Only once they accepted that, then their client app (not our server) generated a Stellar private key. The app signed the public Stellar address into his sig chain. And the Stellar private key counter-signed, proving bidirectionally. The stellar key was then encrypted in a way so their devices could gossip them to each other.

So to be clear (1) this writer did in fact have that Stellar Key. And (2) we, Keybase, did not. And (3) they knew they were doing it. I encourage anyone curious to go try it out -- the flow has not changed.

I don't understand what their agenda is here. Offering some charity, perhaps they went through this flow late at night and forgot. (Looks like they generated their Stellar account well after midnight in Europe.) But the claims in the post are just false.

I accept some people don't like the opinionated cryptocurrency partnership Keybase has formed. We do like Stellar. However, that doesn't change our security story. Nor does it force users to set up Stellar keys, and something like half of our users have not. Actually - we spent a great effort building around the fact that many users wouldn't be interested in the cryptocurrency side of things.

For those who generate Stellar keys and then change their mind, not wanting them, we'll add the feature to delete all of them.

Anyway, this is just not true. All of it.


Reading the article, I took sympathy with the Keybase team. As a dev working at a relatively large software company, I commonly see the smallest issues causing users to knee-jerk and claim conspiracy to harm them. Of course, this headline is shocking, and many probably upvoted it without reading the article, or having any context into your software.

Is there any precedent to getting posts like this (blatant lies) removed from HN? I will report the post, but this article has the potential to be highly damaging to your business, even if it has zero truth to it.


The post appears to have been flagged and is no longer visible on the front page.

Honestly I don’t know if it’s better to hide it so it doesn’t do more damage, or to change the title so people who already saw it can see it’s false.

I actually can’t ever recall a story on HN that was so highly upvoted and damaging yet unsubstantiated. What a crappy situation.


This appears to be legit. I got the email about free Lumens, but I don't have a Stellar key signed by my private key. Granted, I haven't signed into my account from any of Keybase's mobile apps, but it seems unlikely that they would backdoor _only_ the mobile apps.


THERE IS NO BACKDOOR HERE. Neither the especially scary kind suggested by the title (everyone assumes encryption breaking!), nor the coerced attestation kind suggested in the text.

I agree with this. It is very sensational & I was expecting something totally different when I clicked on it then what I found.

I think a moderator should change this title.

This is done without any user interaction or consent, violating the fundamental principle of Keybase’s product until now: the user controls their keys.

I am confussed by this. Pre- stellar accounts have to opt in to a wallet... and after you get one you can easily find the private key in the settings.


Random user here, I can confirm, at least for the desktop app. I had to explicitly agree to create a wallet.

I checked a few friends' profiles. I knew one of them hadn't set up a wallet and hey, you know what? Their profile doesn't include a Stellar address.


The people complaining need to review a glossary before they start complaining. Maybe also becoming knowledgeable about the subject matter might help.


> Someone below threw out the word "libel" here.

Where? Your comment, and now this reply, are the only occurrences of that word on this page.

It's really irksome when someone tells me I consent to something that I don't. I'm the authority on whether or not my keys were used improperly—no one else.

You used my keys in a way in which I did not want. That's the beginning and the end of it.

I hope you got paid a lot for it.

Here are dozens of other users who made it all the way to GitHub and provided feedback in an effort to resolve the same issue:

https://github.com/keybase/client/issues/15555

How many others just gave up?


Those users appear to acknowledge that there was consent sort before the key was generated.

> I created a stellar wallet to explore the feature


Creating a wallet (generating a keypair offline) and signing+publishing an attestation using a non-wallet keybase key to publicly associate that wallet on your profile are two different things. Adding cryptocurrency support is fine; using my private keys without my consent to publish an implicit endorsement of that cryptocurrency is not, especially when it can't be removed. It's a dark pattern that enables paid advertising designed to look like an endorsement/user engagement.

Furthermore, there is a way to remove/revoke every other type of attestation/claim on a keybase profile - except for the permanent, paid ad for Stellar.

See: https://github.com/keybase/client/issues/20022#issuecomment-...

It sounds like that part is being fixed, though, which is good.


> So to be clear (1) this writer did in fact have that Stellar Key. And (2) we, Keybase, did not. And (3) they knew they were doing it. I encourage anyone curious to go try it out -- the flow has not changed.

1) I have never seen the private key you claim I "in fact have".

2) I have no way of verifying this information, but I will accept your words on their face.

3) I did not. Your own description of the UX flow says nothing of using the keybase (not Stellar) device key to sign an attestation/proof. That was the unwanted bit, the use of my keybase (again, not Stellar) key to publicly state that I wish to use Stellar.

I'll make a screencap video of the flow if necessary to illustrate how sketchy it is.


The Stellar private key is easy to find in the wallet settings on all of the clients.

Also, I made a test account from scratch to test out the UX flow. Here's what I found (Note, this is the Android version, not iOS).

1) I created a new username and entered the new account on mobile client.

2) I created a password so I could log into the web client.

3) Out of curiosity I went ahead and clicked the wallet tab in the burger menu.

4) I'm then presented with a brief (full screen) 'Welcome' message and have to click a button that says 'Open Your Wallet' to continue.

5) once that button is clicked you are presented with a more lengthy, full screen, disclaimer that takes a minute to read.

Here is what point #3 says 3. CRYPTOCURRENCY ISN'T REALLY ANONYMOUS. When you sign your first of "default" Stellar address into your signature chain on Keybase, you are announcing it publicly as a known address for you. Assume that all of your transactions from that account are public. You can have as many Stellar accounts as you like in Keybase, but whenever you make one your default, that one is then announced as your. Consider that data permanent.

6) I then clicked 'Not now' button. Instead of 'Yes, I agree' button.

7) I log into my web client to see how my new account looks, and in fact, there is no Stellar wallet or address.

Seems to me like you have to explicitly opt into creating a wallet, and the disclaimer is very clear about signing it into your signature chain and announcing it publicly.

So unless the iOS client does not have the same disclaimer and wording, which would surprise me, I'm still not understanding what the problem is. The developer also said they are working on the feature totally remove your default Stellar wallet, so I imagine in the near future you can delete it.


Hold on, I'm confused.

This isn't allowing anyone to arbitrarily add any Stellar key to somebody else's profile or anything, is it? (And thus redirect actual money?)

It's just generating a new Stellar profile/key for each Keybase user automatically, and affirming that it belongs to each Keybase user?

Hardly seems like a backdoor, just a mildly annoying/unwanted marketing partnership. Actually not even partnership -- since Stellar is now funding Keybase, just cross-product promotion? [1]

[1] https://keybase.io/blog/keybase-stellar


The affirmation part is the problem. Generating trustworthy signatures is a critical part of a cryptographic system.

Signing something requires access to the user's private key. If that key can be used by other entities to produce signatures, it is no longer private and can no longer be trusted.


Edit: My comment took at face value the OP's claim that the Stellar account was generated without their knowledge. Obviously, if that claim is false, as Keybase's official response indicates, then my comment is invalid.

Original comment: It does seem more than a bit questionable that the Stellar account is added automatically to the user's profile among a list where every other account/key/whatever in that list was manually added by the user. (As pointed out by the OP)


> affirming that it belongs to each Keybase user

Falsely/fraudulently affirming, using a cryptographic signature silently and non-consensually generated, yes. Those keys it claims are mine are not; I have no knowledge of them. The claim is incorrect, unlike each and every other item on my profile page, which I explicitly signed.

This is the same concept of a backdoor as when a messaging app signs a wiretap key without the user's consent or knowledge. The same thing has happened here.

It's one thing to get "their username on GitHub is 'x'" wrong. It's another thing entirely to say "you can send real, actual money to this person at AN ADDRESS THAT BELONGS TO THEM, 'x'", when I have no knowledge of the keys for that payment destination and no desire to receive such payments; it is blatantly fraudulent that their software has used my private keys to sign and publish such a statement.

Would you tolerate an email client that silently changed your checking account or routing number on an outbound email before PGP signing it?


So basically:

- You can send a message to anyone with the iOS Keybase client, asking it to sign a message saying that a certain XLM address is theirs

- Your client will happily and automatically do so and add it to your Keybase profile page, no interaction needed

I base this summary on the statements "Keybase updated their iOS client to sign an attestation, as a user, that a given stellar address belongs to them, even if it does not. This is done without any user interaction" and "There is no option to remove this payment address from my Keybase profile". Did I get that right? It seems kinda weird, but given the partnership, I guess this is the way to roll that out quickly.

So the point of Keybase is tying profiles together, like HN and GitHub account, Powerdraincurrency addresses, PGP key, etc., all with cryptographic proofs. It would be pretty weird indeed if any of the Keybase clients chose to cryptographically sign a proof for a random GitHub account upon being asked to do so, no matter whether is really is your GitHub account. I can see why the author calls this a backdoor.

But what everyone expected to read is a way for Keybase to read your messages (Keybase chat) or your files (Keybase filesystem) or something. This is not the case in any way, as far as I can tell. The "backdoor" headline is somewhat clickbaity (the owner of Keybase would probably consider it slander though it's not a good PR move to actually say that), even if I see what the author means.


No, I think it's saying that your client only does this at the request of the keybase server to create an initial XLM address for the user, not that it will on-demand add random stellar addresses to the user's profile.

EDIT: See malgorithms's comment; it doesn't even do this much


Gotta say, I didn’t expect Keybase to do this after they announced their partnership back in 2018[0]

Automatically attesting keys with no user consent? Not good. This implies you are happy and willing to add arbitrary attestations to a users profile. For now you presumably have a rationale. But this is a can of worms I don’t think should have been opened.

[0] https://keybase.io/blog/keybase-stellar


> Automatically attesting keys with no user consent? Not good.

Yeah. That's why Keybase doesn't. The app tells you exactly what you're doing, and requires you to confirm you want to do it. It even has a scary warning about cryptocurrencies.


Looking at the issues is interesting: https://github.com/keybase/client/search?l=Go&p=1&q=xlm&type... and https://github.com/keybase/keybase-issues/issues?utf8=%E2%9C... - apparently running a crypto airdrop is still a way to get user numbers up...


This is clickbait. The author is using a version of the term backdoor, as in an action in a cryptographic system is undertaken on behalf of a user but without that users consent, but is clearly just irate at being associated with a cryptocurrency. This is an idempotent single action, less scary, even in a secure context.

The author clearly was just momentarily angry, used some exaggerated language knowing how it would read and is now trying to stand their ground.

Closest thing to a point I see them making is that generated wallets should include an option to be removed from the attestation list, or be deleted if not wanted to begin with.

Valid (if not slightly petty) user feedback maybe, "BACKDOOR IN SECURE APP ALERT ALERT" definitely not...


Keybase has a built in business model that they don't want to take advantage of for some unknown reason.

They made a combo of services that are a "more private" business dropbox, slack and git hosting, which are all business that charge money. I don't understand why they don't charge money for it? Is it because all of their implementations are currently slow and they don't want to be subject to the SLAs that businesses demand? That seems somewhat bizarre since they are solvable problems.

Hell I would like to like to pay them money for the service, in exchange for defined storage quotas (which expand in response to paying more $$$) and better performance but I can't.


I too would pay even just for more storage, and an ability to manage E2E encrypted emails through them. @keybase.io / .com(?) emails would be awesome, especially if it could cross-contact a protonmail email (anyone able to send emails to protonmail accounts outside of protonmail, encrypted and decrypt the responses yet? never looked into this).


> anyone able to send emails to protonmail accounts outside of protonmail, encrypted and decrypt the responses yet? never looked into this

Yes. It's dead simple. Get your protonmail keys here [0], and on the contacts page, click the cog next to the user's email address to import public keys.

[0] https://mail.protonmail.com/keys


My vague recollection is that I had to agree before Keybase would add a Stellar key to my account. Now it's certainly possible that they've changed things since then to do it automatically, but if so, you should be able to find the code for it as all of the apps are open source: https://github.com/keybase/client

Are you sure you didn't just accidentally agree to it without realizing it?


I am aware of the things to which I consent. This is not one of them.



Well, that’s one way to kill your credibility quickly. Even if it was innocent, they should have anticipated that someone would have found this and inferred otherwise, and preemptively disclosed it.

This is public key encryption software, not a toy. Don’t act confused when your users pick everything apart.


It's not a backdoor. Read the post, decide for yourself how you feel about it, but don't go off the headline.


Signing an attestation without user consent is certainly a huge breach of Keybase’s trust, but describing this as a “backdoor” feels inaccurate.


The point is that if keybase can sign the attestation on your behalf, they can further more sign other things on your behalf claiming it's you hence the reason he calls it a backdoor.


https://keybase.io/blog/2014-10-08/the-horror-of-a-secure-go...

Keybase uses the term "backdoor" in their blog to describe an app using a key to sign another key as valid (violating user intent/consent).


That is not how they use the term at all.

> A “golden key” is just another, more pleasant, word for a backdoor—something that allows people access to your data without going through you directly.

Clearly in this situation nothing has been done to allow anyone else to access your data without consent.

I get that you are upset about being made to look like you endorse a cryptocurrency, but that's not an excuse to be purposely misleading. You should edit the post and remove the backdoor claim.


They signed an attestation, that is essentially using your authority to say something is yours. I would consider my ability to consent as something that belongs to me. This change indeed allows people to access my data (in this case, saying I have something I don't, and using my authority without permission).

If they automatically joined my keybase user to my hackernews profile without my consent, it would be just as egregious.


You actually do have the key in question though, so they did not claim that you have something you don't.

Furthermore the change did not give them more access than they had previously like you are subtly implying here. The app could already make attestations on behalf of the user since that is what it's designed to do.

> If they automatically joined my keybase user to my hackernews profile without my consent, it would be just as egregious.

Egregious, maybe, but also not a backdoor.


Your post would benefit from this information.


Updated.


Oh bs, it’s associating a new XLM address with your profile, and giving you free money. They gave everyone $20 USD worth. When PayPal started they gave away $5...


Not sure how the author defines a backdoor, but my definition does not include the addition of a payment feature, even if you don't want to use it.

The "article" reads like a rant from a user who is upset, that a free app now includes a cryptocoin partnership...


It's a bit more than "the addition of a payment feature", given the general promise and working principle of Keybase.

A large part of the value proposition has been "combining identities, users can sign attestation and if you see one you know and can validate that the user proved this as part of their identity". I can see how someone would label a mechanism that causes the app to make such a claim without the user being part of it a a backdoor. (EDIT: per their comment, keybase claims that the user always has to agree to sign up for a wallet, so it'd just be about publicly linking it)


The user is upset about the lack of user consent, which is a red flag in any open-source software.


But he apparently did consent, and just doesn't remember doing so.


Not every keybase user has a stellar attestation. When it happened to me I think I had to take some action. I don't remember the exact language. Anyone have that detail?


I think you’re right. If I remember correctly I did not have a stellar address until I clicked the ‘Wallet’ button in the Keybase app. That action and the device it was issued from was recorded in my chainlink on Feb 15, 2019 .. which sounds about right.

I also remember feeling a bit tricked, because I wasn’t aware that by clicking that button a stellar address would be created and permanently linked to me.


I recently got my XLM drop. Had to click to accept too. Also felt a bit tricked. Like when randos slide into my Keybase messages


How exactly is signing a transaction on a user's behalf a backdoor? Headline seems extremely clickbaity.

At worst it's sketchy. For me as a user I don't even really care. Should they have asked for explicit consent? Yeah I guess...


keybase uses private/pub key. if keybase can use your private key to sign on your behalf, then maybe they can use that same private key to read private documents, transfer money, etc. no one but the user should ever have or know about the private key.


They write the software so they can likely do whatever they want with your key, even if it's only decrypted client-side. At the end of the day I still trust them which is necessary with all software, especially closed-source software.


I closed my account.


I am _extremely_ disappointed by this news.

I would have been _much much_ happier to hear "we are not charging $5 (or $30 or $60 or whatever) per year for keybase users" than "we're going to make claims that you've signed or agreed to attestations which you do not know about and would never have consented to".

I've just update my keybase bio to say:

I'M NOT SURE I TRUST KEYBASE ANY MORE - THEY ARE REPORTEDLY SIGNING ATTESTATIONS FROM ME WITHOUT NOTIFICATION OR CONSENT. TAKE APPROPRIATE CARE WITH ANYTHING THEY"VE CLAIMED I'VE SIGNED


Not sure if you're still following, but Keybase replied and this entire article was blatantly false. There's an explicit opt-in here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: