Patent Application
20080187140
Electronic mail or “email” has become one of the main methods of communication within our society. Negotiations, deals, and confidential business communication all occur over the internet Likewise, with the advances in email and the increased frequency of email use, the dangers of using email have become more prevalent. Fraudsters and other security threats can intercept email and use it for their personal gain. Confidential information can be intercepted and published on the web by hackers or fraudsters. Because of the increased number of threats and higher risk associated with online communication, there is a need for a method that increases the security of email and assures users that their emails are being transmitted and received without interruption or compromise.
One main approach that is used to secure emails is to encrypt the message along with any attachments according to a pre-approved encryption scheme. In this approach, requires both the sender and the recipient to have the same encryption mechanism and same encryption method. Securing the email can be done using Public Key Infrastructure (PKI) based digital certificate to encrypt the email, but the current use of this method requires that the email sender have the recipient's public key certificate installed on his or her computer prior to the encryption. The email is then encrypted using the recipient's public key which is in the recipient's public key certificate. Hence, known methods required an already available digital certificate prior to any encryption.
Therefore, there is a need for an encryption mechanism that can be used without a prior agreement between the parties. There is a need to send secure messages prior to the recipient receiving the message and without both parties having to communicate and work together to establish a pre-approved encryption scheme.
The disclosed invention allows users to send and receive secured and encrypted emails even if an email certificate has not been installed by the intended recipient prior to the email's encryption. The invention works by generating a public and private key pair with the public key being placed into a self-signed public key certificate. The private key is used to encrypt the message and the then encrypted message is then sent to the recipient. The private key or key pair is then sent to a server using a secure connection. Upon receipt of the encrypted email, the recipient connects to the server and requests the private key. The server validates the recipient and sends the private key to the recipient. The recipient then decrypts the email. Optionally, the decrypted email replaces the encrypted email to keep the recipient's inbox clean. The above scheme can also be applied to a symmetric shared-secret which replaces the public key, private key and digital certificate. Otherwise, the process is the same.
During the validation of the recipient, the server can obtain the recipient's “real” email certificate for validation purposes. The applicant's “real” email certificate is an email certificate issued by a trusted third party such as a Certificate Authority. “Real” email certificates are typically, although not necessarily, verified during the issuance process to ensure the validity of the data contained therein. In terms of email certificates, the verification can include a) sending an email to the email address associated with the email certificate, or b) having a system administrator verify the email address on the user's behalf. The server or recipient's computer can then send the real email certificate to the email sender for future use.
In an alternate embodiment, the encrypted email is sent to a server (or to the recipient who then forwards the encrypted email to the server). The server generates a notification email about the existence of the encrypted email. The notification email is sent to the recipient with a web link to the server. The recipient then browses to the server where they are authenticated. After they are authenticated, the server uses the private key to decrypt the encrypted email. The email is then displayed in the recipient's browser for them to read.
In another alternate embodiment, the encrypted email is sent to a mail server. The mail server downloads the key from the server and decrypts the encrypted email for the recipient.
A password can also be required before allowing the recipient to read the email. Other authentication methods can also be used, i.e. finger print scanner, a digital certificate, or any other authentication scheme.
An image of the sender or some other identified can be sent to the recipient through the non-encrypted email, the email generated by the server, or with the notification link to help the recipient know that the email and source can be trusted.
The disclosed invention is a process of sending and receiving encrypted electronic mail (“email”) to a party for whom an e-mail certificate (also referred to as a “public key digital certificate” or “digital certificate” or “certificate” herein) is not already know, present, or installed on the sender's computer. The disclosed invention ensures that the receiver can decrypt the message after it is received and provides for validation of the recipient's identity. The preferred embodiment of the invention only allows the receiver to decrypt the message if certain set criteria are met, such as signing up for and correct installing and configuring an e-mail certificate.
The term SE module as used herein refers to all forms of code or software that can be used to accomplish the tasks set forth, including software plug-ins or extensions, data from other network stack monitoring and interception code, a stand-alone email application, a separate application, a separate mail server of mail appliance, or any other device where the method can be implemented either in a plurality of devices (such as multiple plug-ins), a combination of devices (network code in addition to a plug-in), or a single device.
In Step 104, the SE module 6 residing on either the mail server or the sender's computer intercepts the email being sent 4 and determines whether a public key is already known for the intended recipient 16. Generally, the SE module 6 will check in the windows certificate store for the applicable digital certificate, but the SE module 6 could also access other certificate databases from proprietary and/or third party databases or even remote locations as well. The SE module 6 can be initiated upon the user's pressing the “send” button on their email application, by the email server upon receipt of the email or upon the email being forwarded from the email server, by having the user select to initiate the SE module, or any other method that might be used to initiate a software plug-in, application, or routine or a stand alone application, appliance, or device where all connections to the application are encrypted.
If a key pair is not available, then, in Step 106, the SE module 6 generates a private and public key pair 8. The public key is placed into a certificate which is self-signed using the private key rather than root-signed and include the sender's email address as the certificate's subject. After being generated, the public key certificate is placed in a certificate storage area accessible to the sender's computer.
In Step 108, the SE module 6 generates a unique MessageID (MID) 10, which may occur at substantially the same time as the generation of key pair 8. The MID 10 is a hash (typically 20-bytes) used to identify the generated key pair. The MID 10 can created using certain selected informational details about the email being sent 4, can be a set of random data, or can be a combination of both random and email specific data. Information used to generate the MID can include, but is not limited to, a hash of the receiver's email address, the recipient's email address, the system time, and a sequence id. The sequence ID can be an incremental counter used to “salt” the MID. The counter is not required to be persistent and need not be sequential. However, a sequential count is useful as it can be incremented after generating each MID and can start over once the highest value in the sequence is reached. An incremental counter prevents the possible confusion that could occur if two mails from being sent at the same system time (which would result in a non-unique MID).
In Step 110, the email 4 is encrypted with the session private key, and signed with the sender's e-mail certificate, to the S/MIME standard as defined in RFC3850 and 3851.
In Step 112, the now signed and encrypted email 12 is included in a new non-encrypted email 14 that is generated by the SE module. The new non-encrypted email 14 generated by the SE module 6 can be in any email format. The encrypted email 12 can be included in the new non-encrypted email 14 using any standard form of inclusion, including attaching it to the email or embedding the encrypted message into the new unencrypted message. The MID 10 is included with the new non-encrypted email 14, usually as part of the message's header.
The new non-encrypted email 14 can be blank or can include a human-readable message detailing the steps that need to be taken in order to decrypt the attached encrypted message. The message in the non-encrypted email 14 is typically generated by the SE module 6. Optionally, the new message 14 can be customized by the email sender 2 prior to being sent on to the recipient 16. Additionally, the non-encrypted email can include an image of the sender or some other identifying mark to assist the recipient in identifying and trusting the email sender. The image file can be embedded in the email using any standard embedding techniques.
In Step 114, the new unencrypted email 14, along with the encrypted original email 12, is sent to the selected recipient 16 via standard email transmission routines. The new email should, but does not have to be, signed by the sender's email certificate prior to being sent to the recipient in order to ensure the integrity of the e-mail. The certificate is transmitted along with the signed and encrypted original email.
In Step 116, (which may actually occur prior to Step 110, 112, or 114), the sender's computer connects to a server 20 using an encrypted connection, in the preferred embroilment of the invention this is facilitated using SSL. During the connection, the SSL certificate from the server is examined to ensure that it is a valid and correct domain. After the connection is established, the SE module 6 sends the private key or key pair 8 to the server 20. For security reasons, the transferred information can be packaged together into the PKCS #12: Personal Information Exchange Syntax Standard format. The MID 10 is transmitted at the same time, typically as the password for the PKCS #12. The private key or PKCS #12 is then stored on the server 20 in any known manner.
In Step 118, the recipient 16 receives the non-encrypted email 14 and encrypted attachment 12. The recipient 16 follows the instructions contained in the non-encrypted email 14 in order to decrypt the encrypted attachment 12. In order to decrypt the message, the recipient 16 will be instructed to download the SE module 22 (or a separate SE module used for decrypting encrypted emails).
In Step 120, the SE module on the recipient's computer or network 22 establishes a secure connection to the server 20 where the recipient 16 is authenticated for his or her identity using standard PKI authentication routines. If a certificate does not exist for the user and the recipient has not obtained a certificate elsewhere, the certificate for authentication can be created directly from the SE module 22. The SE module 22 can also use a certificate already assigned to the recipient. Because a secure encrypted connection is being made with the server 20, the recipient's real public key certificate is supplied by the SE module to the server during the client authentication process. One process of the SSL client authentication handshake forces the recipient's computer to perform a private key operation. The private key operation (which can be an encryption or decryption operation) cryptographically proves the recipient's identity, via ownership of the private key corresponding to the public key in the e-mail certificate, to the server and verifies that the recipient is the intended recipient of the message. The server's authentication process also checks the email address in the recipient's email certificate against the e-mail address the original e-mail was sent to by the sender to ensure that they are the same. The server's authentication process checks the email address in the recipient's email certificate against a known trusted root to confirm that the recipient is the intended recipient of the email. The server authenticates the recipient by proving ownership of the private key associated with the supplied public key certificate through requesting proof a successful private key encryption or decryption. The authentication ensures that unauthorized parties are not provided access to the session private key and prevents unauthorized decryption of the message as it protects the session private key from potential email thieves. At this point, the public key of the recipient's real email certificate, or the e-mail certificate itself can be provided to the server which can then distribute the recipient's real key to other email senders so that future email communications will be encrypted using a typical email encryption scheme. Of course the certificate could also be transmitted to other parties through a signed email or in any other manner.
At the same time the recipient's connection to the server 20 occurs, or later if desired, the SE module gathers the recipient's email certificate 26. The SE module then sends the email certificate 26 to the original email sender 2 by creating a new message and signing it with the recipients real e-mail certificate. The signed mail is then transmitted over the e-mail system back to the sender. The original email sender's SE module intercepts the email from the recipient 16 and the recipient's email certificate 26 is extracted and installed on the sender's computer.
Once the encrypted connection is established and the recipient sufficiently validated, the SE module 22 requests the private key or key pair 8 from the server 20 using the MID 10 found in the unencrypted email's 14 message header. The MID 10 is transmitted to the server 20 as well
In Step 122, the server 20 responds to the request by transferring the previously uploaded PKCS #12 to the recipient 16 over the established secure connection The recipient's SE module 16 may then use the private key to decrypt the encrypted email 4 into a format that is readable 24.
Optionally, the encrypted version of the message 12 and/or the unencrypted email 14 can be deleted and replaced with a decrypted version 24 of the same message in order to avoid having duplicate emails in the recipient's mail box.
Optionally, the entire system can be performed with a symmetric key system, which replaces the public and private key and certificate where the e-mail is encrypted with the symmetric key; the symmetric key is uploaded to the server and stored; the recipient is authenticated; the symmetric key is downloaded by the SE module; the e-mail is then decrypted. Using a symmetric key system eliminates the need for the public and private key to be generated and used.
In an alternate embodiment of the invention shown in
In another alternative similar to the one shown in
In another embodiment that is also illustrated by
The invention is not restricted to the details of the foregoing embodiment and the example provided are only one of many possible ways in which the invention as claimed can be accomplished. The order of the steps presented above is not the only order in which the steps may be taken. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.
This application claims the benefit of provisional application Ser. No. 60/888,589, filed Feb. 7, 2007, which is incorporated entirely herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60888589 | Feb 2007 | US |
