Private key transfer - Desktop client as receiver

[shirishag75]

Hi all,
As per readme, "The Android client version 3.0 is required to export your account-key which is needed by the desktop client " now it would be nice if this could be done by the desktop client itself.

[abika]

I'm still unsure about this. Kontalk is a mobile messenger network, the desktop client is (or was) only intended as an addition. The account creation could be integrated (with still a mobile phone number needed for verification) but this will be a lot of work.

Maybe its better to put some effort into improving the key transfer (strong encrypted over the server)?

[daniele-athome]

I was thinking about transferring the key someway between devices, but the problem is you'll need to authenticate first - which is not possible because you don't have the key yet.
Besides, sending a private key through network is always a bad idea, despite of any security measure you might take.

In this specific case, we'll need server assistance, in either two way:

• let the server store an encrypted copy of the private key (I'd rather not do that for obvious reasons)
• make the server arrange a p2p connection between an already registered device and the new device you're trying to pair and let them exchange the key through a secure channel (I guess plain SSL would be safe enough, I have to evalutate some other options - we might have some difficulties such as NAT traversal, but I think they can be worked around)

What do you think?

[abika]

I get your concerns but if we use a strong symmetric encryption with fixed password length (<=26 chars) shouldn't it be safe? It would be much easier to implement than a p2p approach.

we might have some difficulties such as NAT traversal, but I think they can be worked around)

I have not much experience with p2p communication but can remember that applications like Skype had big trouble to find a reliable way for connecting through all kinds of networks. A lot of work was put into this.

[daniele-athome]

You're right, it will probably be a pain...
Let's go through the encrypted exchange then. Shall we open an encrypted session?

Just kidding :-)
Ok seriously now: once the password has been determined, do we use an encrypted <message/> to exchange that?

[abika]

Eh, what exactly is your general idea? The desktop client establishes a temporary XMPP connection, and the Android client sends the key?

[daniele-athome]

I have some thoughts about that.

Android part:

• app uploads the encrypted key
• server replies with a very long identifier (we'll call it a registration token)

Desktop part:

• app connects to the same server the Android app is connected to (we'll have to make it clear in the Android app: "choose THIS server in the desktop app")
• without authenticating, it sends a special <iq/> (extension to in-band registration I guess) with the registration token which was manually typed in by the user from the phone screen
• server replies with the encrypted key which can be used to login

For the key encryption part: we could let the user choose a password, recommending him/her to make it very strong.

What do you think? It might work.

[daniele-athome]

Now that I think about it, this protocol could also be used for Android-to-Android account pairing (that is, multiple devices with the same key).

[abika]

[uhh I almost forgot about this thread again]

In general it sounds good. One improvement idea: The Android app should generate a secure password for the user (26chars, lower letters +digits), otherwise its too insecure IMO. And now: create the registration token as the sha1 hash of the password. By doing that the user has only to type in the password in the desktop app.

It sounds like introducing a weak spot in security, but its not. There is no real difference if an attacker has the password hash in addition to the encrypted key file.

[daniele-athome]

@abika the problem with this approach is that the token is client generated. That is not acceptable sorry, the token has to be generated by the server, it's too important (remember: anything that is provided by clients can and will be exploited).
We could however "compose" a long token made up of the server token and the client password and show that long string to the user. Of course it will be boring to type in manually on the other side. Unless the other device has a camera, in that case a QR code can be used. Most notebooks and tablets have one, so it will cover the majority of users. The rest will have to type in the string manually.
Any other ideas?

[shirishag75]

Hi all,
Have people seen yowsup. Yowsup-cli does a similar thing for whatsapp. You register, have to share your phone number credentials, the service sends a string to your mobile no. via a SMS and then you can put in the service to verify that's it you and you're in .

I do see the issue there that just like the web, the SMS service is also public and theoretically a MIM (man-in-middle) attack is possible but there doesn't seem to any other secure way to do it.

[daniele-athome]

@shirishag75 WhatsApp has no encryption key to exchange between devices. Everything is in cleartext.

[abika]

the problem with this approach is that the token is client generated. That is not acceptable sorry, the token has to be generated by the server, it's too important (remember: anything that is provided by clients can and will be exploited).

Guess you're right, but what exactly is the problem here? The server can check the token format and make sure it wasn't used before. How can a client exploit choosing this string?

Unless the other device has a camera, in that case a QR code can be used. Most notebooks and tablets have one, so it will cover the majority of users.

I can at least say for myself: I'm using a laptop exclusively and never used the camera in the last 10 years, don't even know if it works. Besides that: implementing camera+qr-code scan will be a pain in pure Java (in contrast to Android. Do you know one desktop application that can scan qr codes?).

But all in all: security has priority!

[ Offtopic:

WhatsApp has no encryption key to exchange between devices. Everything is in cleartext.

That's not exactly true. WhatsApp has some kind of encryption and even Axolotls e2e encryption for Android-to-Android communication. But it's closed source, nobody knows exactly. And anyway, no key transfer here.
]

[daniele-athome]

[I was replying by editing your comment. Again. Fortunately I realized that just before pressing the save button]

Guess you're right, but what exactly is the problem here? The server can check the token format and make sure it wasn't used before. How can a client exploit choosing this string?

Maybe not clients directly, but the server will have access to a hashed version of the passphrase. I don't like it. Private key related content should never go through a server (the fact that a private key, even if encrypted, goes through a server, is already dangerous per se - the passphrase is the only thing keeping it somewhat "protected", even if it's hashed).

We could, however, use some encoding (something like Base64, but more user-friendly) to merge into a single string both the server generated ID and the passphrase. The client on the other side will know how to split and use it.
However, this could let the user think that the key was not encrypted because he/she didn't have to type in the passphrase again. What do you think?

I can at least say for myself: I'm using a laptop exclusively and never used the camera in the last 10 years, don't even know if it works. Besides that: implementing camera+qr-code scan will be a pain in pure Java (in contrast to Android. Do you know one desktop application that can scan qr codes?).

That is not a priority of course. I could introduce QR code scanning on Android first and take care of the desktop app later (or never :-). As a start, you could use a library to at least generate a QR from your desktop app (e.g. you want to pair a phone/tablet with your desktop account), showing the characters too in the same screen.

[abika]

Maybe not clients directly, but the server will have access to a hashed version of the passphrase. I don't like it. Private key related content should never go through a server (the fact that a private key, even if encrypted, goes through a server, is already dangerous per se - the passphrase is the only thing keeping it somewhat "protected", even if it's hashed).

That's true, the security depends on the hash function used. If you don't want that, then we don't do that.

We could, however, use some encoding (something like Base64, but more user-friendly) to merge into a single string both the server generated ID and the passphrase. The client on the other side will know how to split and use it.
However, this could let the user think that the key was not encrypted because he/she didn't have to type in the passphrase again. What do you think?

My experience is that my don't care about that. But the Android app should generate a secure passphrase, anyway. Token & passhrase should be around 160bits, so no matter how encoded (e.g. both a 30 digit string, lower alphabetic characters + numbers for easy typing) it will be looong.

That is not a priority of course. I could introduce QR code scanning on Android first and take care of the desktop app later (or never :-). As a start, you could use a library to at least generate a QR from your desktop app (e.g. you want to pair a phone/tablet with your desktop account), showing the characters too in the same screen.

Well, in the future I can generate QR code in the desktop app, but that doesn't help here for the transfer from phone to pc.