JP2002535884A - Distribution of web-based secure email messages - Google Patents

Abstract

(57) [Abstract] Electronic document distribution that does not require a special public key security software application pre-installed on the recipient's computer, enables the exchange of digitally signed and public key encrypted packages. system. A URL identifying such a package is sent by e-mail to the recipient. Based on the deposit of the URL through the World Wide Web, computer instructions, eg, in the form of an applet, are sent to the recipient to retrieve and process the package. Such processing includes decrypting one or more parts of the package and verifying the signature of the package.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001] The present invention relates generally to the secure distribution of data files over a computer network, and in particular, to the encryption technology in such a way that the data files can be decrypted and their signatures verified. To distribute encrypted and / or signed data files.

(Background Art) Since e-mail (e-mail) has become a widely used and widely used communication format, the security of such e-mail has become an important issue. An important development in secure email communication is S / MIME (Secure Multipurpose Internet Mail Extension). S / MIME is designed by RSA Data Security and other software companies to provide message integrity, authentication, non-repudiation, and privacy to electronic message exchanges through digital signatures and encryption.

In S / MIME, the content and structure of the S / MIME message depend on MIME (Multipurpose Internet Mail Extension), and the encryption functionality depends on PKCS (Public Key Encryption Standard). Known ITU-TX. 509 standard, i.e. X.509. 509 certificates are used to identify communicating parties.

There are currently three versions of the S / MIME standard. The most popular is the second edition. The third edition of S / MIME became standard in July 1999 and introduced a number of enhancements to S / MIME. S / MIME 3rd edition also introduces a new cryptographic message syntax rule, which is the PKCS # 7 used in S / MIME 2nd edition.
This is an extension and replacement of v1.5.

[0005] Further information on S / MIME and RSA Data Security can be found at R
It can be obtained from the website of SA Data Security (http://www.rsa.com). The current status of S / MIME standardization and other S / MIME-related documents are available on the IMC (Internet Mail Consortium) website (ht
tp: //www.imc.org) and the IETF S / MIME Working Group website (ht)
tp: //www.imc.org/ietf-smime, http://www.ietf.org/html.charters/smime-cha
rter.html).

[0006] The S / MIME second edition standard is published in two RFC documents. S / MIME Second Edition Message Specification (RFC2311) S / MIME Second Edition Certificate Handling (RFC2312) S / MIME Third Edition is currently being defined in the following set of Internet Draft Documents: -Cryptographic message syntax rule (draft-ietf-sme-cms)-S / MIME third edition message specification (draft-ietf-smime)
-Msg)-S / MIME 3rd edition certificate handling (draft-ietf-smime)
-Cert)-Certificate request syntax rule (draft-ietf-sime-crs)-S / MIME security enhancement service (draft-ietf-ietf-)
ess) Signature certificate attribute specification (draft-ietf-smeme-sigatt)
r)-Certificate distribution specification (draft-ietf-smeme-certdist)
)-Diffie-Hellman key exchange method (draft-ietf-smeme-x)
942)-Domain security service using S / MIME (draft-iet)
f-smime-domsec) These documents are available from many other websites, such as the websites listed above or the RFC Editor website.

[0007] Current approaches to exchanging S / MIME messages require the preparation of an S / MIME file according to the S / MIME specification and the transmission of the S / MIME file as an e-mail message attachment. . When the message reaches the recipient, the recipient is expected to have an S / MIME-capable email reader to process the message. Alternatively, the recipient can use a standalone S / MIME processing helper application to process the message.

There are many obstacles to successful S / MIME message exchange using the above scheme. First, the recipient simply does not have S / MIME capabilities and the S / MIME is unavailable and simply remains stored in the recipient's computer without further processing. May be. There are many cases that lead to such situations. The e-mail reading program selected by the recipient may be a simple e-mail reader or an older version and may not have the ability to properly authenticate and decrypt S / MIME formatted messages. In other cases, the recipient's email reader may rely on plug-in functions or helper programs that are not built into the recipient's computer. In any case, the message in S / MIME format is completely unreadable to the recipient, and the recipient probably cannot understand why this particular email message cannot be read without extra communication with the sender. Will.

[0009] The S / MIME message exchange generally requires that both the sender and the recipient know the necessary infrastructure for public key cryptography, the public key infrastructure (PKI).
Such infrastructure includes the public / private key pair required for encryption, decryption, and signing, as well as the certificates required for authentication. The recipient is generally unaware of such a public key infrastructure, especially S / MIME. However, in order to receive an encrypted secure email, the recipient must have a digital certificate containing the recipient's public key. If the recipient has a certificate, some knowledge of the owner's public key infrastructure will be assumed. However, in the case of a signed message, neither the recipient's public key nor the secret key is required, and thus no such assumption is made regarding the recipient's knowledge of the public key infrastructure.

A second obstacle to successful message distribution and processing in the S / MIME format is inter-version incompatibility. Even though the recipient's email reader has a certain level of S / MIME capability, S / MIME processing may fail due to S / MIME differences implemented by different suppliers. S / MIME is an evolving standard, with three different versions currently in use. If the sender uses an S / MIME program that implements a version later than the version implemented by the recipient's email program, the recipient's email reader will accurately decrypt the message and verify the signature. It will be impossible. As in the case described above, the message may simply appear unreadable and the recipient may not be able to determine the course of action necessary to correct the situation.

A common solution to such a problem is to have recipients upgrade or obtain their email reader or helper application and properly implement the latest standardized version of the S / MIME protocol. Incorporating additional software into a computer system, even simply upgrading existing applications, can adversely affect the computer system by occupying system resources. Therefore, the recipient is the new S / MIM
You may choose not to incorporate E software. In addition, appropriate S / M
IME software may not be available in the recipient's computing environment.
Even if the recipient chooses to upgrade or obtain the S / MIME software, such incorporation can take a significant amount of time, and the recipient can read the message significantly later.

