Implementation Options with RMail Encryption – TLS, PKI, 256-Bit AES PDF?

December 14, 2010 / in Blog, Encryption/Security / by Zafar Khan, RPost CEO

With RMail service, the sender can opt to send encrypted messages by Message-Level Encryption, Transport Layer Encryption, or a combination. As such, there are four scenarios for encrypted transmission.  In all cases, the encrypted message is delivered direct to the recipient’s desktop; RMail never requires the recipient to visit a website to collect their email.

Encrypted Data Flow Path A Path B
1. Desktop-to-Desktop Message-Level Encryption Message-Level Encryption
2. Desktop-to-Server Message-Level Encryption Transport Layer Encryption
3. Server-to-Desktop Transport Layer Encryption Message-Level Encryption
4. Server-to-Server Transport Layer Encryption Transport Layer Encryption

A. IMPLEMENTATION OPTIONS FOR PATH A: SENDER TO PROVIDER

A sender using RMail’s Outlook plug-in has two administrative settings that we will discuss here.  Once set by the sender or sender IT department, they are transparent from a user perspective. When sending Registered Email™ messages with the encryption option selected, the message will either:

    1. Message Level Encrypt. This is done locally at sender’s desktop (invisible to sender) using an embedded RMail digital certificate for PKI encryption. The sender does not need their own digital certificate.
    2. Transport Layer Encrypt. This is done by transmitting, relying on TLS transmission encryption. Here, the sender would need assurance that they were transmitting to RMail using TLS encryption.

B. IMPLEMENTATION OPTIONS FOR PATH B: SENDER TO PROVIDER

RPost will deliver the sender’s message encrypted, using one of the following techniques as selected by the sender in their administrative settings:

    1. Message Level Encrypt. This is done using 256-bit PDF encryption salted with a unique decryption code. The email body text is converted to PDF and encrypted with the attachments embedded in the PDF in their native format.  The receiver receives a Registered Email™ message with the encrypted message attached in PDF format.
    2. Transport Layer Encrypt. If the sender has selected this option, RMail tests to determine if the receiver server supports and will accept at that moment a secure connection for TLS encrypted transmission. If it can, RMail delivers the message via the encrypted connection to the recipient server and the message displays in the recipient’s inbox in a standard email message form with markings on it so the sender knows that it had been transmitted encrypted and contains sensitive or protected information.

C. AUDITABLE PROOF OF ENCRYPTED DELVIERY

It is important to note that will all options, the sender does receive verifiable and auditable proof of compliance with regulated (HIPAA, FSA, GLB, FDCPA, etc.) encrypted delivery requirements – a patented capability unique to RPost service. These options discussed can be sent by individual senders or sender’s IT departments, in most cases.

Consider the Council of Insurance Agents and Brokers (CIAB) top level evaluation criteria in their recommendations.

When considering data breach, we are considering two points, a data breach when the data is (a) within the sender’s control (i.e. where the email is sent from sender to recipient – “security of sender-controlled data”); and (b) after the data leaves the sender’s control (i.e. if there is a data breach on the recipient’s system or after the recipient forwards the information on to others – “downstream data breach”).

 In reference to protection from downstream data breach, CIAB cites as the most important criteria, as having “Auditable proof of compliance”.

CIAB goes on to state, “It seems that only RMail has a robust mechanism in place to provide an auditable record of precisely what message content (body text and attachments) was in fact sent and received in an encrypted manner to each intended recipient.  This is important because, in the case where there is a data breach after the email has reached the recipient (in the recipient’s environment, or after they have passed the information along to others), the sender will need to retain information to prove that the breach did not happen “on their watch” – that they in fact complied with the data security requirements and delivered the information in a compliant, encrypted manner. 

 RMail addresses this issue by having built its encrypted email service on top of its core Registered Email™ service, which The Council of Insurance Agents and Brokers endorsed in 2004 as the best way to prove email content, time, and delivery with court-admissible records.  By doing this, RMail provides not only effective encryption, but also the most robust proof and record of compliance with the rules of regulators.