2nd Key sent to Codel
The point of sending the second Key to Codel is that we can record the transaction and all relevant details (who and when) on our protected audit trail. Which means, in the event of dispute, either side can provide their half of the evidence and, in conjunction with the Codel data, prove, beyond reasonable doubt, that a particular email was sent from, or received by a particular person at a particular time and date.
If available to relevant parties, Codel can use Public Key Cryptography to help establish the identity of the communicating parties. PK is not that widely spread, however, and Codel is not limited to that means of authentication. Each copy of the Codel Email Software comes with its own unique identifiers and requires its own local authentication (passwords, smart cards etc). Hence, provided that Codel is itself trusted in the same way as a Root Certification Authority (or is certified by one) it is as reliable and meaningful an indicator of human identity as is the possession of a Private Key.
However, we recognise the limitations of either digital signatures or our own alternative when used to identify named individuals and, as a result, insist on using a Strong Revocation Protocol to minimise the risk of undetected abuse or access to either the Private Key or the Codel Software.
The Recipient, who now has both the ciphertext and the encrypted key to it in their possession, needs the second key in order to be able to use the first key and read the message. They obtain the second key from Codel by sending us the hash of the first key. The Sender included a copy of that with the second key, so that we would recognise the Recipient as legitimate.
The hand-over of the second Key takes a few seconds and must be conducted in a real-time online session. This allows the Codel software to mediate the session from the Recipient's end. It does this using a Volatile session key which it sends to Codel for us to use to encrypt the second key. The volatile key is only usable during that online session and if the session is interrupted, or the system crashes, the volatile key will disappear and the 2nd key (if it arrived before the interruption) will remain unreadable. A new online session will have to take place with a new volatile key.
If no problems occur during the final hand-over, the net result is this:
|
Codel can prove: that the Sender sent a 2nd Key and a first key whose hash matches its copy. that the recipient held a copy of the first key and that the recipient received the second key and can now read the message. the times and dates the above took place The sender can prove that the recipient has the original ciphertext (by virtue of the hash sent in request for the first key) The recipient can prove (with Codel's help) that what they have received must have come from the sender (by virtue of Codel's receipt of the second key and hash of first key from the sender) |
All the Codel transactions are time-stamped and stored in the protected audit trail.
Either side can, with Codel's help, now prove to a court that the disputed transmission took place and was readable from the time of the hand over of the second key.