[0012] S / MIME email messages have another disadvantage. The S / MIME message is forwarded as an Internet e-mail attachment. Some Internet email gateways limit the size of the message and consequently the size of such attachments. Therefore, the S / MIME message may be shortened. If the message is shortened, the portion of data required to correctly decrypt the message and verify the signature is lost, rendering the message useless.

What is needed is an email that can be sent to a recipient using a standardized and widely supported secure email protocol, and the recipient's email reader implements the secure email protocol correctly. It is a mechanism that allows the recipient to receive the email despite the failure.

DISCLOSURE OF THE INVENTION According to the present invention, messages conforming to secure e-mail standards such as S / MIME use the World Wide Web HTTP instead of traditional e-mail protocols such as SMTP / POP. Distributed by a document distribution protocol, such as a protocol. The distribution of web-based security emails removes the burden of obtaining and maintaining security email processing software from recipients, and allows recipients to receive security emails instead of receiving them as Internet email attachments. Having it downloaded from a web server increases the likelihood of a successful distribution.

The security email distribution system uses a web server that distributes security messages over the World Wide Web according to HTTP and notification messages sent to recipients by legitimate email. As a result, secure email can be sent to virtually any recipient with an email account, beyond widely used web browsers and email readers, regardless of the capabilities of the recipient's computer system.

A secure e-mail distribution system develops the capabilities of widely used web browsers and automatically embeds and runs software from a web server. Particularly useful is the Java ™ where such a browser is located on a server
The ability to call applets and bring software to a very wide range of computing environments. Some web browsers have the ability to automatically download and incorporate other types of software, including currently plug-in applications and known ActiveX controls. In particular, the recipient responds to the notification message by depositing a URL through the World Wide Web with a web server that controls access to the secure email message. In response, the web server sends software processing the secure message in addition to the secure email message itself, thereby making the message readable to the recipient. Such processing includes, for example, decrypting the message and one or more attachments, and verifying the signature of the secure email message.

There are two main components in a secure email distribution system. The first component is a web server that receives security messages for distribution. The second component is security message processing software. Sender is S / M
It is assumed that you have software that can generate secure email messages according to secure email standards such as IME, PGP / MIME, or open PGP. Also, the recipient has the ability to read short text messages (although reading attachments is not required), has access to Internet e-mail, and runs applets and / or such as secure message processing software. It is also assumed that there is a web browser that can download and embed various software.

To send a secure message, the sender creates a secure message,
The secure message is deposited with the intended recipient's email address on the web server of the secure email distribution system. Such deposits may be made, for example, through a web format using a secure email distribution system and secure email authoring software recognizing the web server, hosted on a web server, or through a secure email distribution system and web server. This can be done in many different ways, such as through the use of Internet relays that are aware of this. In particular, the email relay detects emails that conform to the secure email protocol supported by the secure email distribution system, redirects such emails to the secure email distribution system, and sends other emails. Can continue to pass according to conventional email protocols such as SMTP.

