Best practices for secure network transmissions

1
votes

I am building a secured messaging app for android mostly as a learning experience. The app will allow encrypted communication between one or more people, where the server will never be able to see the message content in plain text.

Below is an example of my protocol, I would like opinions on if it is suitable or a terrible way of doing it, as I am only learning cryptography best practices.

Below we have client A and B, A wishes to communicate with B privately

  1. A & B handshake with server when they come online
  2. Server sends A & B its RSA public key (RSA 2048 bit updated regularly)
  3. Clients A & B generate a key pair each, encrypt their public keys and send to server
  4. Client A packs the message, recipient(B), its public key, meta data and a hash of the servers publickey + this packet
  5. Client encrypts all of this using servers public key and sends to server
  6. Server decrypts, reads recipient address, checks hash, then re encrypts the packet with B's public key and sends
  7. B decrypts message

I'm not sure if this is secure, the reason for double encryption is to make it harder for MITM attacks to get A or B's public key so they could falsely send messages or intercept anything of value.

Any opinions as to a better way of doing it, or suggested improvements?

2
androidsecurityencryptioncryptography
The problem here is that the server still can intercept the messages, since it's "man in the middle" for the key distribution, it can just pass fake keys both ways (ie pass off its own key as A's key to B and as B's key to A) and decrypt/encrypt all messages. The clients will never know. - Joachim Isaksson
Key management is very subtle and tricky. In fact there's no solution to this "chicken and egg" type problem. This blog post discusses it: blogs.msdn.com/b/ericlippert/archive/2011/09/27/… - ntoskrnl
Best practice is to use SSL/TLS instead of shipping your own. (Unless you really know what you're doing) There are lots and lots of tricky details. From replay or reordering attacks to padding oracles. And the big issue is always how to distribute the keys. - CodesInChaos

2 Answers

1
votes

I would strongly recommend you using a well known, developed and widely used architecture like HTTPS and avoid recreating it by yourself.

One could implement that with self-signed certificates or buy one for the insurance.

Update: A link to very good reading about why you should avoid writing cryptography that already has been written and well tested: Showcasing bad cryptography.

0
votes

There are some points that raise my eyebrow:

  • Using public/private keys for a communication is not very efficient.The usual scheme for secured communication is:

    • Use asymmetric protocol to agree on a symmetric key
    • Use symmetric protocol to protect following communication

  • Why do you want to encrypt public keys ? There is no point as they are "public".

  • What is the point of updating regularly the Sever public (and private) key ?
  • I struggle to understand what is done in 4. : could you develop it ?

Also, as @blue said, and it is the 1st commandment in crypto:

Do NOT implement crypto-system by yourself

There is no harm of doing it for learning but if you want to do something really secure you want to use well-tried protocols and libraries: https, open ssl, ...