CA2641728A1 - Trusted third party authentication and notarization for email - Google Patents
Trusted third party authentication and notarization for email Download PDFInfo
- Publication number
- CA2641728A1 CA2641728A1 CA2641728A CA2641728A CA2641728A1 CA 2641728 A1 CA2641728 A1 CA 2641728A1 CA 2641728 A CA2641728 A CA 2641728A CA 2641728 A CA2641728 A CA 2641728A CA 2641728 A1 CA2641728 A1 CA 2641728A1
- Authority
- CA
- Canada
- Prior art keywords
- message
- electronic message
- processor
- sender
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
A system and method for providing trustworthy processing of electronic messages applies the digital signature of a trusted third party to a message en route from the sender to a recipient. The signature is preferably applied so that it is compliant with the S/MIME
standard. The use of a trusted third party applying the digital signature allows for simplified timestamping of the message and reduces the complexity of verification of the authenticity of an archived message.
standard. The use of a trusted third party applying the digital signature allows for simplified timestamping of the message and reduces the complexity of verification of the authenticity of an archived message.
Description
TRUSTED THIRD PARTY AUTHENTICATION AND NOTARIZATION FOR
EMAIL
FIELD OF THE INVENTION
This invention relates generally to fhe use of a trusted tliird party to provide authentication of message integrity and non-repudiation.
BACKGROUND OF THE INVENTION
Electronic mail (email) has become a ubiquitous form of communication between a vat-iety of parties. Email is favored for its low cost and rapid delivery, which nlany people see as a benefit and advantage over traditional mail secvices.
Multipurpose Internet Mail Extension (MIME) is a standard that defines how content such as text and non-text attachments are formatted. It should be noted that altllough MIME defines how the data is str.uctu.red and formatted, it is the Simple Mail Transfer Protocol (SMTP) that defines how email is sent to a server, and how it is sent between servers.
SMTP, for its ubiquity, popularity and general robustness has been considered to be the "killer-app" of the Internet, that is, the application whose utility brought the Intenaet to the atte.ntion of the general public and provided the incentive for beginning a mass adoption of the Internet as a setvice.
As email gained in popularity, its uses expanded and features that were not anticipated by the researchers who developed SMTP have now become desirable if not essential.
One failing in SMTP is the inability to verify the identity of the sender of an ernail message.
So-called spoofrng techniques and the use of open mail relays have allowed entities to transmit email while iinpersonating a sender. This impairs the trust that a recipient of an email message has in the provenance of the message, and diminishes the value of a trust-based system. Despite the ubiquity of email, these issues hamper the utility of email and could be used to reduce the evidentiary weight accorded to email messages in a judicial hearing.
A further problem with SMTP and MIME based email is that there is no robust mechanism to authenticate the content and header information of a message. A nuznber of work around solutions have been developed, but while remedying some of these issues these work around solutions typically introduce additional complexity as well as other related issues.
To understand existing solutions, it is first important to examine how a standard MIME/SMTI' mail session functions. Figure 1 illustrates aii SMTP based email excliange.
User A 100 composes an email niessage using a standard email client A 102.
Client A 102 can be any of a number of standard applications such as Apple Mail, Microsoft Outlook, Mozilla Thunderbird, or another such application. The composed message is addressed to an email address associated with user B 112, and is sent from client 102 to mail server A 104 using SMTP. Client 102 and seiver 104 can be integrated as is the case with web-based email platforms such as hotmail.com, Yahoo Mail, or gmail.com where the client is a web-based interface that has direct connections to the server ar-d may not einploy SMTP.
The email message is then transmitted through Internet 106 to mail seiver B 108 which is associated with the destination email address. Email client B 110 connects to server B
108 using a standard protocol such as the Internet Message Access Protocol (IMAP) or the Post Office Protocol (POP) so that the message can be downloaded. The message is then presented to User B 112.
This implementation does not necessarily provide autllentication of the sender, nor of the content of the email message. Because the content of the message cannot be veriFed as being the same as they were when sent, and the message cannot be authenticated as being sent by a particular user, the message can be repudiated by the sender at a later date.
A public-private encryption key based infrastructure can be employed to mitigate some of the problems associated with the system of Figure 1. Figure 2 illustrates one such example. User A 100 employs a secure email. client A 114 and a private encryption key 116 to sign the body 122 of a message 118. The header 120 of message 118 is not signed as the message 118 is transmitted using SMTP which does not provide a field for a signature that could be used to verify the header infortnation. The message 11.8 with signed message body 122 is transmitted to email server A 104 ttsing SMTP. The message is routed tlirough Intemet 106 to email server B 108 as any message would be in the system of Figure 1. The signed body 122 of message 118 is never inspected along the route as the infrastructure makes use of the standard MIME and SMTP protocols. Secure email client B 124 connects to email server B
108 using a standard protocol such as IMAP or POP and retrieves message 118 Secure email client B 124 niakes use of the public key 126 uniquely associated with private key 116 to veri fy the signature of the body 122 of the received message 118. The verified message 128 is then displayed to user B 112.
One skilled in the art will appreciate that using the public key 126, user B
112 is able to determine that the message body 122 was not tampered with. The signature can include a tiniestainp based on the clock/calendar ftinction of the system ru.nning secure email client A
114. The inessage can be repudiated by the sender, if the public-private key pair (keys 116 and 126) is not associated with User A 100 in a public manner.
To associate the key pair to User A 100, a certificate authority can bind the public key 126 to identifying information associated with User A 100. The certificate binding public key 126 to user A 100 can be sent to user B 112 in advance so that it can be added to a key ring in secure ernail ciient B 124. User B 112 could use public key 1.26 to encrypt a message to User A 100, who would then use private key 116 to decrypt the message. For User B 11.2 to sign any message (encrypted or otherwise) User B would need a different key pair.
Aithough this provides a degree of authentication of the message contents and a limited degree of non-repudiation, it requi.res that User A 100 obtain a certificate binding lcey 126 to him, and requires that User B 112 have a copy of the publ.ic key 126 (and preferably the certifcate) and a secure email client to verify the signature. Although this does not seem like a large burden, it only appears this way because of the limited number of parties in the illustrated transaction. If there are multiple parties, each party will be required to obtain a certificate from a certificate authority, and will be required to transmit the certificate to every other party. Specialized software to manage the ring of public keys, along with the relevant private keys must then be used to allow automated verification. This is a cunZbersome process. As the number of parties grows the number of keys required to allow verification of a message also grows. Furthermore, if the security of private key 116 is compromised, it must be revoked, wluch can otily effectively be done if a certificate autliority issued a certif cate for the key. When a certificate is revoked a cumbersome process must be undertaken by any party holding the compromised key to obtain a new certified key.
A public key infrastructure (PKI) employing a Certificate Authority (CA) does address a nLuiiber of the issues around authenticating the integrity of a message body, but it requires a large number of changes to the email infrastructure as well as an understanding of the complex nature of a PKI . As a result of the added complexity caused, PKI has been slow to gain traction with the broader public though it has proponents in the security field.
One system that has attempted to address these issues is provided through the use of Digital Postmarks. Digital Postmarks are intended for use in an enterprise environment, and are designed to specifically provide authentication of inessage contents.
Fundamentally it is designed as a non-repudiation service. Figure 3 illustrates an exemplary installation of a system to use Digital Postmarking. User A 100 uses a client to generate an email message.
This message is sent from a client to an outgoing mail server 130, typically provided by an enterprise associated with User A 100. Outgoing naail server 130 receives the niessage and forwards it to the digital postmarking server 132. Server 130 preferably signs the message prior to transmission to digital postmarking server 132 so that postmarking server 132 can verify that the message was not altered in transit. Digital postmarking server 132 then validates the authenticity of the signature against a Icnown key associated with either user A
100 or with inail server 130. Upon successful verification., the digital postmarking seiver 132 generates a timestamp that, along with the message, the signature and validation results are stored in a digital postmark non-repudiation database 134. This inforination can then be accessed at a later date to establish a non-repudiation ftinction. The postmarlcs sezver 132 and database 134 generate a digital postmarking receipt that is transmitted back to the outgoing mail server 130. The outgoing mail server 130 wraps the original message in the digital postmarking receipt and traiismits the message to the incoming mail sewer 136.
User B 112 retrieves the message in the proprietary digital postmarking wrapper 138 using a proprietary client 140. The client 140 can then retiieve the authentication information from the digital postmarlc non-repudiation database 134. Client 140 does not need to perform any verification processes on the message itself, as the verification, receipt and even the original document can. be retrieved from database 134, alternately a local cryptographic verification can be performed by client 140.
Although the digital postmarking system discussed with relation to Figure 3 can provide both authentication of a sender and the message, it requires proprietary software, and is cumbersome. The system is designed for implementation in an enteiprise environnlent, and does not take into account the needs of individuals. The digital postmarking server 132 is often dedicated to a particular outgoing mail server 130. As such digital postmarking server 132 requires that the enterprise obtain a dedicated hardware device and inZplement a complex process of having either client software sign a message or having the mail server 130 sign a message prior to beginning the verification process. The storage requirements for database 134 can be immense if all messages and attachments are stored for a number of different organizations. As such, the verification information is typically only stored for a predefined period. If this period expires, the ability to authenticate the message can be adversely affected.
To provide a mechanism for secure email, without needing a proprietary infrastructure, an ei-diancement to the MIME standard entitled Secure/MIME (S/MIME) has been introduced.
S/MIME defines a fonnat for a signed or encrypted message that requires that the verification information be included in the message in a particular fashion.. S/MIME
fitnctionality has been incorporated into most common modem email clients as its implementation is not conlplex and can be used to provide authentication of the message contents using digital signatures (non-repudiation is provided if a certificate is employed) as well an encryptian functionality. In operation, an S/MIME client will encrypt the message body and transmit the resulting object as a MIME attachment (specifically an application/pkcs7-mime MIME
entity). One advantage of S/MIME is that standard mail servers are used, tlius requiring no additional infrastructure.
For a user to make use of an S/MIME compliant client, an individual key or certificate must be obtained (preferably from a certificate authority). To encrypt a message, the recipient's public key must be known, whereas for signing, the recipient must have access to the sender's public key to allow for verification. By using a basic certificate, the only identifying information bound to the key (and thus the signed message) is an email address. To associate additional information, such as actual individual identity information, a certificate must be provided by a CA that has verified the identity infoiTnation. The certificate is then typically publicly available from the CA, and at a mininlum a certificate serial nurriber is made available to allow for revocation of a certificate (as described above witli respect to an encryption based mail client).
Figure 4 illustrates an S/MIME compliant exchange. One skilled in the art will appreciate that this makes use of a PKI infrastructure, and thus bears similarity to the encryption based signature system described earlier. A user 100 employs an S/MIME compliant email client A
142, to create a digitally signed email message 144 using private key 116. The message is sent to email server A 104 using SMTP and is then routed tluough Internet 106 to email server B
108. The digitally signed email message 144 is retrieved by S/MIME client B
124. S/MIME
client B 124 can parse message 144, wluch has a structure defined by the S/1VIIME standards.
As such, if the message has been encrypted, the encrypted package is provided in the application/pkcs7-mime MIME entity. Similarly, a defined entity is used for storing the cryptographic signature used to ensure data integrity (application/(x-pkcs7-signature).
Upon generation of the signature at client 142, the public key used to sigit the message is identified by the serial nutnber and certificate issuer. This allows the recipient to retrieve the cei-tificate to obtain the key to verify the signature. The certificate binding the user information to the key provides non-repudiation. However, it should be noted that at a later date if the certificate expires and is deleted, verification of the message can no longer be performed, reducing the archival qtialities of the verification process. When a certificate expires, a new certificate is often generated, even if the sanie key pair is used. This often leads users to assume that the old certificate can be deleted. Recipients often delete downloaded cei-tificates when they notice that a sender has multiple certificates, which can cause unexpected inability to verify signatures.
Because the signature is carried separate from the body of the message (in contrast to many other signattire implementations) mailing list software that changes the message body often resttlts in the invalidation of the signature. Addi.tionally, because message attachments may be encrypted using S/MIME, the ability of a server to perfomi scans to detect malware such as worms or virii is adversely affected. Stich scanning can only be perfomied at the client side, which is often too late in the process.
One skilled in the art wil.l appreciate that though there are many systems for providing digital signatures on email messages to allow for verification of the integrity of the message body, they all introduce a number of different layers of complexity. Addition of authenticated time stamping functionality is difficult to provide without the addition of additional server side hardware, much as the ability to authenticate the sender of a message requires the cumbersome management of encryption keys.
It is, therefore, desirable to provide a mechanism providing trusted authentication of a message and its contents.
SUMMARY OF THE INVENTION
It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.
In a first aspect of the present invention, there is provided a method providing tn.isted third party verification of an electronic message. The method comprises the steps of receiving the electronic message from a sender addressed to at least one recipient;
processing the electronic message to determine a digital signature associated with both the electronic message and a ptiblicly accessible key not associated with the sender of the electronic message; attaching the detei-mined digital signatLtre to the electronic message; and transmitting the electronic message with the attached digital signature to the at least one recipient.
In an embodiment of the first aspect of the present invention, the step of processing the message includes determining the digital signature by encrypting a cryptographic hash of the electronic message, possibly just the body of the electronic message, using the private portion of a private-public key pair. In another embodiment, the step of processing the electronic message can incltide overwriting header values such as time and date values in using verified header values (e.g. verified time and date values).
In a further embodiment of the present invention, the step of processing the electronic message includes performing a virus scan of the electronic message, and optionally removing a virus identified by the vinis scan. In another embodiment, the step of processing the electronic message can include copying header information from the electronic message into the electronic message body prior to determining the digital signature. In yet another embodiment of the first aspect of the present invention, the step of attaching the deterniined digital signature includes attaching the digital signature as a Secure Multipurpose Liternet Mail Extensions compliant digital signature.
In another embodiment of the first aspect of the present invention, the method can further include the step of authenticating an account associated with the sender of the electronic message after i-eceiving the electronic message. Authentication of the account can include receiving authentication credentials from the sender of the electronic message and verifying the credentials against known data. The receipt of authentication credentials can include receiving login credentials from the sender in accordance to the Simple Mail Transfer Protocol Authentication standard. In another embodiment, the step of authenticating includes verifying an address in a From: field in a header to the electronic message against a lcnown value.
In fiirther embodiments, the method can include billing an entity associated with the sender of the email message, and the message can be a Multipurpose Internet Mail Extensions based eniail message.
In a second aspect of the present invention, there is provided a trustworthy processor for providing verification of an electronic message, sent by a sender, to at least one recipient of the electronic message. The processor comprises a message interface and a signature engine.
The message interface receives electronic messages from the sender and transmits messages to the at least one recipient after processing by the signature engine. The signature engine signs the received message using a signature not associated with the sender to allow the at least one recipient to verify that the message .has not been altered and forwards the signed message to the at least one recipient through the message interface.
In an embodiment of the second aspect of the present invention, the message interface is a Simple Mail Transfer Protocol interface. In another embodiment of the second aspect of the present invention, the processor further includes a message processor for overwriting values in a header of the message with verified values, for copying the contents of the header into a message body prior, and for forwarding the modified message to the signature engine for signing. The message processor can also include a timestamping unit for overwriting the time and date of values in the header with verified time and date values. The message processor can also optionally include a sender verification unit for overwriting FROM
values in the header with verified name and email address values.
In a fuc-ther embodiment, the signature engine can include a dedicated cryptographic engine for digitally signing the message using a cryptographic key.
In another embodiment of the second aspect of the present invention, the processor fiirther includes an account authenticator for authenticating the identity of the message sender pr.ior to transmission of the signed message to the at least one recipient, and optionally includes a billing processor for assessing a charge to an account associated with the authenticated identity of the message sender.
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:
Figure 1 is a block diagram illustrating the data flow in a prior art messaging process;
Figtire 2 illustrates the data flow in a prior art cryptographic signature based messaging process;
Figure 3 illustrates the data flow in a prior art digital postmarking based messaging process;
Figure 4 illustrates the data flow in a prior art S/MIME based messaging process;
Figure 5 is a block diagram illustrating a data flow involving trustworthy processing of electronic messaging;
Figure 6 is a flow chart illustrating a method of trustworthy processing;
Figure 7 is a flow chart illustrating a method of authenticating an account in a trustworthy processing method;
Figure 8 is a flow chart illustrating a method of message processing in a trustwortlty processing method;
Figure 9 is a flowchart illustrating a metliod of billing in a trustworthy processing method; and Figure 10 is a block diagram illustrating logical elements of a trustworthy processor of the present invention.
DETAILED DESCRIPTION
The present invention is directed to a system and method for electronic messaging with a simplified authentication and message integrity verification mechanism.
Reference nlay be made below to specific elements, numbered in accordance with the attached figures. The discussion below should be taken to be exemplary in nature, and not as limiting of the scope of the present invention. The scope of the present invention is defined in the claims, and should not be considered as limited by the implementation details described below, which. as one skilled in the art will appreciate, can be modified by replacing elements with equivalent ftinctional elements.
In the present invention, the troubles associated with user management of a PKI key ring are mitigated by the use of a single digital signature for verifying the contents of messages from any of a number of different individuals. This signattire is associated with a trusted tliird party. Instead of relyuig on a user to obtain a certificate from a CA, the user obtains an account with a trusted third party that processes messages and performs the signature process on behalf of the user. The recipient of the message can tnist that the message was verified. by the trusted third party, and that the third party performed a publicly defined autlientication of the user. Thus, users do not need to obtain certificates, and recipients do not need to manage large and tulwieldy key rings. Additional services such as time stamping, sender authentication and virus scaiming can also be offered.
Because users are authenticated prior to the signed message being transmitted to recipients, a billing process can be implemented. The authentication and optional billing also reduce the likelihood that a message is unsolicited commercial email. As a result, the messages processed by the seiver can be trusted to a higher degree, allowing them to bypass so-called SPAM filters. Other benefits of the present invention will be discussed below with relation to the illustration of an exemplary system and method. One skilled in the art will appreciate that the description below is intended to be exeinplary in nature and should not be regarded as liniiting the scope of the present invention.
Figure 5 illustrates an architecture in which the present invention can be implemented. Two different types of senders are considei-ed, those in an enterpi-ise environment, and those who do not have access to such a system. Corporate Sender 200 creates an email message 204 using client A 202. The message 204 can. include attachments, but there is no requirement that attaclunents be appended to the message. The message is transmitted to the corporate mail seiver 206. Sender 200 is authenticated by corporate mail server 206. The message can either be flagged for sending as conventional email, or it can be flagged to be sent as a trusted third party signed message. The flagging of the message can be done at the client 202, or using corporate rules enforced by server 206. When a message is to be signed by the trusted third party, it is routed from seiver 206 to a trustworthy processor 208.
To provide service to individual users, the present invention can be accessed by individual users much as any other mail server would be used. An individual sender 200a composes a message 204a on client A' 202a. When the message is to be sent, it is relayed to trustworthy processor 208 through Internet 106. Connections to tnastworthy processor 208 from either client A' or from server 206 can be made using a conventional protocol such as SMTP with Transport Layer Security (TLS) for enhanced confidentiality and integrity of communication with the trustworthy processor 208 if so desired. This allows for existing infrastructure to be used without requiring either individuals or enterprises to update their software or hardware.
One skilled in the art will appreciate that Client A' 202a can be a web-based mail client without departing from the scope of the present invention.
Trustworthy processor 208 can perform a number of different processes on received messages. It preferably begins by authenticating the party initiating the session. In the case of an individual user, such as sender 200a, the authentication can be done using standard techniques such as SMTP-Aut11 or POP before SMTP. In the case of enterprise access, the enterpt-ise server 206 can be authenticated using any of a number of luiown techniques. The uset=s of enterprise mail server 206 are authenticated by seiver 206, and the server authentication of the user can then be passed along to trustworthy processor 208 en lieu of individual authentications.
Authentication of a user is done so that the trustwortliy processor can provide user authentication and non-repudiation. After authenticating the user, the ttlistworthy processor can ensure that the message header includes the correct infar.mation associated witlz the user account. The header information can optionally be copied into the body of the email so that it is signed. In conventional systems, the body of the email message is the only portion of the message that is signed. This is done to allow the message to be easily routed using the existing SMTP infrastructure; however, it causes the drawback that the sender and recipient information is n.ot signed. By copying header information into the body of the message, it can be signed along with the message body. The trustworthy processo:r 208 then signs the message, preferably using a standard based format, such as S/MIME, using the private portion of the postmarking key pair 210. The signed message is then transmitted to the addresses recipients, and is received by recipient mail seiver 212. The signed message 214 is retrieved by S/MIME email client B 216. The signed message 214 can be verified by client B 216 using the public portion of the postmark key pair 210. The verified message 218 can then be displayed to the recipient 220.
Before digitally siDung message 204 or 204a, trustworthy processor 208 can modify the message body to add in additional content including branding information designed to provide an immediate syi-nbol that recipients can associate with an assurance that the message was signed by a trusted third party.
Figure 6 is a flowchart illustrating a method of the present invention carried out by a trustworthy processor. The process starts when the processor receives a mail message for processing. The user account is authenticated in step 250. Upon successful authentication of the user, the message is processed in step 252. This processing step can include value added functionality, but also ineludes the d.etermination of a digital signature based on the content of the received message. The trusted third party signature deteri.nined in step 252 is attached to the message in step 254. This is preferably done in compliance with the foimat defined in the S/MIME standard. In the final step of the process, the message is transmitted to the addressed recipients.
In contrast to prior art methods, the signature applied is the signature of a trusted third party, not the signature of the sender. By making use of existing infiastructure, such as the S/MIME
infrastructure, the present invention can provide a foi-in of user authentication, message integrity verification and time stamping without requiring additional hardware installed in an enterprise, and without requiring users to make use of proprietary email clients to read or conzpose email.
In Figure 6, the first step is authenticating the account associated with an incoming message 250. The authentieation, of an account can be carried out using a nuniber of optional steps as illustrated in the flow chart of Figure 7. In step 258, the authentication credentials are received, and they are verified in step 260. This can be done by having the tnistworthy processor malce use of standard authentication mechanisms such as SMTP-Auth or POP
before SMTP. Other authentieation techniques can be employed, especially where the connection is received from an enterprise mail seiver. When an enterprise server connects, it can do so on behalf of an individual user, or can do so on behalf of the enterprise, with the trustworthy processor identifying individual information on the basis of the email address of the From: field in the message.
The tnistworthy processor may also elect to verify the From: field against addresses associated witll the verified authentication credentials. If the From.: field is not verified, the processor can. generate an error inessage, or optionally it can oveitivrite the From: field in the message. By performing a verification of the From: field, a further security barrier is provided, which can be important if the processor is intended to be able to airthenticate the sender information.
Upon finishing any or all of these steps, the process continues to step 252.
A brealcdown of optional steps in the processing of the message in step 252 is provided in the flowchart of Figure 8. One skilled in the art will appreciate that a number of these steps are optional as they provide added value to the system and method of the present invention, but are not essential for the operation of the system. After cornpleting step 250, the time and date associated with tlie message can be overwritten in step 264. This effectively embeds a timestamp in the message header that can be trusted by the recipient. The From Name field in the message can be overwritten with a name associated with the account if it does not match in step 266. In one simplified implementation, regardless of the From name field value, the name is overwritten to ensure that all messages are handled in the same fashion. In step 268 a virus scan of the message contents and any attachments can be performed. By perfomiing this scan, malware and inappropriate content can be identified and removed, or the message can be rejected and the user informed of a problem. By performing the scan before signing the message, the signature will still be valid. Server side scanning at either the sender or recipient .mail server in prior art implementations results in invalidating the signature if virii are to be removed when identified, which defeats the purpose of providing authenticated email.
In step 270, the header information of the message is copied into the body of the message.
This allows the To: From: Date: and Subject: information, along with other header information, to be incorporated into the body of the message before it is signed. Because earlier processes allow for the overwriting of name fields, time and date values and other infonnation to ensure that they are accurate, this information can. be sigiied along with the message body. This allows the recipient to archive the message and have non-repudiable evidence as to when a message was sent, who sent it and what it contained, without needing to consult an exteinal archive. The verification can be guaranteed so long as access to the cet-tificate of the trustworthy processor is available.
In step 272, a digital signature is generated using a private key associated with a public key stored in a publicly available certificate. The signature can be generated using conventional processes used over the entire message body. This digital signature is the trusted third party signature attached in step 254.
Because the sender inforination is verified before the message is transmitted to the addressed recipients, a billing process can be added to the method illustrated in Figure 6. One sueh process is illustrated in the flowchart of Figure 9. After the account verification process, the billing information associated with accaunt is processed as illustrated in step 274. A number of different implementations of a billing process can be employed. For exemplary purposes, a method is illustrated in Figure 9. In this exemplary method, the account is verified as being in good staiiding in step 276. The cost of the rnessage verification and signature is deternrined in step 278 and is transmitted to the accounting system in step 280. The process may require a response from the accounting system before proceeding if it is based on prepaid credits, or can be allowed to immediately proceed in other cases. The determination of the cost can be done using any of a number of different models, including either flat rate billing systems that bill a fixed amount per message, or a per-byte charge that is determined based on the size of the message. The specific implementation can be varied without departing from the scope of the present invention.
Figure 10 is a block diagram illustrating an implementation of the system of the present invention as fiinctional elements. One skilled in the art will appreciate that the fimction of a particular element can be spread across a number of other logical elements, or two or more logical elements illustrated in this diagram could be combined in one logical unit. The trustworthy processor 208 receives communications 282 from clients (either directly or thz=ougll a registered enterprise server) that contain botli mail messages and account credentials. The comniunications are received by an inbound mail interface, such as the illustrated inbound SMTP interface 284. The account credentials are forwarded to the account authenticator 286 and to the optional billing processor 288 if present. The account authenticator 286 authenticates the communication as being frotn a valid user account using any of a number of known techniques including those discussed above. The mail message is provided to both the billing processor 288 if present and the message processor 290. The billing processor 288 can be used to determine if a valid account is in arrears before a message is processed. It also can be used to detennine the cost associated with handling each i-eceived message. The billing processor 288 can be in communication with an accounting system (not shown) so that accurate billing inforniation can be recorded and invoiced. The message processor 290 processes the message after receiving the go ahead from both the account autlaenticator 286 and the billing processor 288. The message processor is not essential and can be omitted if the sole function of trustworthy processor is to obtain a trusted third party verification of the message contents. If added value setvices including time stamping, non-repudiable authentication of the message sender, virLts scanning and embedding of the header in the message body are to be provided they can be provided by the message processor 290. After the message processor 290 (or directly from the inbound SMTP
Interface) the message is provided to the signature engine 292 which uses the private portion of the postniarking key pair 210 to generate a signature that can be used to verify the contents of the message body. This signature is preferably 1landled in accordance with the S/MIME
standards when attached to the message. Signature engine can be a general purpose processor, or can optionally include a specific cryptographic engine designed for compu.ting cryptographic signatures of messages using key 210. The signed message is then provided to outbound SMTP interface 294 which transmits the message to the addressed parties.
Embodiments of the invention may be represented as a software product stored in a machine-readable medium (also refetred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied tllet-ein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, chemical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable nzedium nlay contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perfonn steps in a niethod according to an embodiment of the invention. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention may also be stored on the machine-readable medium. Software running fi=om the machine-readable medium may interface with circuitry to perfoim the described tasks.
The above-described embodiments of the present invention are intended to be examples only.
Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing frorn the scope of the invention, which is defined solely by the claims appended hereto.
FIELD OF THE INVENTION
This invention relates generally to fhe use of a trusted tliird party to provide authentication of message integrity and non-repudiation.
BACKGROUND OF THE INVENTION
Electronic mail (email) has become a ubiquitous form of communication between a vat-iety of parties. Email is favored for its low cost and rapid delivery, which nlany people see as a benefit and advantage over traditional mail secvices.
Multipurpose Internet Mail Extension (MIME) is a standard that defines how content such as text and non-text attachments are formatted. It should be noted that altllough MIME defines how the data is str.uctu.red and formatted, it is the Simple Mail Transfer Protocol (SMTP) that defines how email is sent to a server, and how it is sent between servers.
SMTP, for its ubiquity, popularity and general robustness has been considered to be the "killer-app" of the Internet, that is, the application whose utility brought the Intenaet to the atte.ntion of the general public and provided the incentive for beginning a mass adoption of the Internet as a setvice.
As email gained in popularity, its uses expanded and features that were not anticipated by the researchers who developed SMTP have now become desirable if not essential.
One failing in SMTP is the inability to verify the identity of the sender of an ernail message.
So-called spoofrng techniques and the use of open mail relays have allowed entities to transmit email while iinpersonating a sender. This impairs the trust that a recipient of an email message has in the provenance of the message, and diminishes the value of a trust-based system. Despite the ubiquity of email, these issues hamper the utility of email and could be used to reduce the evidentiary weight accorded to email messages in a judicial hearing.
A further problem with SMTP and MIME based email is that there is no robust mechanism to authenticate the content and header information of a message. A nuznber of work around solutions have been developed, but while remedying some of these issues these work around solutions typically introduce additional complexity as well as other related issues.
To understand existing solutions, it is first important to examine how a standard MIME/SMTI' mail session functions. Figure 1 illustrates aii SMTP based email excliange.
User A 100 composes an email niessage using a standard email client A 102.
Client A 102 can be any of a number of standard applications such as Apple Mail, Microsoft Outlook, Mozilla Thunderbird, or another such application. The composed message is addressed to an email address associated with user B 112, and is sent from client 102 to mail server A 104 using SMTP. Client 102 and seiver 104 can be integrated as is the case with web-based email platforms such as hotmail.com, Yahoo Mail, or gmail.com where the client is a web-based interface that has direct connections to the server ar-d may not einploy SMTP.
The email message is then transmitted through Internet 106 to mail seiver B 108 which is associated with the destination email address. Email client B 110 connects to server B
108 using a standard protocol such as the Internet Message Access Protocol (IMAP) or the Post Office Protocol (POP) so that the message can be downloaded. The message is then presented to User B 112.
This implementation does not necessarily provide autllentication of the sender, nor of the content of the email message. Because the content of the message cannot be veriFed as being the same as they were when sent, and the message cannot be authenticated as being sent by a particular user, the message can be repudiated by the sender at a later date.
A public-private encryption key based infrastructure can be employed to mitigate some of the problems associated with the system of Figure 1. Figure 2 illustrates one such example. User A 100 employs a secure email. client A 114 and a private encryption key 116 to sign the body 122 of a message 118. The header 120 of message 118 is not signed as the message 118 is transmitted using SMTP which does not provide a field for a signature that could be used to verify the header infortnation. The message 11.8 with signed message body 122 is transmitted to email server A 104 ttsing SMTP. The message is routed tlirough Intemet 106 to email server B 108 as any message would be in the system of Figure 1. The signed body 122 of message 118 is never inspected along the route as the infrastructure makes use of the standard MIME and SMTP protocols. Secure email client B 124 connects to email server B
108 using a standard protocol such as IMAP or POP and retrieves message 118 Secure email client B 124 niakes use of the public key 126 uniquely associated with private key 116 to veri fy the signature of the body 122 of the received message 118. The verified message 128 is then displayed to user B 112.
One skilled in the art will appreciate that using the public key 126, user B
112 is able to determine that the message body 122 was not tampered with. The signature can include a tiniestainp based on the clock/calendar ftinction of the system ru.nning secure email client A
114. The inessage can be repudiated by the sender, if the public-private key pair (keys 116 and 126) is not associated with User A 100 in a public manner.
To associate the key pair to User A 100, a certificate authority can bind the public key 126 to identifying information associated with User A 100. The certificate binding public key 126 to user A 100 can be sent to user B 112 in advance so that it can be added to a key ring in secure ernail ciient B 124. User B 112 could use public key 1.26 to encrypt a message to User A 100, who would then use private key 116 to decrypt the message. For User B 11.2 to sign any message (encrypted or otherwise) User B would need a different key pair.
Aithough this provides a degree of authentication of the message contents and a limited degree of non-repudiation, it requi.res that User A 100 obtain a certificate binding lcey 126 to him, and requires that User B 112 have a copy of the publ.ic key 126 (and preferably the certifcate) and a secure email client to verify the signature. Although this does not seem like a large burden, it only appears this way because of the limited number of parties in the illustrated transaction. If there are multiple parties, each party will be required to obtain a certificate from a certificate authority, and will be required to transmit the certificate to every other party. Specialized software to manage the ring of public keys, along with the relevant private keys must then be used to allow automated verification. This is a cunZbersome process. As the number of parties grows the number of keys required to allow verification of a message also grows. Furthermore, if the security of private key 116 is compromised, it must be revoked, wluch can otily effectively be done if a certificate autliority issued a certif cate for the key. When a certificate is revoked a cumbersome process must be undertaken by any party holding the compromised key to obtain a new certified key.
A public key infrastructure (PKI) employing a Certificate Authority (CA) does address a nLuiiber of the issues around authenticating the integrity of a message body, but it requires a large number of changes to the email infrastructure as well as an understanding of the complex nature of a PKI . As a result of the added complexity caused, PKI has been slow to gain traction with the broader public though it has proponents in the security field.
One system that has attempted to address these issues is provided through the use of Digital Postmarks. Digital Postmarks are intended for use in an enterprise environment, and are designed to specifically provide authentication of inessage contents.
Fundamentally it is designed as a non-repudiation service. Figure 3 illustrates an exemplary installation of a system to use Digital Postmarking. User A 100 uses a client to generate an email message.
This message is sent from a client to an outgoing mail server 130, typically provided by an enterprise associated with User A 100. Outgoing naail server 130 receives the niessage and forwards it to the digital postmarking server 132. Server 130 preferably signs the message prior to transmission to digital postmarking server 132 so that postmarking server 132 can verify that the message was not altered in transit. Digital postmarking server 132 then validates the authenticity of the signature against a Icnown key associated with either user A
100 or with inail server 130. Upon successful verification., the digital postmarking seiver 132 generates a timestamp that, along with the message, the signature and validation results are stored in a digital postmark non-repudiation database 134. This inforination can then be accessed at a later date to establish a non-repudiation ftinction. The postmarlcs sezver 132 and database 134 generate a digital postmarking receipt that is transmitted back to the outgoing mail server 130. The outgoing mail server 130 wraps the original message in the digital postmarking receipt and traiismits the message to the incoming mail sewer 136.
User B 112 retrieves the message in the proprietary digital postmarking wrapper 138 using a proprietary client 140. The client 140 can then retiieve the authentication information from the digital postmarlc non-repudiation database 134. Client 140 does not need to perform any verification processes on the message itself, as the verification, receipt and even the original document can. be retrieved from database 134, alternately a local cryptographic verification can be performed by client 140.
Although the digital postmarking system discussed with relation to Figure 3 can provide both authentication of a sender and the message, it requires proprietary software, and is cumbersome. The system is designed for implementation in an enteiprise environnlent, and does not take into account the needs of individuals. The digital postmarking server 132 is often dedicated to a particular outgoing mail server 130. As such digital postmarking server 132 requires that the enterprise obtain a dedicated hardware device and inZplement a complex process of having either client software sign a message or having the mail server 130 sign a message prior to beginning the verification process. The storage requirements for database 134 can be immense if all messages and attachments are stored for a number of different organizations. As such, the verification information is typically only stored for a predefined period. If this period expires, the ability to authenticate the message can be adversely affected.
To provide a mechanism for secure email, without needing a proprietary infrastructure, an ei-diancement to the MIME standard entitled Secure/MIME (S/MIME) has been introduced.
S/MIME defines a fonnat for a signed or encrypted message that requires that the verification information be included in the message in a particular fashion.. S/MIME
fitnctionality has been incorporated into most common modem email clients as its implementation is not conlplex and can be used to provide authentication of the message contents using digital signatures (non-repudiation is provided if a certificate is employed) as well an encryptian functionality. In operation, an S/MIME client will encrypt the message body and transmit the resulting object as a MIME attachment (specifically an application/pkcs7-mime MIME
entity). One advantage of S/MIME is that standard mail servers are used, tlius requiring no additional infrastructure.
For a user to make use of an S/MIME compliant client, an individual key or certificate must be obtained (preferably from a certificate authority). To encrypt a message, the recipient's public key must be known, whereas for signing, the recipient must have access to the sender's public key to allow for verification. By using a basic certificate, the only identifying information bound to the key (and thus the signed message) is an email address. To associate additional information, such as actual individual identity information, a certificate must be provided by a CA that has verified the identity infoiTnation. The certificate is then typically publicly available from the CA, and at a mininlum a certificate serial nurriber is made available to allow for revocation of a certificate (as described above witli respect to an encryption based mail client).
Figure 4 illustrates an S/MIME compliant exchange. One skilled in the art will appreciate that this makes use of a PKI infrastructure, and thus bears similarity to the encryption based signature system described earlier. A user 100 employs an S/MIME compliant email client A
142, to create a digitally signed email message 144 using private key 116. The message is sent to email server A 104 using SMTP and is then routed tluough Internet 106 to email server B
108. The digitally signed email message 144 is retrieved by S/MIME client B
124. S/MIME
client B 124 can parse message 144, wluch has a structure defined by the S/1VIIME standards.
As such, if the message has been encrypted, the encrypted package is provided in the application/pkcs7-mime MIME entity. Similarly, a defined entity is used for storing the cryptographic signature used to ensure data integrity (application/(x-pkcs7-signature).
Upon generation of the signature at client 142, the public key used to sigit the message is identified by the serial nutnber and certificate issuer. This allows the recipient to retrieve the cei-tificate to obtain the key to verify the signature. The certificate binding the user information to the key provides non-repudiation. However, it should be noted that at a later date if the certificate expires and is deleted, verification of the message can no longer be performed, reducing the archival qtialities of the verification process. When a certificate expires, a new certificate is often generated, even if the sanie key pair is used. This often leads users to assume that the old certificate can be deleted. Recipients often delete downloaded cei-tificates when they notice that a sender has multiple certificates, which can cause unexpected inability to verify signatures.
Because the signature is carried separate from the body of the message (in contrast to many other signattire implementations) mailing list software that changes the message body often resttlts in the invalidation of the signature. Addi.tionally, because message attachments may be encrypted using S/MIME, the ability of a server to perfomi scans to detect malware such as worms or virii is adversely affected. Stich scanning can only be perfomied at the client side, which is often too late in the process.
One skilled in the art wil.l appreciate that though there are many systems for providing digital signatures on email messages to allow for verification of the integrity of the message body, they all introduce a number of different layers of complexity. Addition of authenticated time stamping functionality is difficult to provide without the addition of additional server side hardware, much as the ability to authenticate the sender of a message requires the cumbersome management of encryption keys.
It is, therefore, desirable to provide a mechanism providing trusted authentication of a message and its contents.
SUMMARY OF THE INVENTION
It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.
In a first aspect of the present invention, there is provided a method providing tn.isted third party verification of an electronic message. The method comprises the steps of receiving the electronic message from a sender addressed to at least one recipient;
processing the electronic message to determine a digital signature associated with both the electronic message and a ptiblicly accessible key not associated with the sender of the electronic message; attaching the detei-mined digital signatLtre to the electronic message; and transmitting the electronic message with the attached digital signature to the at least one recipient.
In an embodiment of the first aspect of the present invention, the step of processing the message includes determining the digital signature by encrypting a cryptographic hash of the electronic message, possibly just the body of the electronic message, using the private portion of a private-public key pair. In another embodiment, the step of processing the electronic message can incltide overwriting header values such as time and date values in using verified header values (e.g. verified time and date values).
In a further embodiment of the present invention, the step of processing the electronic message includes performing a virus scan of the electronic message, and optionally removing a virus identified by the vinis scan. In another embodiment, the step of processing the electronic message can include copying header information from the electronic message into the electronic message body prior to determining the digital signature. In yet another embodiment of the first aspect of the present invention, the step of attaching the deterniined digital signature includes attaching the digital signature as a Secure Multipurpose Liternet Mail Extensions compliant digital signature.
In another embodiment of the first aspect of the present invention, the method can further include the step of authenticating an account associated with the sender of the electronic message after i-eceiving the electronic message. Authentication of the account can include receiving authentication credentials from the sender of the electronic message and verifying the credentials against known data. The receipt of authentication credentials can include receiving login credentials from the sender in accordance to the Simple Mail Transfer Protocol Authentication standard. In another embodiment, the step of authenticating includes verifying an address in a From: field in a header to the electronic message against a lcnown value.
In fiirther embodiments, the method can include billing an entity associated with the sender of the email message, and the message can be a Multipurpose Internet Mail Extensions based eniail message.
In a second aspect of the present invention, there is provided a trustworthy processor for providing verification of an electronic message, sent by a sender, to at least one recipient of the electronic message. The processor comprises a message interface and a signature engine.
The message interface receives electronic messages from the sender and transmits messages to the at least one recipient after processing by the signature engine. The signature engine signs the received message using a signature not associated with the sender to allow the at least one recipient to verify that the message .has not been altered and forwards the signed message to the at least one recipient through the message interface.
In an embodiment of the second aspect of the present invention, the message interface is a Simple Mail Transfer Protocol interface. In another embodiment of the second aspect of the present invention, the processor further includes a message processor for overwriting values in a header of the message with verified values, for copying the contents of the header into a message body prior, and for forwarding the modified message to the signature engine for signing. The message processor can also include a timestamping unit for overwriting the time and date of values in the header with verified time and date values. The message processor can also optionally include a sender verification unit for overwriting FROM
values in the header with verified name and email address values.
In a fuc-ther embodiment, the signature engine can include a dedicated cryptographic engine for digitally signing the message using a cryptographic key.
In another embodiment of the second aspect of the present invention, the processor fiirther includes an account authenticator for authenticating the identity of the message sender pr.ior to transmission of the signed message to the at least one recipient, and optionally includes a billing processor for assessing a charge to an account associated with the authenticated identity of the message sender.
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:
Figure 1 is a block diagram illustrating the data flow in a prior art messaging process;
Figtire 2 illustrates the data flow in a prior art cryptographic signature based messaging process;
Figure 3 illustrates the data flow in a prior art digital postmarking based messaging process;
Figure 4 illustrates the data flow in a prior art S/MIME based messaging process;
Figure 5 is a block diagram illustrating a data flow involving trustworthy processing of electronic messaging;
Figure 6 is a flow chart illustrating a method of trustworthy processing;
Figure 7 is a flow chart illustrating a method of authenticating an account in a trustworthy processing method;
Figure 8 is a flow chart illustrating a method of message processing in a trustwortlty processing method;
Figure 9 is a flowchart illustrating a metliod of billing in a trustworthy processing method; and Figure 10 is a block diagram illustrating logical elements of a trustworthy processor of the present invention.
DETAILED DESCRIPTION
The present invention is directed to a system and method for electronic messaging with a simplified authentication and message integrity verification mechanism.
Reference nlay be made below to specific elements, numbered in accordance with the attached figures. The discussion below should be taken to be exemplary in nature, and not as limiting of the scope of the present invention. The scope of the present invention is defined in the claims, and should not be considered as limited by the implementation details described below, which. as one skilled in the art will appreciate, can be modified by replacing elements with equivalent ftinctional elements.
In the present invention, the troubles associated with user management of a PKI key ring are mitigated by the use of a single digital signature for verifying the contents of messages from any of a number of different individuals. This signattire is associated with a trusted tliird party. Instead of relyuig on a user to obtain a certificate from a CA, the user obtains an account with a trusted third party that processes messages and performs the signature process on behalf of the user. The recipient of the message can tnist that the message was verified. by the trusted third party, and that the third party performed a publicly defined autlientication of the user. Thus, users do not need to obtain certificates, and recipients do not need to manage large and tulwieldy key rings. Additional services such as time stamping, sender authentication and virus scaiming can also be offered.
Because users are authenticated prior to the signed message being transmitted to recipients, a billing process can be implemented. The authentication and optional billing also reduce the likelihood that a message is unsolicited commercial email. As a result, the messages processed by the seiver can be trusted to a higher degree, allowing them to bypass so-called SPAM filters. Other benefits of the present invention will be discussed below with relation to the illustration of an exemplary system and method. One skilled in the art will appreciate that the description below is intended to be exeinplary in nature and should not be regarded as liniiting the scope of the present invention.
Figure 5 illustrates an architecture in which the present invention can be implemented. Two different types of senders are considei-ed, those in an enterpi-ise environment, and those who do not have access to such a system. Corporate Sender 200 creates an email message 204 using client A 202. The message 204 can. include attachments, but there is no requirement that attaclunents be appended to the message. The message is transmitted to the corporate mail seiver 206. Sender 200 is authenticated by corporate mail server 206. The message can either be flagged for sending as conventional email, or it can be flagged to be sent as a trusted third party signed message. The flagging of the message can be done at the client 202, or using corporate rules enforced by server 206. When a message is to be signed by the trusted third party, it is routed from seiver 206 to a trustworthy processor 208.
To provide service to individual users, the present invention can be accessed by individual users much as any other mail server would be used. An individual sender 200a composes a message 204a on client A' 202a. When the message is to be sent, it is relayed to trustworthy processor 208 through Internet 106. Connections to tnastworthy processor 208 from either client A' or from server 206 can be made using a conventional protocol such as SMTP with Transport Layer Security (TLS) for enhanced confidentiality and integrity of communication with the trustworthy processor 208 if so desired. This allows for existing infrastructure to be used without requiring either individuals or enterprises to update their software or hardware.
One skilled in the art will appreciate that Client A' 202a can be a web-based mail client without departing from the scope of the present invention.
Trustworthy processor 208 can perform a number of different processes on received messages. It preferably begins by authenticating the party initiating the session. In the case of an individual user, such as sender 200a, the authentication can be done using standard techniques such as SMTP-Aut11 or POP before SMTP. In the case of enterprise access, the enterpt-ise server 206 can be authenticated using any of a number of luiown techniques. The uset=s of enterprise mail server 206 are authenticated by seiver 206, and the server authentication of the user can then be passed along to trustworthy processor 208 en lieu of individual authentications.
Authentication of a user is done so that the trustwortliy processor can provide user authentication and non-repudiation. After authenticating the user, the ttlistworthy processor can ensure that the message header includes the correct infar.mation associated witlz the user account. The header information can optionally be copied into the body of the email so that it is signed. In conventional systems, the body of the email message is the only portion of the message that is signed. This is done to allow the message to be easily routed using the existing SMTP infrastructure; however, it causes the drawback that the sender and recipient information is n.ot signed. By copying header information into the body of the message, it can be signed along with the message body. The trustworthy processo:r 208 then signs the message, preferably using a standard based format, such as S/MIME, using the private portion of the postmarking key pair 210. The signed message is then transmitted to the addresses recipients, and is received by recipient mail seiver 212. The signed message 214 is retrieved by S/MIME email client B 216. The signed message 214 can be verified by client B 216 using the public portion of the postmark key pair 210. The verified message 218 can then be displayed to the recipient 220.
Before digitally siDung message 204 or 204a, trustworthy processor 208 can modify the message body to add in additional content including branding information designed to provide an immediate syi-nbol that recipients can associate with an assurance that the message was signed by a trusted third party.
Figure 6 is a flowchart illustrating a method of the present invention carried out by a trustworthy processor. The process starts when the processor receives a mail message for processing. The user account is authenticated in step 250. Upon successful authentication of the user, the message is processed in step 252. This processing step can include value added functionality, but also ineludes the d.etermination of a digital signature based on the content of the received message. The trusted third party signature deteri.nined in step 252 is attached to the message in step 254. This is preferably done in compliance with the foimat defined in the S/MIME standard. In the final step of the process, the message is transmitted to the addressed recipients.
In contrast to prior art methods, the signature applied is the signature of a trusted third party, not the signature of the sender. By making use of existing infiastructure, such as the S/MIME
infrastructure, the present invention can provide a foi-in of user authentication, message integrity verification and time stamping without requiring additional hardware installed in an enterprise, and without requiring users to make use of proprietary email clients to read or conzpose email.
In Figure 6, the first step is authenticating the account associated with an incoming message 250. The authentieation, of an account can be carried out using a nuniber of optional steps as illustrated in the flow chart of Figure 7. In step 258, the authentication credentials are received, and they are verified in step 260. This can be done by having the tnistworthy processor malce use of standard authentication mechanisms such as SMTP-Auth or POP
before SMTP. Other authentieation techniques can be employed, especially where the connection is received from an enterprise mail seiver. When an enterprise server connects, it can do so on behalf of an individual user, or can do so on behalf of the enterprise, with the trustworthy processor identifying individual information on the basis of the email address of the From: field in the message.
The tnistworthy processor may also elect to verify the From: field against addresses associated witll the verified authentication credentials. If the From.: field is not verified, the processor can. generate an error inessage, or optionally it can oveitivrite the From: field in the message. By performing a verification of the From: field, a further security barrier is provided, which can be important if the processor is intended to be able to airthenticate the sender information.
Upon finishing any or all of these steps, the process continues to step 252.
A brealcdown of optional steps in the processing of the message in step 252 is provided in the flowchart of Figure 8. One skilled in the art will appreciate that a number of these steps are optional as they provide added value to the system and method of the present invention, but are not essential for the operation of the system. After cornpleting step 250, the time and date associated with tlie message can be overwritten in step 264. This effectively embeds a timestamp in the message header that can be trusted by the recipient. The From Name field in the message can be overwritten with a name associated with the account if it does not match in step 266. In one simplified implementation, regardless of the From name field value, the name is overwritten to ensure that all messages are handled in the same fashion. In step 268 a virus scan of the message contents and any attachments can be performed. By perfomiing this scan, malware and inappropriate content can be identified and removed, or the message can be rejected and the user informed of a problem. By performing the scan before signing the message, the signature will still be valid. Server side scanning at either the sender or recipient .mail server in prior art implementations results in invalidating the signature if virii are to be removed when identified, which defeats the purpose of providing authenticated email.
In step 270, the header information of the message is copied into the body of the message.
This allows the To: From: Date: and Subject: information, along with other header information, to be incorporated into the body of the message before it is signed. Because earlier processes allow for the overwriting of name fields, time and date values and other infonnation to ensure that they are accurate, this information can. be sigiied along with the message body. This allows the recipient to archive the message and have non-repudiable evidence as to when a message was sent, who sent it and what it contained, without needing to consult an exteinal archive. The verification can be guaranteed so long as access to the cet-tificate of the trustworthy processor is available.
In step 272, a digital signature is generated using a private key associated with a public key stored in a publicly available certificate. The signature can be generated using conventional processes used over the entire message body. This digital signature is the trusted third party signature attached in step 254.
Because the sender inforination is verified before the message is transmitted to the addressed recipients, a billing process can be added to the method illustrated in Figure 6. One sueh process is illustrated in the flowchart of Figure 9. After the account verification process, the billing information associated with accaunt is processed as illustrated in step 274. A number of different implementations of a billing process can be employed. For exemplary purposes, a method is illustrated in Figure 9. In this exemplary method, the account is verified as being in good staiiding in step 276. The cost of the rnessage verification and signature is deternrined in step 278 and is transmitted to the accounting system in step 280. The process may require a response from the accounting system before proceeding if it is based on prepaid credits, or can be allowed to immediately proceed in other cases. The determination of the cost can be done using any of a number of different models, including either flat rate billing systems that bill a fixed amount per message, or a per-byte charge that is determined based on the size of the message. The specific implementation can be varied without departing from the scope of the present invention.
Figure 10 is a block diagram illustrating an implementation of the system of the present invention as fiinctional elements. One skilled in the art will appreciate that the fimction of a particular element can be spread across a number of other logical elements, or two or more logical elements illustrated in this diagram could be combined in one logical unit. The trustworthy processor 208 receives communications 282 from clients (either directly or thz=ougll a registered enterprise server) that contain botli mail messages and account credentials. The comniunications are received by an inbound mail interface, such as the illustrated inbound SMTP interface 284. The account credentials are forwarded to the account authenticator 286 and to the optional billing processor 288 if present. The account authenticator 286 authenticates the communication as being frotn a valid user account using any of a number of known techniques including those discussed above. The mail message is provided to both the billing processor 288 if present and the message processor 290. The billing processor 288 can be used to determine if a valid account is in arrears before a message is processed. It also can be used to detennine the cost associated with handling each i-eceived message. The billing processor 288 can be in communication with an accounting system (not shown) so that accurate billing inforniation can be recorded and invoiced. The message processor 290 processes the message after receiving the go ahead from both the account autlaenticator 286 and the billing processor 288. The message processor is not essential and can be omitted if the sole function of trustworthy processor is to obtain a trusted third party verification of the message contents. If added value setvices including time stamping, non-repudiable authentication of the message sender, virLts scanning and embedding of the header in the message body are to be provided they can be provided by the message processor 290. After the message processor 290 (or directly from the inbound SMTP
Interface) the message is provided to the signature engine 292 which uses the private portion of the postniarking key pair 210 to generate a signature that can be used to verify the contents of the message body. This signature is preferably 1landled in accordance with the S/MIME
standards when attached to the message. Signature engine can be a general purpose processor, or can optionally include a specific cryptographic engine designed for compu.ting cryptographic signatures of messages using key 210. The signed message is then provided to outbound SMTP interface 294 which transmits the message to the addressed parties.
Embodiments of the invention may be represented as a software product stored in a machine-readable medium (also refetred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied tllet-ein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, chemical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable nzedium nlay contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perfonn steps in a niethod according to an embodiment of the invention. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention may also be stored on the machine-readable medium. Software running fi=om the machine-readable medium may interface with circuitry to perfoim the described tasks.
The above-described embodiments of the present invention are intended to be examples only.
Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing frorn the scope of the invention, which is defined solely by the claims appended hereto.
Claims (23)
1. A method of providing trusted third party verification of an electronic message comprising:
receiving the electronic message from a sender addressed to at least one recipient;
processing the electronic message to determine a digital signature associated with both the electronic message and a publicly accessible key not associated with the sender of the electronic message;
attaching the determined digital signature to the electronic message; and transmitting the electronic message with the attached digital signature to the at least one recipient.
receiving the electronic message from a sender addressed to at least one recipient;
processing the electronic message to determine a digital signature associated with both the electronic message and a publicly accessible key not associated with the sender of the electronic message;
attaching the determined digital signature to the electronic message; and transmitting the electronic message with the attached digital signature to the at least one recipient.
2. The method of claim 1 wherein the step of processing the message includes determining the digital signature by encrypting a cryptographic hash of the electronic message using the private portion of a private-public key pair.
3. The method of claim 2 wherein the digital signature is a cryptographic digital signature of the body of the electronic message.
4. The method of claim 1 wherein the step of processing the electronic message includes overwriting values in a header to the electronic message with verified values.
5. The method of claim 4 wherein overwriting values in the header includes overwriting time and date values in the header using verified time and date values.
6. The method of claim 1 wherein the step of processing the electronic message includes performing a virus scan of the electronic message.
7. The method of claim 6 further including the step of removing a virus identified by the virus scan.
8. The method of claim 1 wherein the step of processing the electronic message includes copying header information from the electronic message into the electronic message body prior to determining the digital signature.
9. The method of claim 1 wherein the step of attaching the determined digital signature includes attaching the digital signature as a Secure Multipurpose Internet Mail Extensions compliant digital signature.
10. The method of claim 1 further including a step of authenticating an account associated with the sender of the electronic message after receiving the electronic message.
11. The method of claim 10 wherein the step of authenticating the account includes receiving authentication credentials from the sender of the electronic message and verifying the credentials against known data.
12. The method of claim 11 wherein the step of receiving authentication credentials includes receiving login credentials from the sender in accordance to the Simple Mail Transfer Protocol Authentication standard.
13. The method of claim 10 wherein the step of authenticating includes verifying an address in a From: field in a header to the electronic message against a known value.
14. The method of claim 1 further including billing an entity associated with the sender of the email message.
15. The method of claim 1 wherein the electronic message is a Multipurpose Internet Mail Extensions based entail message.
16. A trustworthy processor for providing verification of an electronic message, sent by a sender, to at least one recipient of the electronic message, the processor comprising:
a message interface for receiving the electronic message from the sender; and a signature engine for signing the received message using a signature not associated with the sender to allow the at least one recipient to verify that the message has not been altered, and for forwarding the signed message to the at least one recipient through the message interface.
a message interface for receiving the electronic message from the sender; and a signature engine for signing the received message using a signature not associated with the sender to allow the at least one recipient to verify that the message has not been altered, and for forwarding the signed message to the at least one recipient through the message interface.
17. The processor of claim 16 wherein the message interface is a Simple Mail Transfer Protocol interface.
18. The processor of claim 16 further including a message processor for overwriting values in a header of the message with verified values, for copying the contents of the header into a message body prior, and for forwarding the modified message to the signature engine for signing.
19. The processor of claim 18 wherein the message processor includes a timestamping unit for overwriting time and date values in the header with verified time and values.
20. The processor of claim 18 wherein the message processor includes a sender verification unit for overwriting FROM values in the header with verified name and email address values.
21. The processor of claim 16 wherein the signature engine includes a dedicated cryptographic engine for digitally signing the message using a cryptographic key.
22. The processor of claim 16 further including an account authenticator for authenticating the identity of the message sender prior to transmission of the signed message to the at least one recipient.
23. The processor of claim 22 further including a billing processor for assessing a charge to an account associated with the authenticated identity of the message sender.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2641728A CA2641728A1 (en) | 2008-10-15 | 2008-10-15 | Trusted third party authentication and notarization for email |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2641728A CA2641728A1 (en) | 2008-10-15 | 2008-10-15 | Trusted third party authentication and notarization for email |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2641728A1 true CA2641728A1 (en) | 2010-04-15 |
Family
ID=42110370
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2641728A Abandoned CA2641728A1 (en) | 2008-10-15 | 2008-10-15 | Trusted third party authentication and notarization for email |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2641728A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107995616A (en) * | 2016-10-27 | 2018-05-04 | 中国电信股份有限公司 | The processing method and device of user behavior data |
-
2008
- 2008-10-15 CA CA2641728A patent/CA2641728A1/en not_active Abandoned
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107995616A (en) * | 2016-10-27 | 2018-05-04 | 中国电信股份有限公司 | The processing method and device of user behavior data |
| CN107995616B (en) * | 2016-10-27 | 2021-05-18 | 中国电信股份有限公司 | User behavior data processing method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20100100465A1 (en) | Trusted third party authentication and notarization for email | |
| US9634843B2 (en) | Apparatus and methods for the secure transfer of electronic data | |
| US6584564B2 (en) | Secure e-mail system | |
| US7325127B2 (en) | Security server system | |
| US8359360B2 (en) | Electronic message system with federation of trusted senders | |
| US8560655B2 (en) | Methods and apparatus for controlling the transmission and receipt of email messages | |
| US7277549B2 (en) | System for implementing business processes using key server events | |
| US20060053280A1 (en) | Secure e-mail messaging system | |
| US20040151323A1 (en) | Implementing nonrepudiation and audit using authentication assertions and key servers | |
| US20030028494A1 (en) | Electronic document management system and method | |
| US20090319781A1 (en) | Secure message delivery using a trust broker | |
| EP1701494B1 (en) | Determining a correspondent server having compatible secure e-mail technology | |
| JP2004521404A5 (en) | ||
| KR102083313B1 (en) | Method for the registration and certification of receipt of electronic mail | |
| EP1678666A2 (en) | Storage and authentication of data transactions | |
| MX2010007507A (en) | Signature method and device. | |
| KR102015386B1 (en) | Method for certifying the sending of electronic mail | |
| US20080034212A1 (en) | Method and system for authenticating digital content | |
| Al-Hammadi et al. | Certified exchange of electronic mail (CEEM) | |
| JP2001042769A (en) | Communicating method for electronic data, repeating server and recording medium | |
| CA2641728A1 (en) | Trusted third party authentication and notarization for email | |
| ZA200102154B (en) | A secure data transfer system. | |
| KR20160094726A (en) | Method for producing electronic contracts certified by a user of a telecommunications operator | |
| KR20050024765A (en) | System and Method for Blocking Spam Mail | |
| WO2014054009A1 (en) | Secure email messaging system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |
Effective date: 20150226 |