When such a deposit is made, the secure e-mail distribution system provides the recipient with information about the secure message to the recipient and a uniform resource locator ( Generate an e-mail message containing the URL. This URL specifies the web server of the secure e-mail distribution system and contains sufficient information to allow the web server to locate the secure message.

The recipient accesses the URL on the web server using a web browser. The web server generates a web page, which instructs the web browser to call the secure email processing software. Secure email processing software is executed by the recipient's web browser, which retrieves the secure message from the web server, processes the secure message, and passes the result to the recipient. Processing of the security message may include decrypting the message and one or more attached data files and verifying the signature of the message.

The secure e-mail distribution system of the present invention allows a recipient to properly process a secure message without having to have secure message processing software prior to receiving the message. In addition, because the secure message processing software is stored on a web server, the secure e-mail distribution system ensures that recipients have the latest available version of the secure message processing software.

BEST MODE FOR CARRYING OUT THE INVENTION According to the present invention, a distribution server 104 (FIG. 1) follows a secure e-mail protocol and (i) notifies a recipient 106 of an e-mail message, (ii) receiving data identifying the message from the recipient, and (iii) responding to the data in accordance with a security protocol and providing computer instructions for receiving and properly handling the email message, thereby providing Distribute.

In particular, sender 102 sends a secure email message using a secure email protocol over a computer network 108, for example, the Internet. The secure email message is addressed to recipient 106. However, the security message goes through the distribution server 104, as described more fully below. Although distribution server 104 is shown in FIG. 1 as a single computer system, it will be appreciated that distribution server 104 may include multiple computer systems.

The distribution server 104 assumes that the recipient 106 does not have the appropriate software to correctly process the secure message according to the security protocol. Therefore, it is assumed that the secure email protocol should be implemented correctly in the recipient 106. One such secure email protocol is the S / MIME Protocol Third Edition. Other versions of S / MIME may also be secure email protocols. In another embodiment, the PGM /
Other secure email protocols such as MIME and open PCG can also be implemented.

As described more fully below, distribution server 104 sends a notification email message to recipient 106 using conventional techniques. The notification email message has sufficient identification information in the distribution server 104 to identify the particular security message addressed to the recipient 106.

When recipient 106 receives and reads the notification email message, recipient 106 deposits the identification information with distribution server 104 and thereby requests that the security message be distributed. In this embodiment, the identifying information is a universal resource locator (URL) containing data identifying the secure message, and the recipient 106 may be a Netscape Navigator, sold by Netscape, Inc. of Mountain View, California, or Washington, DC. Through a web browser 704 (FIG. 7), such as Internet Explorer, sold by Microsoft Corporation of Redmond, Calif., The hypertext transfer protocol (H
The URL is transmitted to the distribution server 104 using TTP).

In response to the URL, distribution server 104 sends computer instructions that are executed by recipient 106 and implement a secure email protocol to which the secure message conforms. As described in greater detail below, the computer instructions are compatible with the Java ™ computer instruction language implemented by most currently available web browsers in the exemplary embodiment. The web browser, in response to receiving the computer instructions, starts interpreting and executing the computer instructions, ie, starts executing as the computer instructions arrive. In another embodiment, the computer instructions are transmitted to the recipient 10 so that subsequent security email messages can be processed without requiring a second distribution of the computer instructions.
6 to form a computer program stored as persistent storage in the computer system. In this exemplary embodiment, the distribution server 104 verifies that the stored program for the recipient 106 is the latest available program and redistributes the computer instructions if the program is not up to date. And re-install.

As will be described more fully below, upon execution of the received computer instructions, recipient 106 retrieves a secure message emanating from distribution server 104,
Process the retrieved secure email message according to a secure email protocol implemented by the received computer instructions.

In this manner, recipient 106 can establish established security without first separately obtaining and properly incorporating software specifically designed to implement a secure email protocol. E-mail can be received safely according to the protected e-mail protocol.

Sender 102 As described above, sender 102 prepares and sends a message according to a secure email protocol such as S / MIME. In addition, the message is addressed to the distribution server 104. Sender 102 is shown to be a computer system. However, the email is usually addressed to a human user, rather than to a computer system, or alternatively to a computer process. In simplicity, the sender 102 is a human user of the computer system or a computer process running inside the computer system. Similarly, recipient 106 is a computer system, shown as recipient 106 in the figure, or a computer process running within the computer system.

To prepare the message according to the secure email protocol, the sender 102 includes an email authoring process 202 (FIG. 2), and the email authoring process 2
02 also includes a security protocol module 204. The email authoring process 202 generates an S / MIME message given a commercially available S / MIME capable email software, in other words, an initial document and a set of one or more recipient email addresses. Software having the ability to do so. An example of such software is World Secure / Mail, available to e-mail customers from World Talk, Inc. of Santa Clara, California (http://www.worldtalk.com). Security Protocol Module 2
04 is shown to be an essential component of the email authoring process 202, while the security protocol module 204 can be a plug-in or helper application that adds functionality to the email authoring process 202. I understand.

Logic flow diagram 300 (FIG. 3) illustrates one possible example of message packaging by email authoring process 202 and security protocol module 204. Various security email protocols use various cryptographic protocols in addition to the signature encryption protocol shown in logic flow diagram 300. For example, some secure email protocols may not allow signing and / or support cryptographic protocols such as encryption-signature and signature-encryption-signature. In addition, the logic flow diagram 300 has been simplified for clarity and includes known and conventional steps such as, for example, key management, certificate lookup and retrieval, and certificate validation.

In step 302, the email authoring process 202 (FIG. 2) collects information elements of the message, ie, one or more data files, and includes them in the message and one or more recipient addresses. In step 304 (FIG. 3), security protocol module 204 (FIG. 2) packages the one or more files into a multi-part MIME construct. In a test step 306 (FIG. 3), the security protocol module 204 determines whether the security message should be signed as specified by the sender 102 through the email authoring process 202. Sender 102 can specify whether or not to sign the message using conventional user interface techniques, or alternatively, can use a logic element to automatically determine whether or not it is desired to sign the message. Can be determined.

If so, the process moves to step 308. vice versa,
If the message is not signed, step 308 is skipped. In step 308, security protocol module 204 signs the multi-part MIME construct to form a signed data package. In this embodiment, the signed data package conforms to the known PKCS # 7 data format. In test step 310, security protocol module 204 determines whether to encrypt the message. Sender 102 can specify whether or not to encrypt the message using conventional user interface technology and, alternatively, use a logic element to determine whether or not it is desired to encrypt the message. Can be determined automatically. If the message is to be encrypted, the process moves to step 312. Conversely, if the message is not signed, steps 312 through 314 are skipped. In step 314, the security protocol module 204 encrypts the multi-part MIME construct to form an encrypted data package, and in this exemplary embodiment, the encrypted data package conforms to the known PKCS # 7 data format. I do. At step 316, the data package is returned as a message to send.
The data package is the signature data package of step 308 if the data is signed but not encrypted, or the encrypted data package of step 314 if the data is encrypted. Thus, the security message can be signed and / or encrypted.

Message Deposit Module 206 The message deposit module 206 communicates with the distribution server 104 to deposit security messages for distribution. Specifically, the message deposit module 206
Directs the secure email message generated by the email authoring process 202 and the security protocol module 204 to the distribution server 104. In one embodiment, the message escrow module 206 includes an e-mail authoring module 202 that allows a human user of the sender 102 to assemble and send a secure message to the recipient 106 using a single integrated user interface. Element.
In this embodiment, the message escrow module 206 communicates with the distribution server 104 over the network 108 using HTTP and, in particular, sends the secure message using an HTTP "post" command. HTTP and HTTP
The "post" command is well known and will not be described further here.

In a simpler embodiment, message escrow module 206 is a web browser with the ability to upload data using HTTP “post” commands. In such a browser, the message generated through the e-mail copyright processing 202 and the security protocol module 204 can be saved inside the sender 102 as a data file itself, and separated and transmitted to the distribution server 104 through the message deposit module 206 Required.

In the third embodiment, the sender 102 uses the normal SM according to the logic flow diagram 300
A message formed by TP (Simple Mail Transfer Protocol) is transmitted. In this embodiment, the secure email addressed to recipient 106 is directed to distribution server 104 by an email relay.

Such a relay can be implemented using a known program, another known “send mail” program called “block mail” that processes each incoming email message according to a script. The script first verifies that each email message is secure content, forwards the email message to the distribution server 104 if the email message contains secure content, otherwise sends the email message to the distribution server 104. Forward the mail message to a conventional SMTP email server.

All e-mail destined for recipient 106 will take the route through the relay so that the relay can process each e-mail message destined for recipient 106. Such can be done in many ways. First, the sender 102 can specify that all outgoing e-mail be routed through an e-mail relay. In particular, most currently available e-mail readers / composers allow the user to specify an outgoing SMTP server, so that the sender 102 can designate such an e-mail relay as the outgoing SMTP server. Accordingly, email sent by sender 102 according to the secure email protocol is distributed through a secure email distribution system as implemented by distribution server 104. Second, the relay may be part of a component of the routing architecture of the network 108 itself. For example, a large company, university, or commercial Internet service provider may incorporate such an email relay as an integral part of its email routing. As a result, all e-mail destined to and / or from a large company, university, or commercial Internet service provider will be processed by such an e-mail relay and the distribution server 104 will receive the secure e-mail. The distribution system is available to all recipients reachable through it. Third, route selection information
The sender 102 sends the e-mail message to the recipient 10 via the e-mail relay.
6 can be included in the recipient's 106 email address.

Distribution Server 104 The distribution server 104 is shown in further detail in FIG. The distribution server 104 includes a web server 402 that includes a customized filter that in turn blocks and redirects all HTTP requests. Specifically, the distribution server 10
All HTTP requests unrelated to the security message distributed by
It is directed to another conventional HTTP web server. As an alternative to redirecting HTTP requests, the web server 402 processes regular HTTP requests as usual,
At the same time, requests containing URLs pointing to security messages are filtered and distributed in the manner described herein. The web server 402 can use standard programming techniques to select specific HTTP requests for special processing, such as, for example, CGI, NSAPI, active server pages, servlets. The web server 402 is the primary server between the distribution server 104 and the recipient 106 in distributing a secure message generated according to the secure email protocol as illustrated by the logic flow diagram 300 described above. Interface.

The distribution server 104 also includes an e-mail server 404. Email server 404 sends the notification message to the intended recipient in a manner more fully described below. Distribution server 104 includes security message logic 406, which governs the overall operation and interaction of the components of distribution server 104.

Once the security message, addressed to the recipient 106, is received by the recipient 106, the security message is distributed by the security message logic 406 according to the logic flow diagram 500 (FIG. 5). . At step 502, the secure message logic 406 initiates the distribution process by generating a URL at the recipient 106 that includes key data that uniquely identifies the secure message within the secure message database 408. Step 5
At 04, the secure message logic 406 (FIG. 4) sends a notification message including the URL and the key data contained therein to the recipient 106 through the email server 404. The notification message is sent to the recipient 106 using the recipient's email address contained in the security message and using the well-known SMPT protocol.

The general paradigm of data distribution by sending a URL associated with data to a recipient is described in US Pat. No. 5,970,970 to Smith et al.
Electronic Document Distribution System for Sending Electronic Document Notifications to Its Recipients ", the description of which is incorporated herein by reference. The ingestion of data identifying messages to be distributed is provided by Jeffrey C. Smith (Jeffre
y C.I. Smith) and Jean Christophe Bandini (Jean Chr)
US Patent Application S / N08 / 832,784 to istophe Bandini)
In Privately Trackable URLs for Directed Document Distribution, which is hereby incorporated by reference.

The remainder of the distribution of the security message is according to the logic flow diagram 600 (FIG. 6)
Achieved through a "pull" paradigm. Specifically, the receiver 106 (FIG. 1) receives the notification message including the URL including the key data. Recipient 106 deposits the URL with web server 402 (FIG. 4) over network 108 using, for example, a conventional web browser 704 (FIG. 7) within recipient 106.

In step 602 (FIG. 6), the web server 402 (FIG. 4) receives the URL,
The RL is determined to accompany the distributed security message. As described above, a UR that is unrelated to the security message distributed by distribution server 104
L may be redirected to another, traditional HTTP web server, or alternatively,
Processed by web server 402 in a conventional manner. Web server 402 notifies security message logic 406 of the receipt of the URL.

In step 604 (FIG. 6), security message logic 406 (FIG. 4)
Identify the security message identified by the key data within the RL and form an inquiry about the security message.

At step 606, security message logic 406 searches security message receiver applet 410 and attaches a query for the security message to the applet. In particular, the secure message logic 406 constructs an HTML document that includes a tag to the secure message receiver applet 410 and includes the visit as a parameter used by the secure message receiver applet 410 during execution. In one embodiment, the query for the security message is key data from the URL received in step 602.

At step 608, security message logic 406 sends the HTML document, along with the tag to embedded security message receiver applet 410, to web server 402, returning the recipient 106 in response to the URL. The secure message receiver applet 410 executes within the recipient 106 and processes the secure message according to the secure email protocol in a manner more fully described below.

Recipient 106 Recipient 106 is shown in greater detail in FIG. Recipient 106 includes an email reader 702, which is conventional, by which the notification message described above is received and read. In some embodiments, the notification email includes a URL comprising key data in an HTML attachment file format,
This is called Jeffrey C. Sm, entitled "Electronic Document Distribution System for Sending Electronic Document Notifications to Its Recipients."
i.) as described in US patent application S / N / 09 / 386,643, the description of which is incorporated herein by reference. In this exemplary embodiment,
The notification message includes an HTML attachment that is opened by the recipient 106. Within the recipient's 106 computer system, an HTML data file, such as an HTML attachment, is combined with a web browser as a default application for opening the HTML data file, ie, processing and displaying the contents of the data file. Have been. Therefore, when opening the HTML attached file, the HTML browser 704 executes and displays the contents of the HTML attached file. HTML browser 704 is a conventional web browser in this exemplary embodiment.

