The invention relates to the field of software, and more particularly to rights management for digital documents.
The field of Document Rights Management (DRM) has long been hampered by the complications of configuring cumbersome DRM software, and by the constraints imposed by existing DRM packages, which require senders and recipients to agree on DRM protocols and software in advance of any controlled communication. In standard DRM systems, a sender utilizing the DRM system may only control documents sent to a recipient if the recipient has, in advance of the document transfer, installed a reader for the particular DRM system. This limitation of existing DRM systems precludes a sender from controlling a document forwarded to an arbitrary recipient. Indeed, to ensure that the document will be both controlled and secure, the current state of the art forces the sender to ensure through an independent channel that the recipient has installed the appropriate software for reading the document. Otherwise, any controlled document forwarded to an uninitiated recipient is merely noise.
The inadequacies of existing DRM systems, in which senders and recipients must agree on a particular DRM package prior to the initiation, is further exacerbated by the multiplicity of existing DRM systems. The current art lacks a standard protocol or software package for DRM; users with mismatched DRM systems are precluded from controlling messages transferred amongst themselves.
The inadequacies of the existing internet infrastructure with respect to Digital Rights Management is be illustrated by the limitations of existing e-mail systems. The e-mail protocols currently deployed on the Internet—such as Multi-Purpose Internet Mail Extensions (MIME), and Simple Mail Transport Protocol (SMTP), as well as server protocols deployed for e-mail communication, such as Internet Message Access Protocol (IMAP) or Post Office Protocol 3 (POP3)—do not include provisions for controlling e-mails forwarded between senders and recipients. Thus any document control between senders and recipients of e-mail can only be undertaken by use of higher level applications, which have been agreed to in advance by the sender and recipient. Thus, a sender who wishes to send an e-mail message, to an arbitrary recipient, in a manner which disables certain operations on the e-mail message, has no tools available to facilitate this type of exchange.
In view of the limitations of the current art, there is a need for transparency in Document Rights Management Systems, to alleviate the complexity in installation and configuration of current DRM technology. Such Document Rights Management tools should also utilize existing communications infrastructure.
Additionally, there is a need for tools which facilitate control over documents forwarded to arbitrary users.
These and other inadequacies in the prior art are addressed by the inventor described herein.
The invention comprises systems and methods of Digital Rights Management, which allows documents to be controlled by a sender, in a manner which is transparent to any end recipients. Embodiments of the invention include mechanisms enabling a sender to control documents sent to a recipient, in a manner that (1) encrypts the message to ensure its security, and (2) restricts operations the recipient may perform on the received message; this mechanism is transparent, in that the recipient and sender need not agree on a control protocol in advance of the communication.
Embodiments of the invention also include techniques for facilitating wide distribution of a Digital Rights Management System, in a manner which does not compromise the security of the DRM system. This distribution may be facilitated by use of self-installing modules, which integrate with existing software used for document publishing and retrieval. These modules may be forwarded to unregistered recipients upon authentication of the recipient, and may, upon acceptance by the recipient, install automatically on the recipient's computer. Accordingly, these self-installing modules leverage pre-existing software and communications infrastructure to facilitate controlled, secure communications.
In embodiments of the invention, the controlled document may comprise an e-mail message; the invention allows a sender to forward a controlled message via e-mail to an arbitrary user, and ensure that the user may read the controlled message transparently. In some such embodiments, the control mechanism comprises a plug-in module to the sender's otherwise standard e-mail composer; in embodiments, this plug-in module may be self-installing.
In embodiments of the invention, upon creation of the controlled message by the sender, a lookup is performed for the recipient, to determine whether or not the recipient is a registered user of the transparent DRM system. If the recipient's e-mail address is not located in the registry, this is indicative that the recipient does not have software configured to decode the secure e-mail. In some embodiments, a certificate may be generated automatically for the recipient and forwarded to the sender's e-mail client; this message may be encrypted by reference to the recipient's new certificate.
In embodiments of the invention, if the recipient is not located in a registry of the DRM system, an invitation may be forwarded to the recipient to read the attached message; the message may include an invitation to download an add-in enabling him to read the controlled document. If the recipient elects to receive the message, the invention facilitates a download of add-in software to the recipient's e-mail reader. In embodiments of the invention, the add-in software is designed for self-installation and for integration with the recipient's original e-mail reader. Upon installation and integration of the add-in to the recipient's e-mail reader, the message is controlled per the instructions of the sender.
These and other embodiments are elaborated in greater detail infra.
The invention comprises systems and methods for enabling documents to be controlled by a sender, in a manner which is transparent to any end recipients.
Embodiments of the invention include mechanisms enabling a sender to control an e-mail message sent to an end recipient, in a manner that restricts operations the recipient may perform on the received message; this mechanism is transparent, in that the recipient and sender need not agree on a control protocol in advance.
An illustrative example of the invention is depicted in the use case of
Alice instructs the e-mail composer to send the message securely to Bob. In embodiments of the invention, this prompts the add-in component to perform lookup Bob's e-mail address (bob@R.com) 106; in embodiments of the invention, the request for the lookup by Alice is signed. If the corresponding e-mail address to Bob is not located on a registry, a response is sent back to Alice. In embodiments of the invention, a certificate for Bob may be generated and forwarded to Alice in the response. The message is encrypted by reference to Bob's new certificate. Subsequently, an invitation to Bob to read the message is attached, and the message and signed by Alice 112. The revised message is then forwarded directly to Bob 114. In embodiments of the invention, if it is determined that Bob does not have appropriate certifications or software to read the message, the message may include an invitation to download an add-in enabling him to read the encrypted software. In some nonlimiting embodiments, this invitation may be encoded in a markup language, such as, by way of non-limiting example, HTML.
A corresponding use-case for Bob is illustrated in
If Bob elects to receive the message 200, Bob may click on a URL embedded in the message 202. The URL links to a proprietary DRM server 210, which facilitates a download of the add in software to Bob's e-mail reader 204. The DRM add-in software is designed for self-installation and for integration with Bob's original e-mail reader. Alice's and Bob's certificates are extracted and installed, and the unencrypted message is displayed 208.
The document control features available to an author of a message 400 are illustrated if
In embodiments of the invention, an add-in to the sender's e-mail composer may include a Graphical User Interface as illustrated in
The control options available to the author include:
Viewing the Message
The author has the alternative not to control the message, in which case the ordinary behavior of the e-mail reader is observed. If the message is controlled, the message can be opened and read if the local mail address matches one of the recipient addresses. In embodiments of the invention, this behavior obtains irrespective of the GUI representations of opening and viewing e-mails. These GUI representations may include by way of non-limiting examples, clicking on a message header to display a message in preview pane; double-clicking a message header to open a message window; and opening a saved e-mail document.
Cut or Copy
If the message is not controlled, the ordinary behavior of the e-mail client is observed. If the message is controlled, the message contents cannot be extracted by cut, copy, or drag and drop operations.
If the message is not controlled, the ordinary behavior of the e-mail client is observed. If the message is controlled and print is enabled, the message can be printed. In embodiments of the invention, the printed message is watermarked with this recipient's e-mail address. If the message is controlled and print is disabled, the message cannot be printed.
Forward
If the message is not controlled, the ordinary behavior of the e-mail client is observed. However, if the message is controlled, the message cannot be forwarded by the recipient.
Save
If the message is not controlled, the ordinary behavior of the e-mail client is observed. In some embodiments, if the message is controlled, the message cannot be saved in clear text; in some embodiments, the message may be saved in encrypted format. In other embodiments, the save option in the e-mail reader and or operating system are disabled.
Save Attachments
If the message is not controlled, the normal behavior of the e-mail client is observed. If the message is controlled, attachments to the message cannot be saved.
Architecture of the Transparent Document Control Mechanism
In embodiments of the invention, the transparent control of e-mail messages is enabled by a software architecture comprised of components, which are responsible for concealing cryptographic, protocol, and control issues from application-specific issues such as display, event management, and the user experience.
In embodiments of the invention, the Event Manager 604 is responsible for trapping any events at the e-mail reader which could allow the replication of clear data. These events include application level operations such as cut, copy, paste, save, save-as, print, send, and forward; relevant events also include low-level events occurring in the operating system, such as mouse clicks, keystrokes, or other interrupts.
In embodiments of component architecture 600, The Display Manager 602 is responsible for several functions, including:
The Protocol Manager 606 handles the arrival of e-mail messages which may be controlled per the mechanism of the present invention.
In embodiments of the invention, the message format further includes text encoded in a markup language 706; non-limiting examples of such markup languages include Hyper Text Markup Language (HTML). By way of non-limiting example, the HTML text may comprise an invitation to download an add-in to the recipient's e-mail reader. In some such embodiments, the HTML text may include a signed URL which links to a site for download of the add-in. The message also includes one or more digital certificates, for authenticating the message. Finally, the message includes the original message in encrypted format 710, for decryption by the recipient.
The encrypted message format 710 is elaborated upon in
The message may further include a signature from the sender 804, and a length key 806. In some embodiments of the invention, the message includes a field 808 indicating a hash that may be used; non-limiting examples of such hashes include the many instantiations of the Secured Hash Algorithm (SHA). In embodiments of the invention, the message may also include a length for the Hash 810, a value for the hash 812, and a signature for the hash 814. The message further includes a payload, or data field 816: the data field maybe further comprised by subfields including the length of the encrypted data, an identifier for an encryption algorithm used, and the encrypted data itself.
Embodiments of the invention include numerous protocols for communication between senders and recipients of controlled messages. The protocols described herein are for illustrative purposes only; many equivalents and alternatives shall be apparent to those skilled in the art.
Sender-Side Protocols
Upon receipt of Bob's certificate, a one time key K is created 912 for the message M. The message M is encrypted with K to generate an encrypted message E 914. The encrypted message E can be hashed to generate a hash H 916, and then signed by Alice to generate a signature S 918. The one-time key K can then be encrypted with Bob's public key to generate an encrypted vector BK 920, and a signed Invitation I can be generated for Bob to read the message 922. Alice's digital certificate AC may also be added to the message 924. At the end of the process, an e-mail is forwarded to Bob 926, containing the encrypted message E, the hashed encrypted message H, the signed hashed message S, the key K encrypted with Bob's public key BK, a signed invitation 1, and Alice's digital certificate AC.
Recipient-Side Protocols
Embodiments of the invention include protocols which enable controlled message to be received and read by new recipients transparently.
The process commences when Bob clicks on the invitation I; in non-limiting embodiments of the invention, this invitation I embeds a URL. In some such embodiments, this causes Bob's e-mail client to post a message to the third party server. In non-limiting embodiments, this post may take place over a secure protocol, such as HTTPS. An executable for the add-in is downloaded from the third party server to Bob's client, along with a one-time key. The add-in self-installs on Bob's client.
Once the add-in has installed, known certificates are forwarded from the client to the Security Server. The secured e-mail generated by Alice 926 is then sent to Bob's client. In response, two actions are taken on the client side. First, a certificate message is opened on the client side. A command is sent to the Protocol Module to open the message, and a message is sent to the cryptographic module to validate the decryption. Once Bob's certificate is installed, Alice's message is opened. Again, a command is sent to the Protocol Module to open the message, and again, the decryption is validated by the Cryptographic module. Alice's certificate is installed, and the message from Alice is decrypted.
Once the add-in has been installed through the procedure above, Bob can read any subsequent messages transparently, simply by clicking on the message.
The underlying processes enabling the transparent receipt of messages is illustrated in
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
This application claims priority to U.S. Provisional Patent Application No. 60/364,982, filed Mar. 14, 2002, U.S. Provisional Patent Application No. 60/397,597, filed Jul. 23, 2002, U.S. Provisional Patent Application No. 60/420,313, filed Oct. 23, 2002, and U.S. Provisional Patent Application No. 60/432,866, filed Dec. 11, 2002, all of which are hereby incorporated by reference in their entirety.
Number | Date | Country | |
---|---|---|---|
60364982 | Mar 2002 | US | |
60397597 | Jul 2002 | US | |
60420313 | Oct 2002 | US | |
60432866 | Dec 2002 | US |