WO2000046952A1

WO2000046952A1 - Method for sending secure email via standard browser

Info

Publication number: WO2000046952A1
Application number: PCT/US2000/002865
Authority: WO
Inventors: John A. Burns; Gregg A. Bennett; Scott A. Phillips; Sam D. Hartman
Original assignee: Fundsxpress, Inc.
Priority date: 1999-02-05
Filing date: 2000-02-03
Publication date: 2000-08-10
Also published as: AU2755400A

Abstract

A method for securely sending email between a sender (16) and a receiver over a public communications network (20) using a standard browser. The sender of the message first opens a standard web browser (30) and points it to a web site operated by an intermediary party (32). Then, the message sender enters a secure communication session with the intermediary party and logs into the intermediary party's web site with a valid access ID and password pair (34). After successful log in, the sender composes and submits a confidential email (50) to the intermediary party's web site (52). The intermediary party then encrypts the email with a public key belonging to the receiver and signs the email with its own private key. Next, the intermediary party sends the encrypted email to the receiver. The receiver is then able to access the email using an encrypted password.

Description

METHOD FOR SENDING SECURE EMAIL VIA STANDARD BROWSER

TECHNICAL FIELD

This invention relates to a method for sending secure email using a standard Internet browser, and more particularly to a method for sending confidential email between a business and its customers via an intermediary party or data center.

BACKGROUND OF THE INVENTION The need for secure communication over a public communications network, such as the Internet, has been apparent due to the possibility that confidential information transmitted over the network may be intercepted by others. The need has increased as a result of the rise in popularity of use of the Internet by individuals and businesses alike. To address this problem, various encryption techniques have been devised to try and protect the information sent over the network. The most popular method for encrypting confidential messages sent over the Internet has been public key cryptography. This method is well known in the art, and one popular example currently in use is PGP (Pretty Good Privacy) encryption. PGP encryption uses a public key/private key pair to enable secure communication over the Internet between two parties who know the other's key.

Unfortunately, current methods of public key cryptography are complex and are therefore ill suited for use by a large number of users such as the many customers of a business. The installation of encryption software add-ins to normal email programs such as Eudora™, Netscape™, or Microsoft Outlook™ is a relatively complex process. Added to the software installation process is the time and skill needed to issue and install private keys and public keys. Once the encryption system is in place, its maintenance is also unwieldy. Each sending party must know the recipient's public key in order to receive a secure communication. Updating and maintaining public key data is difficult because oftentimes customers may have two or three different keys: one for work, one for home, and possibly one for other family members. So a business may be required to store multiple keys for each customer in order to send encrypted email directly to its customer base. In spite of these difficulties, however, the need for secure communications between many businesses and their customers is still required for transmission of confidential information. For example, customers want the ability to communicate securely with their financial institutions regarding their financial information, but customers may not have the software or the capability to send secure email communications to the financial institution on their own. Furthermore, many industries are becoming subject to regulations addressing the sending of confidential customer information over the Internet. The FDIC and other federal regulators have requested that financial institutions not communicate over open email channels with their customers because of the possibility that the confidentiality of these transactions cannot be protected. There is concern among regulators that the information being passed over normal email channels is capable of being intercepted by hackers who could target a financial institution and try to monitor the institution's email. The present invention solves these problems by permitting companies to securely communicate with others, such as their customers, using a standard web browser without requiring the customers to install, use and understand cumbersome encryption software.

SUMMARY OF THE INVENTION The present invention provides a method for sending email between a sender and a receiver over a public communications network using a standard browser. The sender of the message first opens a standard web browser and points it to a web site operated by an intermediary party. Then, the message sender enters a secure communication session with the intermediary party and logs into the intermediary party's web site with a valid access ID and password pair. After successful log in, the sender composes and submits a confidential email to the intermediary party's web site. At this point, the intermediary party takes over processing of the message. The intermediary party encrypts the email with a public key belonging to the receiver and signs the email with its own private key. Next, the intermediary party sends the encrypted email to the receiver. The receiver is then able to access the email using an encryption password.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the major components in the present system for sending secure email via a standard browser. FIGS. 2 A and 2B are flowcharts depicting the steps for sending secure email using a standard browser over the system shown in FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

As illustrated in Fig. 1, the system 10 of the present invention uses an intermediary data center 12 and a data storage device 14, such as a database to permit customers 16 of a participating business 18, such as a financial institution, who have been authorized to communicate with the business 18 securely over the Internet 20 to log into an Internet web site maintained by the intermediary 12. After successfully logging in to the web site using, for example, an access ID and password, the customer 16 enters into a Secure Socket Layer ("SSL") encrypted session from which the customer 16 can upload confidential files or send confidential messages to the business 18 via the intermediary 12. The intermediary 12 operates at least one secure server 22 that connects to the customer's personal computer or other Internet access device in a SSL encrypted session upon customer log in via the Internet 20. Once the customer 16 submits the confidential message during the session, it is stored by the secure server 22 in the database 14. The business 18 subsequently logs into the intermediary 12 via the Internet 20 through a special web site using its own access ID and password. Once successfully logged in, the session between the business 18 and the intermediary 12 is also an encrypted SSL session. At this point, an authorized representative of the business 18 is able to access and read all secure email and files that have been sent by customers 16 to that business 18.