In another embodiment, the URL is included as text in the notification message. Some e-mail readers automatically open an HTML browser in the manner described above when the recipient 106 clicks on a URL. In another case, the recipient 106 copies the URL from the message and independently starts the HTML browser and enters the URL. Recipient 106 is an e-mail reader 702 and HTML
It is assumed that both the browser 704 can be used, and that the HTML document can be searched using both the HTML browser 704 and the URL found in the text message received through the email reader 702.

As described above, HT sent in response to an HTML attachment or URL
The ML document includes an embedded tag associated with a secure message receiver applet 410 (FIG. 4) that includes a query for a secure email message to be distributed to the recipient 106. An embedding tag is a known component of an HTML data file. When displaying the contents of an HTML attachment,
TML browser 704 (FIG. 7) requests secure message receiver applet 410 from web server 402 (FIG. 4).

In yet another embodiment, the secure message receiver applet 41
0 is permanently embedded in the recipient's 106 computer system. In this embodiment, a comparison is made between the version of the permanently installed security message receiver and the latest version made available from the distribution server 104. this is,
This is accomplished by initiating the execution of a permanently embedded security message receiver requesting the latest version from the web server 402 of the distribution server 104. If the latest version is greater than the version of the permanently installed security message receiver, the permanently installed security message receiver starts redistribution and re-installation of the new security message receiver.

The HTML browser 704 (FIG. 7) includes an applet interpreter 706, which in this exemplary embodiment is a Java ™ interpreter, and is a computer according to the Java ™ computer instruction language of Sun Microsystems. Execute the instruction. Upon receipt and execution of the modified applet computer instructions, a secure email receiver 708 is formed. The secure email receiver 708 communicates with the distribution server 104 to download the secure message and then process the secure message so that the message can be read by the recipient 106. Thus, the secure email receiver 708 requires cryptographic capabilities to decrypt the secure message and verify the signature of the secure message. In addition, the security email receiver 708 may provide the security message with an essential portion of the content, or may transmit the essential portion of the content to the recipient 106 in a manner that the essential portion of the content is subsequently accessible. You must be able to save it to a local disk by storing it in a known location.

In this exemplary embodiment, security email receiver 708 is a Java ™ applet, which is cryptographically signed by distribution server 104 and allows the recipient to simply access the URL included in the notification message. Is transparently and dynamically downloaded via the HTML browser 704. The secure email receiver 708 is shown in more detail in FIG.

The security email receiver 708 includes a communication module 802, which serves for communication with the distribution server 104. In this exemplary embodiment, the communication module 802 supports the HTTP protocol and the web server 402 (FIG. 4)
) Is implemented using the well-known Java-net URL connection class, which allows the retrieval and transmission of data from a web server such as. In this exemplary embodiment, the communication module 802 (FIG. 8)
02, retrieves the security message, and after processing the security message as described below, reports the success of such processing to the web server 402.

The security email receiver 708 also includes the security protocol module 8
04, which serves to decrypt the security message, verify the sender's signature, and extract the data files contained in the security message. The security protocol module 804 also provides support for PKI functionality, including key management, decryption, and signature and certificate verification, as described more fully below.

In this exemplary embodiment, communication module 802 pipes the contents of the security message from communication module 802 to security protocol module 804.
Move through 6. Communication module 802 streams the security message through pipe 806 as the security message is received so that the security message can be processed upon receipt of the security message. It greatly improves the performance of the secure email receiver 708. The pipe is a known inter-module communication mechanism and can be implemented using, for example, a known class Java I / O package.

Processing by the secure email receiver 708 is shown in logic flow diagram 900. In step 902, the secure e-mail receiver 708
02 is initialized. In step 904, the secure email receiver 708 instructs the communication module 802 to retrieve a secure message from the distribution server 104. At step 906, a secure email receiver 708 sends a pipe 806 between the communication module 802 and the security protocol module 804 so that the data received by the communication module 802 is immediately transmitted to the security protocol module 804. To form If the processing of the received security message by the security protocol module 804 is successful, the secure e-mail receiver 708 determines at step 908 that success has been received by the web server 402 (
See Figure 4).

In this exemplary embodiment, the secure email receiver 708 also provides a user interface so that the recipient 106 can save any data files contained in and restored from the secure message to local non-volatile storage. You can save, then search and open. In addition, the secure email receiver 708 reports to the recipient 106 any errors that occur during processing of the secure message by the security protocol module 804.

Security Protocol Module 804 The processing by security protocol module 804 is illustrated in logic flow diagram 1000 (FIG. 10). As discussed above with respect to logic flow diagram 300 (FIG. 3), logic flow diagram 1000 (FIG. 10) is merely an illustrative example of processing in accordance with the secure email protocol. At step 1002, the security protocol module 804 determines whether to encrypt the security message. If the security message is not encrypted, security protocol module 804 skips steps 1004 through 1006.

At step 1004, the security protocol module 804 decrypts the security message. Step 1004 is the reverse of step 314 (FIG. 3) and the result is a MIME construct. In step 1006 (FIG. 10), security protocol module 804 parses the MIME construct. If the security message is signed, the result of such analysis is the signature data generated in step 308 (FIG. 3). Conversely, if the security message has not been signed, the result of such analysis is the collection of data files collected in step 308 (FIG. 3).

In step 1008 (FIG. 10), the security protocol module 804
Determine if the security message is signed. If the security message has not been signed, security protocol module 804 skips steps 1010-1012.

At step 1010, security protocol module 804 verifies the signature of the security message. Step 1010 is the reverse of step 308 (FIG. 3). The result of the verification in step 1010 (FIG. 10) is the MIME structure generated in step 304 (FIG. 3). In addition, security protocol module 804
Reports the result of the signature verification to the recipient 106 either as a report displayed to the user or as a report communicated to the process of receiving the security message. The report indicates whether the signature has been verified and, if so, indicates the identity of the sender indicated by the signature. In some embodiments, the report includes the sender's certificate.

