1

I'm developing a solution for secure chat over instant messaging, here is the scenario:

I need to encrypt my message then send it on {Whatsapp, telegram, Wechat,...}, I don't trust any software above, so I use an app on my cellphone to encrypt/decrypt messages, basically it works like a translator.

However, the first idea turns to be naive, because it's really hard to ensure the cellphone itself not to be hacked, for example, the clipboard.

Therefore the current idea is, to use a dedicated cellphone to encrypt and decrypt message, and it transmit/receive messages with my cellphone (the one runs IM apps) over Bluetooth. The goal is to isolate the hardware that possibly contacts the original text, so my cellphone can only read the encrypted messages.

Is Bluetooth here a good solution?

The following picture shows the rough idea. Phone A-1 and B1 should install only the encryption apps, and stay offline for any kinds of connections except the Bluetooth connection with A-2 and B-2.

A typical message send& receive process

  • Some remarks: 1. A wireless channel is prone to interference and attacks, or eavesdropping. 2. Looks like A1 and B1 here do not have to be cell phones, what if I use a dedicated device that supports USB connections only to talk with A2 and B2? It's easy to turn IoT+screen to be such a cipher. A cellphone may not be a secure cipher due to its nature, it is designed to be easier to talk with others. – GKZDqqX Jan 9 at 13:21
3

Is Bluetooth here a good solution?

From the perspective of security it does not matter if the communication channel (Bluetooth) itself is secure since only encrypted messages are transferred anyway in your design. Attacks at the Bluetooth stack on the senders device might be possible though which can compromise the senders device - see for example the Blueborne attack. This might give the attacker access to the messages before encryption.

Additionally, a bug in your encryption application might allow an attacker to hijack your encryption application with corrupted messages and thus also get access to the plain messages. This is actually independent from the communication channel used.

As for non-security properties like reliability or bandwidth: it is possible to create a reliable protocol on top of some unreliable. And for the usual text messages send by a single person the bandwidth should be enough. Even if bandwidth is no longer sufficient (like when sending videos) you can use WiFi - the risk is about the same (i.e. also vulnerable drivers) but the bandwidth is higher.

0

Is Bluetooth here a good solution?

The use of bluetooth itself as described here does not add any additional vulnerability to your design. The purpose of message encryption is to provide confidentiality to the message irrespective of the channel through which the message is being transmitted. Other security properties though would be dependent on the way you implement the overall solution.

Having said that I disagree that the complicated architecture provides any additional security you anticipate. This also feels very much like re inventing the wheel. I will explain why in a bit.

What are the security properties you need for a secure chat?

  1. Authentication - Only verified users shall be able to send messages and no adversary shall be able to spoof an existing user.
  2. Integrity - No adversary shall be able to tamper the message while it is in transit [or storage] such that the final decrypted data at the receiver's end would not be the same as the message sent by the sender.
  3. Repudiation - There should be a cryptographically absolute way of confirming the identity of a sender even if the sender denies it.
  4. Confidentiality - No person with access to the channel [Like the IM apps in your case] should be able to retrieve the content.
  5. Availability - An adversary should not have the ability to disrupt your channel of communication.
  6. Authorization - If there are restrictions based on user type, a user by themselves should not be able to bypass those restrictions.

Here is how you solve it one by one.

  1. Authentication

In your example, there is only one authentication factor - access to the network isolated phone with your encryption client. If that device falls into another person's hand they would be able to do the exact same operations phone A-1 is authorised to do. Ideally there should be multiple factors of authentication. [Password protection of phone A-1 can be one of it]. If your client package itself is leaked somehow, one would be able to mimic phone A-1 to communicate to phone A-2. If you want end to end authentication to be possible, phone A-1 should sign the content and the signature should be verified at the phone B-1.

  1. Integrity

There are two potential man-in-the-middle opportunities in the above architecture [A-2 & B-2]. If you want to protect message integrity end to end between phone A-1 and phone B-1 there should be some sort of HMAC validation or a signature validation at the recipient side. Note that HMAC would require a shared secret between the two communicating parties. And this should be shared using a secure key exchange mechanism. Signature on the other hand requires the receiving party to be aware of the public key of the sender. A secure implementation of this might require reliance on a PKI system.

  1. Repudiation

For the recipient to be able to have non-repudiation, each message should be signed using an asymmetric cryptographic algorithm.

  1. Confidentiality

From your question it appears that confidentiality is your key concern. There are two parts to ensuring confidentiality. Defining an encryption scheme or a ciphersuite and exchanging keys securely. Encryption can be symmetric or asymmetric. If it is symmetric the key has to be exchanged between the parties. This could be achieved by either encrypting and sending the key using an asymmetric cryptographic mechanism or by using a key exchange protocol such as Diffie Hellman Key Exchange. There are numerous things to be considered while choosing any of the ciphersuites depending on the weaknesses associated with each.

  1. Availability

Your application is using an interference prone channel - bluetooth. Bluetooth jammers could be used by an attacker to limit your availability.There are multiple single point of failures in your architecture, in fact all the nodes are single point of failures.

  1. Authorization

This is a factor to consider if there are multiple privilege levels.

To summarize:

You are introducing two additional nodes to just eliminate the possibility of a potential compromise of phone A-2 and phone B-2. However this opens up other channels of potential compromise - phone A-1 itself and the channel between phone A-1 and phone A-2.

However, the first idea turns to be naive, because it's really hard to ensure the cellphone itself not to be hacked, for example, the clipboard.

The same stands true for phone A-1. Adding that extra node does not provide any exceptional security other than reducing the attack surface of delivering payloads. If the intend was to limit access to clipboard you can use methods like this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.