12

I'm creating a small web game using three.js, and I'd like to add voice chat functionality to it. Currently, the audio information is converted into base64 client-side and then sent to the server from where it's sent out to all other clients.

I have pretty much no knowledge or experience when it comes to information security, so I'd like to know if audio data like this counts as sensitive information and should be encrypted/obscured in some way before sending it.

Improve this question
8
  • 4
    “Does this count as sensitive information?” This is entirely subjective and a matter of opinion. If it’s already over HTTPS then it’s already encrypted. But yes, as a general rule of thumb, audio content should be encrypted. Of course also keep in mind that encrypting then decrypting data server-side slows things down.
    – security_paranoid
    Commented Oct 6 at 6:02
  • 6
    If its over HTTPS then its already encrypted.
    – CaffeineAddiction
    Commented Oct 6 at 6:19
  • 15
    HTTPS will encrypt the payload while in transit between the client and the server. With HTTPS, both the client and the server will see the plaintext payload, but anyone in between will only see the encrypted payload. If you don't want the server to have access to the plaintext payload, then you need to encrypt the payload at the client, using an encryption key that is unknown to the server.
    – mti2935
    Commented Oct 6 at 11:18
  • 23
    side note: Why are you converting to base64? HTTP(S) can transport arbitrary binary data. All you get from converting to base64 is 33% more data to transport.
    – Sören
    Commented Oct 6 at 17:52
  • 5
    @Sören I smell a simple JSON/REST-like backend. Maybe websockets at best. Either would require base64. I also suspect that this approach will have latency issues.
    – Vilx-
    Commented Oct 6 at 19:56

3 Answers 3

Reset to default
11

It depends on who you're trying to defend from.

If the audio is going to be broadcast to "all other clients", there might not be a reason to encrypt it when it's on the server. However, if there are separate lobbies where only a small group of friends would chat, then it might be worth it.

In the modern age, you would almost certainly be using HTTPS (there are certain features you won't be able to use otherwise). HTTPS will ensure that anybody listening on the wire between the player and your server cannot see the contents.

What's stopping a random player from listening in to all the conversations? If the answer is "nothing" -- i.e. all the players are in the same voice chat -- then there's not much to be gained from encryption: you use encryption to limit the range of people who have access to some information, and if "everyone" is supposed to have access, then there's no need to do it.

However, if there are separate lobbies, such that all players within one lobby can talk to each other but not between lobbies -- then encryption should be used to make sure that even if someone pwns your server (and can record everything that's sent to it), they wouldn't be able to record the voice chat. This is called "end-to-end encryption": the message is encrypted by the sender, and it doesn't get decrypted to plaintext until it reaches the receiver.

You would need to figure out a way for the different clients to agree on a shared secret, while the server (which we do not trust to not leak data) doesn't know what it is. A very popular protocol is Diffie-Hellman key exchange: this allows two people to generate a shared secret, while communicating over an insecure channel (this video explains how it works). Since you might want more than two people in a lobby, you would need to perform this across multiple parties: this Crypto.SE post has some ideas for how to do it.

Improve this answer
6
  • 3
    diffe-hellman alone works in the presense of passive evesdropping, but a "man in the middle" can just seperately agree secrets with both parties. There are ways to mitigate this using digital signatures but ultimately if your server is responsible for the key management then it is likely in a position to MITM the communication.
    – Peter Green
    Commented Oct 7 at 20:53
  • @PeterGreen You could try to notice that by showing users a hash of their shared secret and having them read it to each other, possibly making it so that you have to correctly pick the data on the other person's side or your client hangs up. I know that Telegram voice chats have 4 emojis shown to all parties to the call, and you can optionally ask the other person to confirm them.
    – Danya02
    Commented Oct 7 at 21:11
  • @Danya02 Yeah, that (and the basic idea of this answer) is totally impractical. Imagine a group of young friends having to confirm each other keys each time before playing a match... You threat model is wrong here. If somebody can pwn OP's server, they already won. Listening to real-time chats is the least of the problems (they could probable deploy malware disguised as a forced update, or just steal the user credential at login). Adding this complexity to the user experience is totally unjustified, especially considering that it's just a game.
    – Margaret Bloom
    Commented Oct 8 at 14:51
  • @MargaretBloom That's a valid criticism. My main idea was "you probably don't want to do this, but if you would, here's how". Re UX complexity, it depends on how you present it: in my script kiddie days I would've really enjoyed a game that showcases some of the cryptography it's using, so it could work if that's the kind of audience you've got.
    – Danya02
    Commented Oct 8 at 17:08
  • 1
    Diffie Hellman is the key exchange for Off-the-record (OTR) protocol. Throwing this out there since this protocol as a concept has not been mentioned anywhere in the post and knowing about it may lead to discovering existing tools and concepts that otherwise might seem informally related.
    – Anthony
    Commented Oct 9 at 15:26
9

I'd like to know if audio data like this counts as sensitive information

Whether or not it "counts" is a mostly matter of opinion. But, since you presumably have no control over what your users say, then presumably they may say things that would reasonably be considered "sensitive."

and should be encrypted/obscured in some way before sending it.

That would probably be a good idea.

As one commenter has mentioned, if the data is sent over HTTPS, then it is encrypted from client to server. However, it is not encrypted on your server. You should probably learn some basics about how TLS works (TLS is effectively the "S" in "HTTPS") and what TLS protects. The upshot is that it protects data in transit from the clients to your server, but not on your server.

Improve this answer
1

Encrypt everything what you can.

For a communication you may use existing tools like WebRTC that allows to make live audio calls. It tries to establish a direct connection or fallback to TURN server if both peers are behind NAT. The WebRTC already has an encryption built-in. It also supports Data Channels that may be used for a plain chat.

As an alternative you may use XMPP over WebSockets or HTTP Long Pooling (BOSH). You may find ready to use libraries (strophe.js lib, Converse.js web app) and servers (Openfire, Prosody).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .