0

I don't have any kind of experience in security, but just on API and app development, and I'm developing an application for doctors and patients which has an added private messaging feature between doctor:patient.

I also should be able to retrieve messages exchanged in case of legal issues between doctor:patient, basically a man-in-the-middle.

I invested the day studying XMPP, OTR, etc and I decided I'll use a simple POST REST endpoint to post messages, using sockets, instead of XMPP, et. all.

I read that even consumer chatting apps use OTR for end-to-end encryption, but isn't HTTPS enough? I understand the concept of end-to-end encryption, but both doctor and patient will be connected via HTTPS to the server, isn't that enough? Isn't that already a kind of end-to-end encryption?

So is there any benefit on using HTTPS AND OTR?

Is there another secure but easier to implement option and/or technique other than OTR? (compatible with iOS, Android, Windows Phone, Web).

EDIT: OTR has "Deniability: After the chat session is finished, messages cannot be identified as originating from either your correspondent or you." - but in this case the messages have to be identified, specially for liability issues on face of the doctor decisions/instructions/etc.

Willian Schneider
  • 3
  • 2
  • Shouldn't the doctor-patient conversation be confidential? Isn't there a problem with recording all of it without any anonymity? – Beat Nov 30 '15 at 22:22
  • Yes, totally confidential, but we are still coming to a legal agreement that in case of extreme legal issues we should be able to retrieve messages to handle for authorities. So in this case they have to be stored with extreme encryption, that only a few selected persons may have access to retrieve and decrypt. – Willian Schneider Nov 30 '15 at 22:41
  • @Beat - Perhaps you're confusing doctor-patient privacy with anonymity? In nearly all situations, medical professionals should know who they are speaking with and patients are happy with that. – Neil Smithline Nov 30 '15 at 23:03

2 Answers2

1

OTR messages are encrypted end-to-end. This means that the clear-text of OTR messages cannot be accessed by an intermediary such as a server. This is useful to prevent messaging companies, governments, and any other MiTM from snooping on your conversation.

If you are looking to implement your own messaging system using a REST API that records the data that is being messaged, OTR is not what you want as the server will not be able to access the clear-text of the messages for logging. HTTPS will provide you with sufficient on-the-wire security.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • But if it can't be acessed by an intermediary, what about [mod_otr](https://github.com/webiest/mod_otr)? _This module, once loaded, will do the "man in the middle" at the server level In other word, it will decrypt messages, so the server administrator can read them._ – Willian Schneider Dec 01 '15 at 00:39
  • 1
    @WillianSchneider - `mod_otr` works by breaking end-to-end encryption. User A only encrypts messages to the server where they are decrypted, logged, and then encrypted to be sent to User B. It relies on users not using validating who they are encrypting messages to. From `mod_otr`'s readme `they will never verify their fingerprint`. – Neil Smithline Dec 01 '15 at 01:01
0

The definition of end to end encryption is that only the parties that are part of the communication can read the message, while the infrastructure that supports the communication can't. HTTPS encrypts between the client and the server, but it does not encrypt between the patient and doctor. In other words, it's not an end to end encryption in the conventional sense of the word.

Whether this is enough depends on your threat model and any regulatory requirements that applies to you (e.g. HIPPA).

I also should be able to retrieve messages exchanged in case of legal issues between doctor:patient, basically a man-in-the-middle.

Since you only need to decrypt messages between doctors and patients when there is a dispute, then you can be sure that at least one party is going to cooperate with you. One way you can implement this with encryption is to encrypt a data encryption key with key encryption key and use secret splitting (e.g. Shamir's Secret Sharing) to split the key encryption key three ways (patient, doctor, and you). The communicating parties then discloses the data encryption key to you in an encrypted form and one share of the key encryption key and you record the encrypted messages. In this scheme, you cannot decrypt the data encryption key and the message, unless one party has agreed to disclose their share of the secret to you. This preserves doctor-patient confidentiality while allowing you to check the decrypt the message that has been deliberately disclosed to you.

A simpler solution, if you're fine with having a single person/trusted party that can decrypt the entire world; is to have the messages encrypted with an asymmetric intercept key. Both sides have to encrypt all their messages to the intercept key, and the person controlling the intercept key has to keep his private key private. The patient and doctor knows the public key part of the intercept key, so they can encrypt the message so that the intercept key can decrypt it.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • Never heard of Shamir's Secret Sharing before, your described solution is exactly what I was looking for! Thank you. – Willian Schneider Dec 01 '15 at 00:38
  • Saw your edit about the asymmetric intercept key, I like that approach better, since it provides a way for a central person to access it at anytime, while keeping it secure as I was looking for. – Willian Schneider Dec 01 '15 at 00:45
  • @WillianSchneider: a subtlety that you need to consider with the intercept key is that you need to make sure that the message sender can't just give you one message while sending to the receiver a totally different message. Both the sender and receiver had to independently encrypt to the public key and with the same parameters (timestamp, salt) so that you can compare the ciphertext. If the cipher text matches, then you know that the plain text that the patient and doctor sees are the same, without decrypting the message. This way you can keep the intercept key offline. – Lie Ryan Dec 01 '15 at 00:55
  • Another possibility is if you require that the receiver of a message hash the message packet and send the hash to you, so you can compare that the receiver is receiving the same message as you. But this won't prevent the sender to just not encrypt to the intercept key at all. – Lie Ryan Dec 01 '15 at 01:04