Figures 2 A and 2B are flow charts showing the steps of the method of the present invention. Referring first to Fig. 2 A, a customer or user 16 of a business who seeks to communicate confidentially via a public communications network, such as the Internet, opens a browser such as Netscape™ or Internet Explorer™ at step 30. At step 32 the user points the browser to a web site operated by an intermediary party 12 of the user and the business, and the user 16 enters an encrypted communication session with the business. In the preferred embodiment, the user 16 enters a SSL encrypted session. At step 34 the user logs into the web site with a previously authorized access ID and password pair. Improper entry of an access ID and password prevents the user 16 from proceeding further at step 36 until a correct ID/password pair is entered. The number of times a user may attempt to enter a valid ID and password pair may be limited by the intermediary 12. Upon validation of the access ID and password, the user enters a secure session with the intermediary web site.

At step 38, the user 16 is presented with several options. The user may check to see if any messages from the business or the intermediary 12 have been received at step 40. At step 42, the user may access various services including securely sending a message at step 44 or sending a file at step 46 to the business or intermediary as email. If the user chooses to send a secure message at step 44, a web page including two fields, one for a subject and the other for message text, is presented to the user at step 48. The user completes these fields, attaches any files by specifying their location, and "sends" the email by selecting an option to do so at step 50. The user's message and any attached files are then submitted to the intermediary's web page through SSL encryption at step 52. The server 22 operated by the intermediary 12 reads the web page and stores the encrypted message in the intermediary's database 14 for processing at step 54. Processing of the message is virtually instantaneous, but in case of a backlog, there may be a slight delay in processing the message. Assuming the user only wants to send the business a confidential file, the user may do so by selecting the appropriate option at step 46. After the user has entered an access ID and password and is locked into a secure session with the intermediary's web site, the user is presented with a web page containing a field for the user to specify the location (path name) of the file to be transmitted at step 56. There may also be a location on the page to indicate the subject matter of the file being transferred. At step 58, the user specifies the file to be sent and adds a subject line if desired. The user indicates that the file is ready to be transferred at step 60. During this process, the user remains in a SSL encrypted session with the intermediary. At step 62, the file is sent through the intermediary's 12 server 22 for storage in the database until it is processed for transmission to the business 18 in a manner similar to that described for sending a message.

If the user wants to access messages sent by the intermediary 12 or business 18, the user does so by selecting the appropriate option at step 40. The user will then be notified if any new messages are waiting to be read at step 64. If there are messages waiting, the user will be presented with a list of the messages at step 66 from which the user may select none, some or all of the messages to read. Returning to the process of sending secure messages or transferring confidential files, Fig. 2B is a flow chart depicting the steps involved in processing messages or files sent by the user to the business 18 via the method of the present invention. Further processing of the messages takes advantage of known encryption technology such as PGP and the secure email infrastructure between the intermediary 12 and the business 18. During processing, at step 70 the message or file being transferred will be encrypted by the intermediary 12 with the public PGP key of business 18 and signed with the intermediary's private key. The message is then sent to the business' email address through the conventional email network in an encrypted format at step 72 where the message waits until the business logs into the web site and requests its new messages. The next time an authorized employee of the business accesses its email, a notice that mail is waiting is presented at step 74. The business representative can then access and review this email using the business' encryption password and reply to the customer via the same process at step 76 if the reply is sensitive or through the regular email system if the reply is not confidential. If the reply message is confidential, sending it will occur in an encrypted session between the business 18 and the intermediary 12. At step 78, messages or files from the business to its customers are then stored in the intermediary's database and made available to the particular customer upon the customer's next login to the intermediary's web site.

It is intended that the description of the preferred embodiment of the present invention is but one embodiment for implementing the invention. Variations in the description likely to be conceived of by those skilled in the art still fall within the breadth and scope of the disclosure of the present invention. While specific alternatives to components of the invention have been described herein, additional alternatives not specifically disclosed but known in the art are intended to fall within the scope of the invention. It is understood that other applications of the present invention will be apparent to those skilled in the art upon the reading of the preferred embodiment and a consideration of the appended claims and drawings.

Claims

We claim:

1. A method for sending email between a sender and a receiver over a public communications network using a standard browser, the method comprising: the sender opening the standard browser; pointing the browser to a web site operated by an intermediary party; entering a secure communication session with the intermediary party; logging into the intermediary party's web site with a valid access ID and password pair; and submitting a confidential email to the intermediary party's web site; the intermediary party encrypting the email with a public key belonging to the receiver; signing the email with a private key belonging to the intermediary party; and sending the encrypted email to the receiver; and the receiver accessing the email using an encryption password.

2. The method of claim 1 further comprising the receiver replying to the email.

3. The method of claim 1 wherein the encryption password is linked to the receiver's public key.

4. The method of claim 1 wherein the confidential email is a message composed by the sender.

5. The method of claim 1 wherein the confidential email includes a file designated by the sender.

6. The method of claim 1 wherein the confidential email includes a message composed by the sender and a file designated by the sender.

7. The method of claim 1 wherein the secure session is encrypted using Secure Socket Layer (SSL).

8. The method of claim 1 further comprising storing the email in a database operated by the intermediary party after submitting the email by the sender to the intermediary party

AMENDED CLAIMS

[received by the International Bureau on 19 June 2000 (19.06.00); original claim 1 amended; remaining claims unchanged (1 page)]

1. A method for sending email between a sender and a receiver over a public communications network using a standard browser, the method comprising: the sender opening the standard browser; pointing the browser to a web site operated by an intermediary party; entering a secure communication session with the intermediary party; logging into the intermediary party's web site with a valid access ID and password pair; and submitting a confidential email to the intermediary party's web site; the intermediary party encrypting the email with a public key belonging to the receiver; signing the email with a private key belonging to the intermediary party; and sending the encrypted email to the receiver; and the receiver accessing the email using an encryption password wherein all communication between the sender and receiver is transmitted through the intermediary party.

2. The method of claim 1 further comprising the receiver replying to the email.