In step 1012 (FIG. 10), the MIME structure generated in step 1010 is analyzed. The result of the analysis is a collection of data files collected in step 302 (FIG. 3). Thus, the logic flow diagram 1000 (by the security protocol module 804)
The result of the process according to FIG. 10) is that the data collected in step 302 (FIG. 3), whether the security message was signed in step 1012 or the security message was not signed in step 1006. A collection of files.

To perform steps 1004 and 1010, security protocol module 804 requires some level of public key infrastructure. In particular, the security protocol module 804 needs the ability to manage keys for the recipient 106 and access trusted certificate authority certificates.

To receive a secure email according to many secure email protocols such as S / MIME, PGP / MIME, and open PGP, recipient 106 has a public / private key pair. There must be. Asymmetric key encryption is known, but will be briefly described here for completeness. Asymmetric key encryption involves a pair of reciprocal keys, one kept secret and the other publicly available.
Keys are reciprocal in that data encrypted with either key can only be decrypted with the other key.

To encrypt a data file for the recipient 106, the data file is encrypted with the recipient's 106 public key. The recipient's 106 public key can be obtained, for example, from a trusted certificate authority. Trusted certificate authorities are known, but will be briefly described here for completeness. Once the data file is encrypted with the recipient's 106 public key, the data file cannot be decrypted without using the recipient's 106 private key.
Since the recipient's 106 private key is kept secret by the recipient 106, the recipient 10
Only 6 can decrypt the data file. Even if the subject encrypts the data file using the recipient's 106 public key, it is not possible to reverse the encryption to restore the data file to plaintext, unencrypted form.

To sign a data file, the data file or its hash value is encrypted using the signing subject's private key. As a result, any person or process that can know the public key of the signing entity can decrypt the data file or its hash value. Since only the signing subject can know the secret key of the signing subject, the signature is verified by successful decryption of the data file or its hash value using the public key of the signing subject. Therefore, the signing entity is authenticated as the source of the data file.

[0069] Public keys are often stored in the form of certificates. Certificates are well known, but will be briefly described for completeness. A certificate combines data identifying a subject, such as a person or a computer process, with the subject's public key. The certificate authority signs the certificate and ensures that the certificate has not been tampered with. Thus, certificates provide a fairly high level of trust in the connection between the public key and the authenticity of the key owner.

Currently available web browsers support secure communications such as SSL (Secure Socket Layer) and HTTPS (Hypertext Protected Transfer) using private keys and certificates. Generating such a private key or certificate is part of the initial configuration of the web browser.

In this exemplary embodiment, security protocol module 804 retrieves such private keys and certificates from HTML browser 704 (FIG. 7). The certificate is transferred to the distribution server 104 (FIG. 1) and used, for example, by the sender 102 in step 314 (FIG. 3) to encrypt data to the recipient 106. In addition, in step 1004 (FIG. 10), the security protocol module 804 (FIG. 8)
) Decrypts the data using such an introduced secret key.

In addition to introducing certificates and keys from the HTML browser 704 (FIG. 7), the security protocol module 804 provides a user interface through which the recipient 106 can view and operate the keys. For example, the recipient 106 can seek out the public key from another entity and add it to a key ring, a data structure containing many public keys. In addition, in this exemplary embodiment, the recipient 106 can delete the public key from the key ring using a user interface provided by the security protocol module 804. In this exemplary embodiment, using the user interface provided by security protocol module 804, recipient 1
06 can also send or introduce keys to password protected data files stored in non-volatile storage accessible to recipient 106.

As described briefly above, security protocol module 804 receives a certificate from a trusted certificate authority. The certificate authority may use the security protocol module 80
4 provides the certificate used to verify the signature in step 1010 (FIG. 10). There are now a number of certificate authorities that have established a reputation for being trustworthy, that is, sincerely generating certificates that are deposited with them. In one embodiment, security protocol module 804 (FIG. 8) receives an initial list of trusted certificate authorities and provides recipient 1 with a user interface, for example.
06 modifies the list to include other certificate authorities that the recipient 106 trusts. It is important that the initial list of trusted certificate authorities for the security protocol module 804 be secure from tampering by attackers who intend to impersonate other parties' authenticity by certificate tampering. is there. Therefore,
In this exemplary embodiment, the secure email receiver 708 is passed from the distribution server 104 in a signed form, ie, as signed by the distribution server 104. Thus, tampering with the contents of the secure e-mail receiver 708
Avoid, including the list of trusted certificate authorities.

In another embodiment, the list of trusted certificate authorities is retrieved from web server 402 (FIG. 4) of distribution server 104 each time security protocol module 804 (FIG. 8) needs such a list. Can be searched. In this embodiment, the list is not modified by recipient 106. In addition, web server 402
It is important that the list of trusted certificate authorities received from is secure from tampering by an attacker who seeks to impersonate another party's authenticity by manipulating the certificate. Thus, in this alternative embodiment, the list of trusted certificate authorities is received from distribution server 104 over a secure channel, such as an SSL connection. Thus, tampering during distribution of the list of trusted certificate authorities is avoided.

The security protocol module 804, in addition to accessing keys and certificates, can securely store the keys and certificates inside the persistent storage of the recipient 106. In one embodiment, the private key is stored by the recipient 106 in local storage,
Stored using a strong symmetric encryption scheme such as a known password-based encryption scheme PKCS # 12 and a known triple DES algorithm. As described above, in one embodiment, the secure email protocol supported by distribution server 104 is the S / MIME protocol. Accordingly, the security protocol module 804 of this embodiment is implemented using RSA Data Security's RSABSAFE Crypt J ™ 2.0 toolkit. This toolkit provides basic cryptographic functionality based on the known PKCS # 1 standard. In addition, the toolkit includes a module that can generate and verify message digests and digital signatures, as well as encrypted and decrypted data, using a number of encryption algorithms. Familiarity with this toolkit and the S / MIME protocol in general will be useful in implementing this exemplary embodiment of the security protocol module 804.

