Browse Prior Art Database

Secure Messaging and Local Logging Store (SMALLS) for implementing a Corporate Common Public Key Encryption and email Logging /Journaling Architecture

IP.com Disclosure Number: IPCOM000031032D
Original Publication Date: 2004-Sep-07
Included in the Prior Art Database: 2004-Sep-07
Document File: 3 page(s) / 64K

Publishing Venue

IBM

Abstract

An architectural design to intercept and securely store both plain text and fully encrypted email in a readable form without requiring any modification to either Client code or Mail Server code, nor storing multiple private keys.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 3

Secure Messaging and Local Logging Store (SMALLS) for implementing a Corporate Common Public Key Encryption and email Logging /Journaling Architecture

Disclosed is an architecture to allow encrypted email to be intercepted and stored in plain text transparently to the user without modification to the Client User software or the central mail server software.

The Problem:
1) Large corporates in the financial sector are being mandated by their Audit and Security officers, the SEC and the Sarbanes-Oxley Act to keep local copies of all email sent and received.
2) Large corporates in the financial sector are being mandated by their Audit and Security officers to use encrypted email for all communications.

    The problem is that the above 2 requirements are actually mutually exclusive: Once an email has been encrypted using the recipients Public Key, (obtained from an LDAP server), although the contents of the email can subsequently be intercepted and successfully stored; without the corresponding Private Key it will not be possible to actually read the contents of the email.

    Encrypting email at the server rather than the client, technically breaches 2) above because it leaves all email being routed around the corporate Intranet as totally unencrypted and easy to monitor with basic network tools until it is encrypted at the mail server.

    It would also not be at all reasonable to expect an email recipient who is external to the Corporation to provide their private key, even for audit purposes.

The Architectural Summary:

    A secure centrally held mail storage database with a secure centrally maintained Directory Service to act as "middle-man" in all Public Key exchanges.

    A copy of all mail received and all mail sent will be captured and saved in a central mail "logging" database.

    The central Directory Service will manage the "spoofing" of the Public Keys internally and externally whilst being the ONLY holder of the Corporate Private Key.

    Users will have their own Private Key held locally to decrypt all received mail (which was re-encrypted by the Central Directory Service after storing the email)

    Where an email arrives encrypted, it will still be possible to store AND decrypt the mail, because of Corporate "spoofing" of all Public Keys in either direction.

    Thus it is possible to both receive and send email fully encrypted client to client at all times, and yet still be able to securely capture or "log" all emails sent or received, in either an encrypted form (with secure but available Private key to de-crypt them) or in an unencrypted form.

The Architectural Solution: Out Bound Mail from within the Financial Corporate:

    The client will look-up each recipients public key for all intended recipients of the email and present any exceptions back to the user for the users decision (ie if any intended recipient does not have a Public Key, the whole email to all recipients will not be sent until the user has chosen their preferred action, this is the stan...