The simple answer is that it is very secure, and here is why:

Firstly, some core design and implementation principles we used to build Secure Cloud Messenger (SCM) The system MUST use Australian Government approved cryptography with at least a SECRET content rating as per the Australian Government Information Security Manual (ISM) All sensitive data at rest MUST be encrypted with AES-256 or higher

  • All sensitive data in transit SHOULD be encrypted with TLS 1.2 or higher
  • All data hashing MUST use SHA-256 or higher
  • Each registered Company using SCM has their own set of cryptography keys
  • All Company cryptography keys are re-issued monthly
  • Each recipient has their own individually encrypted copy of each message
  • Access to a decrypted message is ONLY possible via a unique URL sent to a recipient (the link itself contains essential information for the decryption process)
  • Supplying the recipient’s email address is a MANDATORY requirement for the decryption process
  • The system NEVER logs a recipient’s email address against a message
  • Preemptive is unable to decrypt any message without the explicit help of the customer
  • All customer data belongs to the customer
  • SCM MUST use cryptographically strong random numbers

With these principals in mind, below is a simplified overview of how SCM message processing works.

Receiving an email into SCM, and sending out link URLs emails to recipients:

  • All incoming email should transfer using TLS 1.2
  • The system uses the X-Secure-Preemptive header of an incoming email to identify the sending Company. If that information is missing the email is silently dropped.
  • The system locates and readies the Company’s current cryptography key
  • For each recipient, a message-recipient key is created in memory, which consists of the Company’s current cipher + raw message bytes + a random value + recipient’s email address.
  • This unique message-recipient key is used to encrypt a unique copy of the message for each recipient.
  • The unique URL in the email sent to the message recipients contains encrypted access information for each recipient’s personal copy of the message. It is impossible to retrieve an email without this link

Retrieving a message from link email sent to a recipient:

  • You can only retrieve a message with a valid link URL
  • SCM needs the email address of link message’s intended recipient to decode the link
  • Optionally, the message sender may require the recipient to authenticate with SCM with two-factor authentication
  • All interaction between the message recipient and SCM is conducted over secure HTTP (https) and is fully encrypted with TLS 1.2
  • Once decrypted, the message is displayed to the recipient

Amazon’s Aurora relational database service in the Sydney, Australia data center hosts SCM’s metadata. All sensitive data in that system is either encrypted or hashed and is meaningless to a third-party observer.

Let’s take a look:

Here is an example of the data we store for 10 messages

Moreover, for each of those messages here is the link letter information stored for each recipient

As you can see, this information is meaningless to any observer, but essential to the encryption/decryption process.

As previously mentioned, information in the link message sent to a recipient (something they have) and their email address, which may require authentication (something they know), are essential to the decryption process.

SCM stores the content of each message as an AES-256 encrypted Internet Message object (RFC5322) within Amazon’s S3 Cloud Storage. At the time of writing this is in the Sydney, Australia data center.  SCM also uses Amazon’s Elastic Compute Cloud (EC2) in the same location to host the service.

We hope this overview has given you an insight into how seriously we take the security and integrity of your data. We have taken great care when constructing SCM to create a system that can be provably trusted. We welcome questions on its design and would appreciate the opportunity to answer them. Please feel free to use our forum at http://preemptive.freshdesk.com or write to us directly at [email protected]