In addition, the following components are known and may be useful in implementing this exemplary embodiment of the security protocol module 804: (1) ASN. 1: ASN. The 1DER data format provides a universal way to represent and encode structured data. ASN. 1 is widely used in the public key cryptosystem. The security protocol module 804 includes the ASN. One DER encoding can be analyzed and generated. (2) PKCS # 1: PKCS # 1 can use many encryption algorithms to calculate and verify message digests and digital signatures, as well as encrypted and decrypted data. PKCS # 1 is RSABSAFE Crypt J (
(TM) 2.0 toolkit. (3) X. 509: X. 509 defines the format of the certificate. In this embodiment, PKCS # 1 in addition to building the certificate chain,
. 509 Third Edition Certificate can be analyzed and verified. This component of PKCS # 1 also provides support for the third version certificate extension required by S / MIME. X. 509 is an ASN. 1 and PKC to verify
It can be implemented using S # 1. (4) PKCS # 12: PKCS # 12 defines data protected by a password. By implementing PKCS # 12, the security protocol module 804 can extract secret keys and certificates from password protected PKCS # 12 data. In addition, the security protocol module 804 may also generate password-protected PKCS # 12 data for a given key and certificate set and a given password. PKCS # 12 is AS
N. 1, PKCS # 1, and X.0. 509 is implemented. (5) Private key database: By implementing the private key database,
Security protocol module 804 manages one or more private keys of recipient 106. In this exemplary embodiment, security protocol module 804 supports adding, deleting, and enumerating private keys. The secret key is protected and stored by the user-defined password. Although the term "password" is considered to imply a single word, it is understood that "password" as used herein can include non-text data and can include multiple words, such as a passphrase. . The security protocol module 804 stores the key in a database using PKCS # 12 and retrieves the key from another application. (6) Trusted Certificate Authority Database: By implementing the trusted certificate authority database, the security protocol module 804 can access a list of trusted certificate authorities. The security protocol module 804 has 5
09 to manipulate the certificate of the certificate authority. (7) PKCS # 7 signature data: PKCS # 7 defines a cryptographic message syntax rule. By implementing PKCS # 7, the security protocol module 804 can verify data signed using the PKCS # 7 format, and authenticate the signed content of such data and the signer's signature. Can be extracted. The security protocol module 804 uses ASN. To analyze the PKCS # 7 data. 1 to verify the signature, and X.1 to verify the signer's certificate. 509 and a trusted certificate authority. (8) PKCS # 7: PKCS # 7 also defines a format for envelope data. By implementing the PKCS # 7 envelope data portion, the security protocol module 804 can decrypt the encrypted and packaged data using the PKCS # 7 format. The security protocol module 804 uses ASN. To analyze the PKCS # 7 data. 1
It uses the private key database to access the recipient's 106 private key needed to decrypt the security message, and PKCS # 1 for decryption. (9) MIME analysis module: The security protocol module 804
A MIME message can be parsed and all attachments contained in such a MIME message can be extracted. (10) S / MIME message processor: The security protocol module 804 implements an S / MIME message parsing module, which processes S / MIME messages with decryption and signature verification applied as needed. S / M
The IME message parsing module uses the security protocol module 804 M
Relying on the IME analysis module to detect and extract the S / MIME content, once all of the signature and encryption layers are both PKCS # 7 features described above as components (7) and (8) When used and removed, process the source content. (11) Certificate user interface: Security protocol module 8
04 implements a certificate user interface that can report certificate information to the recipient 106. The certificate user interface is X. 509 provides such information. (12) Signature user interface: security protocol module 80
4 implements a signature user interface that can report S / MIME package signature information to the recipient 106. The signing user interface provides an indication of the signer's certificate with the certificate user interface and a PK containing, for example, the signature date and time.
It can rely on the signature information generated by CS # 7. (13) Private Key Database User Interface: The security protocol module 804 implements a private key database user (interface?), Which provides users with access to private key database operations. The private key database user interface uses the certificate user interface to indicate the user's certificate and performs operations using the private key database.

The above description is merely illustrative and not restrictive. The present invention is limited only by the appended claims.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a secure electronic mail distribution system including a distribution server that distributes secure electronic mail according to the present invention.

FIG. 2 is a block diagram showing the sender of FIG. 1 in further detail.

FIG. 3 is a logic flow diagram illustrating the generation of a secure email message by a secure email protocol.

FIG. 4 is a more detailed block diagram of the distribution server of FIG. 1;

FIG. 5 is a logic flow diagram of the distribution of a secure email message according to the present invention.

FIG. 6 is a logic flow diagram of the distribution of a secure email message according to the present invention.

FIG. 7 is a more detailed block diagram of the recipient of FIG.

8 is a block diagram illustrating the recipient of the secure email of FIG. 7 in further detail.

FIG. 9 is a logic flow diagram of receiving a secure email message according to the present invention.

FIG. 10 is a logic flow diagram of processing a secure email message according to the secure email protocol.

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID , IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, NO, (72) Invention NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW Party Bandini Jean-Christophe United States of America 95014 Cupertino # E10 North Foothill Boulevard 10230 F-term (reference) 5B017 AA03 BA07 BB09 CA16 5J104 AA09 LA06 NA02 PA08 5K030 GA15 HA06 HC01 KA01 KA06

Claims (42)

