|
All messages are encrypted for
the intended recipient and further encrypted for the
SafeMessage server. In this way the SafeMessage server can
decrypt the header element of the message and thereby notify
the recipient of the message waiting.
Since the body text and
attachments of the message are encrypted solely for the
recipient, messages stored at the server cannot be accessed
by any one other than the intended recipient.
Compliance
To meet internal and external
compliance requirements (e.g. FSA, Sarbannes-Oxley and other
legislative purposes), SafeMessage can optionally copy, and
separately encrypt, every message to a Compliance Server,
which will allow suitably authorised staff to access any
message.
In Detail
When a message is sent using
SafeMessage, the client application creates a very long set
of asymmetrical encryption keys. The client then requests
the servers public key and sends its own public key back to
the server. This key request is the only unencrypted
operation, but does use an associated authorisation key.
The SafeMessage then creates
an envelope request which validates and authorizes the
users, looks up the public keys for those users and creates
a Unique ID for the message.
The message is then compressed
and encrypted for the ultimate recipient. It is then
re-encrypted using the key for the server and then sent. The
recipient then can retrieve the message from the server and
de-crypt it using their private key, which is held only by
that recipient.
SafeMessage is
exceptionally secure, far more so than comparable products.
The result is that accounts must be authorised and created
separately from the transmission of the messages.
In this way the
authentication offered by SafeMessage is woven through-out
the entire message cycle, and therefore not only more secure
but far harder to circumvent than other similar systems. No
session-based system can come close to the full security of
SafeMessage. |
