Codel Email
Codel has developed two demonstration email applications that prove despatch, receipt and integrity of email. Messages are encrypted with a key that is lodged with Codel and they can only be read when the key is downloaded from Codel who keep a record of this transaction - thereby proving despatch and receipt. Codel can also be easily integrated into existing messaging software so if you would like to try Codel's plug-in for Outlook 2003 or would like to integrate Codel into your messaging software please contact us here. Contact
Strong Revocation for Email
This is a novel protocol designed by Codel to address the issue of undetected abuse of or access to protected systems particularly for email. In short, the idea is that every time the protected system is used to communicate with another party, a 3rd party intervenes to seek confirmation that the user accepts responsibility for, and confirms the validity of, the immediately preceding transaction.
For example, if we are using the protocol to protect credit cards, Codel would send back an anonymous token which it has retained from the previous transaction. The user's Codel software would use the token to retrieve details of that transaction and present that information to the user for validation. If the token is not recognised, or if the user does not recognise the details they are being presented with, then the unauthorised abuse or access has been identified and the user can take the appropriate steps.
What this means is that no transaction earlier in the audit trail can subsequently be revoked unless the user is prepared to (and can, presumably, justify) revoke an entire series of transactions. This builds incremental trust into the audit trail.
Email Validation- Quick Guide
The Point:
To make it possible to prove - to the satisfaction of a Court - that either an email was sent or received by named individuals at or before a given date.
The Method:
- Message between Sender and Recipient cannot be read without a Key which the Sender only gives to Codel and the Recipient can only get from Codel. These transactions are captured to Codel's protected Audit Trail.
- The software used to create or retrieve these keys is uniquely branded so that we know exactly which software is being used and thus who is sending or receiving the email.
- We also require both sender and recipient to verify the previous transaction for which the software was used.
How it Proves an Email:
- The Recipient Request for the Codel Key is made by submitting the fingerprint of a first Key Codel never sees. But it matches the fingerprint the Sender gives to Codel. So Codel is witness to the sharing of the first key.
- The first key is only sent by the sender once the recipient proves they've received the encrypted message. So the Sender can prove the recipient must have received the message.
- Codel, therefore, does not directly prove the transmission of the original message, but as it can prove the sharing of the first key, it is "witness" to the agreement between sender and recipient that the original message must have been sent and received.
- Forcing the recipient to retrieve the final key from Codel allows us to play this witness role and to log the time and date of the transaction we're involved in. This fixes the earliest time and date at which the original encrypted message can be opened and read.
- The requirement to verify previous transactions deals with the problem of identity theft. This check speeds up the detection of compromised communications and, if no compromise is detected, it builds up increased confidence in the transaction trail and the identity of the person creating those transactions.
Previous page: Codel Bible
Next page: Codel E-Wills