[Claims] Claims 1. A method for distributing an e-mail message conforming to a secure e-mail protocol to a recipient, comprising: receiving a query about the e-mail from the recipient through a computer network; Receiving, via the computer network, computer instructions for retrieving and processing the message in accordance with the secure email protocol, receiving the email message conforming to the secure email protocol. How to distribute to people. 2. The method of claim 1, wherein receiving the email message from a sender over the computer network, forming the inquiry about the email message, notifying the inquiry. The method of claim 1, further comprising: including in a message; and sending the notification message to the recipient over the computer network. 3. The method of claim 1, wherein the computer instructions collectively form an applet. 4. The method of claim 1, wherein transmitting comprises transmitting the computer instructions such that the computer instructions are executed by the recipient without human intervention upon reception. the method of. 5. The method of claim 1, wherein said secure email protocol is an S / MIME secure email protocol. 6. The method of claim 1, wherein the secure email protocol is a PGP / MIME secure email protocol. 7. The method of claim 1, wherein the secure email protocol is an open PGP secure email protocol. 8. The method according to claim 1, wherein the receiving is in accordance with a hypertext transfer protocol. 9. The method according to claim 1, wherein the transmission follows a hypertext transfer protocol. 10. The method of claim 1, wherein the email message includes one or more attached data files. 11. The method of claim 11, wherein the computer instructions, when executed by the recipient upon receipt, process the email by decrypting at least a portion of the email. 2. The method according to 1. 12. The computer instructions, when executed by the recipient upon receipt, process the email by verifying at least a portion of the signature of the email. The method of claim 1. 13. The method of claim 1, wherein the computer instructions provide a user interface for managing one or more encryption keys. 14. The method of claim 1, wherein the computer instructions, when executed, introduce one or more encryption keys. 15. A computer readable medium useful for a combination of a processor and a computer having a memory, comprising: receiving a query about an e-mail message from the recipient over a computer network; Sending search computer instructions to the recipient over the computer network to retrieve and process the message in accordance with the secure email protocol, thereby distributing email messages conforming to the secure email protocol to the recipient A computer readable medium comprising computer instructions configured to cause a computer to do the following. 16. The computer instructions comprising: receiving the electronic mail message from a sender over the computer network; forming the inquiry about the electronic mail message; including the inquiry in a notification message; 16. The computer-readable of claim 15, wherein the notification message is sent to the recipient over the computer network, thereby causing the computer to distribute the email. Medium. 17. The computer-readable medium of claim 15, wherein the search computer instructions collectively form an applet. 18. The method according to claim 15, wherein the transmitting is such that the search computer instructions are transmitted by the recipient without human intervention upon receipt. A computer-readable medium according to claim 1. 19. The computer readable medium according to claim 15, wherein said secure email protocol is an S / MIME secure email protocol. 20. The computer readable medium according to claim 15, wherein said secure email protocol is a PGP / MIME secure email protocol. 21. The computer readable medium according to claim 15, wherein said secure email protocol is an open PGP secure email protocol. 22. The computer-readable medium according to claim 15, wherein the receiving is according to a hypertext transfer protocol. 23. The computer readable medium according to claim 15, wherein the transmission follows a hypertext transfer protocol. 24. The computer readable medium according to claim 15, wherein said email message includes one or more attached data files. 25. The search computer instructions, wherein the search computer instructions process the email by decrypting at least a portion of the email upon execution upon receipt by the recipient. 16. The computer-readable medium according to claim 15, 26. The search computer instructions, wherein the search computer instructions, upon execution upon receipt of the recipient, process the email by verifying at least a portion of the signature of the email. A computer readable medium according to claim 15. 27. The search computer instructions, wherein the search computer instructions provide a user interface for management of one or more encryption keys.
6. The computer-readable medium according to claim 5. 28. The computer-readable medium of claim 15, wherein the search computer instructions, when executed, introduce one or more encryption keys. 29. A processor, a memory operatively coupled to the processor, and a distribution module, the distribution module being: (i) executing from the memory within the processor; and (ii) A retrieval computer which, when executed by the processor, receives an inquiry about an e-mail message from the recipient over a computer network and retrieves the e-mail message by execution to process the message according to the secure e-mail protocol Sending instructions to the recipient over the computer network, thereby causing the computer to distribute email to the recipient that conforms to a secure email protocol. system. 30. The distribution module comprising: receiving the email message from a sender over the computer network; forming the query about the email message; including the query in a notification message; 30. The computer system of claim 29, wherein the computer system is configured to cause a computer to distribute the email by sending a notification message to the recipient over the computer network. 31. The computer system of claim 29, wherein the search computer instructions collectively form an applet. 32. The method according to claim 35, wherein transmitting comprises transmitting the search computer instructions in a manner that, upon receipt, causes the search computer instructions to be executed without human intervention. Item 30. The computer system according to item 29. 33. The computer system of claim 29, wherein said security email protocol is an S / MIME security email protocol. 34. The computer system of claim 29, wherein said security email protocol is a PGP / MIME security email protocol. 35. The computer system of claim 29, wherein said security email protocol is an open PGP security email protocol. 36. The computer system according to claim 29, wherein receiving is in accordance with a hypertext transfer protocol. 37. The computer system according to claim 29, wherein the transmission follows a hypertext transfer protocol. 38. The computer system of claim 29, wherein said email message includes one or more attached data files. 39. The search computer instructions, wherein the search computer instructions, when executed by the recipient upon receipt, process the email by decrypting at least a portion of the email. Item 30. The computer system according to item 29. 40. The search computer instructions, when executed by the recipient upon receipt, process the email by verifying at least a portion of the signature of the email. A computer system according to claim 29. 41. The computer system of claim 29, wherein the search computer instructions provide a user interface for managing one or more encryption keys. 42. The computer system of claim 29, wherein said search computer instructions introduce one or more encryption keys upon execution.