+

WO2002039224A2 - Procedes relatifs a un environnement partage securise - Google Patents

Procedes relatifs a un environnement partage securise Download PDF

Info

Publication number
WO2002039224A2
WO2002039224A2 PCT/US2001/046818 US0146818W WO0239224A2 WO 2002039224 A2 WO2002039224 A2 WO 2002039224A2 US 0146818 W US0146818 W US 0146818W WO 0239224 A2 WO0239224 A2 WO 0239224A2
Authority
WO
WIPO (PCT)
Prior art keywords
information
rules
digital information
sender
email
Prior art date
Application number
PCT/US2001/046818
Other languages
English (en)
Other versions
WO2002039224A3 (fr
Inventor
Robert P. Weber
Timothy J. Murray
Original Assignee
Aspsecure Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Aspsecure Corporation filed Critical Aspsecure Corporation
Publication of WO2002039224A2 publication Critical patent/WO2002039224A2/fr
Publication of WO2002039224A3 publication Critical patent/WO2002039224A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Definitions

  • the present invention generally relates to methods for controlling the delivery of digital information and for controlling the manipulation of such information after its delivery, in particular, methods for the delivery and manipulation of digital information in a distributed trust environment having different levels of access and control.
  • Email is fast, cost-efficient, and convenient, as typically implemented, email may expose enterprises and individuals to extreme risk. Some of these risks include: 1) the inability to control email messages and attachments after transmission, 2) the loss of communications privacy and trust, and 3) increased corporate and individual liability from uncontrolled digital communications.
  • the inability to control message content may lead to the disclosure of sensitive personal, corporate, and/or governmental information.
  • Email users may not trust messages when they cannot be certain of the integrity of message content and/or the identity of the sender or receiver. Lack of message control, therefore, may lead to increased liability, for example, when individual healthcare or financial records are received and read by parties lacking the authority to do so. More specifically, referring to Fig. 1, a scenario illustrating present day email communication is illustrated.
  • the sender 10 wishes to communicate via email a private message 12 to an intended receiver 14 (or group) and not beyond, and wishes to be assured that the message only be used in a manner specified.
  • the private message travels from a first mail server 16 to the internet and to the mail server 20 of the intended receiver.
  • the intended receiver can use the private message in ways unintended by the sender.
  • the intended receiver may distribute electronic or print copies of the message, reply to the email message and including unintended receivers, or forwarding the message to unintended or unauthorized receivers.
  • the privacy of the email message can be compromised by its context alone (i.e., subject / sender identity).
  • a system is needed to control access to the same digital information by different players (having different levels of clearance) and allow different types of action be acted upon that digital information in accordance with the levels of clearance. For example, a person having a low clearance level should only have the ability to view the sensitive digital information while a person having a high clearance level should have the ability to view and manipulate the digital information. Furthermore, as circumstances change, a player's level of clearance may change as well.
  • a system for controlling digital information from a sender to one or more recipients comprising of: (i) a packager for packing digital information in accordance with a sender-specified set of rules and access level information; (ii) one or more secured delivery engines for delivering said packed digital information from said sender to said one or more recipients; and (iii) a rendering program for manipulating said delivered digital information in accordance with said rules and said access level information associated with each of said recipients.
  • Another advantage of the present invention is that it provides methods for monitoring use of digital information, including use associated with and/or in the context of access in view of changing circumstances.
  • Still another advantage of the present invention is that it controls access to digital information in accordance with levels of clearance associated with recipient. Still yet another advantage of the present invention is that it provides methods for controlling the manipulation (including the viewing, the forwarding, or the replying) of digital information.
  • An email sender can protect selected email messages and attachments by specifying rules that a recipient must comply with in order to access the message and attachments.
  • Messages and attachments are packaged into secure containers along with rules governing their use by an authorized messaging program.
  • the secure containers are transmitted using normal email channels, however upon receipt the body and attachments can only be accessed when using an authorized rendering program and handled by the recipient in a manner specified by the sender. For example, if the sender specifies a rule that states a recipient can only view the body and attachments of an email, then the recipient is prohibited by the trusted email rendering program from cutting or copying the message or from printing it.
  • the system provides an approach to managing the trusted authorization of message packaging and rendering programs.
  • the system provides a tracking function that can monitor and report the status of email transmissions.
  • the system does not require that a company or individual scrap their current email system.
  • Secure email seamlessly integrates into existing mail clients and requires no special processing by backend mail servers. This allows the existing email network becomes the foundation to integrate secure communications process and persistent content protection into email communications, inside and outside an organization.
  • the rule-based nature of secure email can implement virtually any privacy policy as required by governments, contracts, markets or end users.
  • Rules attached to e-email protect the rights to the intellectual property and ideas contained in email messages and attachments.
  • access and usage rules as defined by the sender, are attached to the email.
  • the sender can control an extensible list that defines things like how and when the email and attachments can be used, e.g., a sender can provide direct control over intended uses that may include viewing, printing, copying, editing and duplication.
  • Trusted email can maximize the efficiency of email communications while providing the full confidence that intellectual property; confidential communication, and financial information are exchanged and shared with minimum risk.
  • Secure email has a built in audit trail that can monitor and report the status of email transmissions. This audit trail could be used to verify that a message was delivered, in authentic and unaltered form. The audit function can also determine and report the fact that a message was opened at the destination.
  • the trusted email audit features are significant in those circumstances where message delivery status and acceptance may be required.
  • the audit trail provides a full-featured protection process in case an intended recipient repudiates message delivery.
  • the present invention relates to exchanging electronic messages in a cryptographically secure container (non-limiting examples of which are disclosed US Pat. No. 5,715,403 issued to Stefik on 2/03/1998; US Pat. No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997; and, US Pat. No. 5,845,281 issued to Benson et al. on 12/1/1998; which are incorporated herein by reference).
  • the present invention also relates to electronic rules securely associated with electronic messages and means for enforcing those rules whenever and wherever access and/or use of protected information is requested.
  • FIG. 1 is an illustration of a prior art process for sending email from a creator/sender to a receiver(s);
  • Fig. 2 is an illustration of a prior art process where an unintended receiver reads forwarded email;
  • Fig. 3 is an illustration of a prior art process where portions of the email message are compromised in an open work environment
  • FIG. 4 is an illustration of a prior art process where the email is mistakenly addressed for the wrong person
  • Fig. 5 is a block diagram of an embodiment of a messaging system
  • Fig. 6 is a block architecture diagram of an embodiment of a trusted messaging system client.
  • Fig. 7 is a block diagram of an embodiment for creating a secured email message
  • Fig. 8 is a block diagram of an embodiment for viewing a secured email message
  • Fig. 9 is a screen shot of an embodiment of a settings panel that includes profiles, intents and message field replacement;
  • Fig. 10 is a block diagram of a rule selection process
  • Fig. 11 is a table illustrating an example of the membership and access layout in a distributed trust environment.
  • FIG. 5 An non-limiting example embodiment of a messaging system 100 is shown in Fig. 5.
  • a sender 104 and receiver 108 have a trusted computing base (“TCB") 128 associated with each of their computers, said TCB 128 having a software tamper resistant secure execution facility known to those skilled in the arts.
  • a TCB 128 may rely in part on hardware tamper resistant techniques known to those skilled in the arts.
  • TCB 128 is disclosed in US patent No. 5,715,403 issued to Stefik on 2/03/1998; US Patent No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No.
  • TCB 128 is an "InterRights Point" software installation that includes a protected processing environment as disclosed in the InterTrust patents, hi a related embodiment, the TCB functions are more fully integrated with the operating system, one example of which is the Virtual Distribution Environment (VDE) disclosed in the InterTrust patents.
  • VDE Virtual Distribution Environment
  • the sender 104 uses a messaging program 116 to compose a message, which may include one or plural attachments.
  • the messaging program 116 formats and passes the message to the TCB 128-1 using the application program interface (API) of the TCB 128.
  • API application program interface
  • Some embodiments could gather some message and/or packager information from a MAPI mail client 112 or a stand-alone packager application program 120.
  • the messaging program 116, MAPI mail client 112, and/or stand-alone packager program 120 would operate together with TCB 128-1 on a common computer/appliance 110-1.
  • the messaging program 116, MAPI mail client 112, and/or stand-alone packager would be distributed on separate computer/appliance and interact remotely with TCB 128-1.
  • the messaging program 116 includes a packager routine and rules compiler routine.
  • the packager routine gathers the message and any attachments and sends them to the API of the TCB 128-1.
  • the rules associated with the packaged message and/or attachments are compiled and passed to the TCB 128-1 for inclusion in a cryptographically secure container (“CSC") 132.
  • the CSC protects the message and attachments during transport through the Internet, private networks, including corporate networks (“intranets”) and private networks among value chain parts, often referred to as "extranets,” for example. Once in the CSC 132, the message is passed to the receiving party 108.
  • the TCB 128-2 of the receiver decodes the CSC 132 and controls subsequent access to the message and/or attachments.
  • the rendering program 124 allows the receiver 108 to view and manipulate the message and any attachments in accordance with the rules provided by the sender 104.
  • the rendering program 124 would operate together with TCB 128-2 on a common computer/appliance 110-2. 108.
  • the rendering program 124 would be distributed on a separate computer/appliance and interact remotely with TCB 128-2.
  • the messaging program 116 and/or the stand-alone packager 120 is authorized to exchange messages with the rendering program 124.
  • Authorization to exchange messages is based in part on authorization to use the TCB 128 and the presence of a protected digital data structure(s) stored within TCB 128.
  • One or more protected digital data structures authorizes messaging program 116 and/or the stand-alone packager 120 to allow sender 104 according to rules to encode messages and attachments within a CSC 132 and to include within the CSC 132 a protected digital control mechanism that allows an authorized rendering program 124 to authenticate that the receiver 108 of the message is the intended recipient.
  • the presence of one or more protected digital structures stored within TCB 128 authorizes the rendering program 120 using the protected digital control mechanism transported within CSC 132 to only decode and render messages that are intended for receiver 108.
  • authorization to exchange messages is provided by a centralized rights manager program ("RM") 134.
  • RM 134 may create, modify, store, and distribute protected digital data structures used by TCBs to manage rights.
  • Non-limiting examples of rights managed within a protected digital data structure include authorizations, membership cards, budgets, and persistent ownership rights.
  • a user authorized to use TCB 128, must also be authorized by the RM 134 to use messaging program 116, stand-alone packager 120, and/or rendering program 124.
  • the RM 134 may be a stand-alone program or in other embodiments the functions of RM 134 may be incorporated via API's or other suitable mechanisms into existing centralized authorization systems such as Novell's directory services products, or other directory systems using enterprise directory system (e.g. x.500), or Lightweight Directory Access Protocol (LDAP).
  • the entity that controls the RM 134 may provide certain policies to authenticate the identity of the user including their email address. Non-limiting examples of the policies used by the controlling entity may include procedures that incorporate x.509 certificates or other digital certificate authority schemes.
  • Some embodiments of the RM may include API's to facilitate this access to 3rd party systems that provide certificate and key management services.
  • the RM 134 controlling entity is also responsible for causing the RM 134 to distribute securely a protected digital data structure to TCB 128, which grants authorization to use the messaging program 116, the stand-alone packager 120, and/or the rendering program 124.
  • authorization to exchange messages is provided in an initial peer-to-peer exchange of authorization information between the messaging program 116 and the rendering program 124.
  • a sender 104 and a receiver 108 must first be authorized to use TCB 128-1 and TCB 128-2 respectively, the sender 104 and the receiver 108 securely registers certain identifying information about themselves including their email address to TCB 128-1 and TCB 128-2 respectively, the sender 104 then invites the receiver 108 to exchange messages.
  • Authorization is passed within a protected digital data structure inside a CSC 132 from the receiver 108 back to the sender 104.
  • At least some rules and/or associated "objects" or files related to the message may be sent in a CSC to receiver 108 by a third party.
  • third parties include providers of financial clearing and/or processing services.
  • financial clearing rules and/or associated information include one or more instantiations of electronic money, payment, stored value, credit, notational currency, digital cash, and other currency and payment related electronic files or "objects".
  • An example financial clearinghouse 140 may send a rule or payment object in a CSC 132 to the message receiver 108.
  • the TCB 128 includes means for receiving, assessing the integrity and authorized source of the payment-related information, and as necessary, associating the payment information with rules provided by sender 104 if payment for access and/or use of the message and/or one or plural attachments is required by sender's 104 rules.
  • the sender 104 can choose rules to regulate access to the message and attachments by the receiver
  • the messaging program 116 gathers the rules and passes them to the TCB 128 for inclusion with the CSC 132. These rules are persistent, such that the receiver 108 or other parties cannot violate the rules at any time in the future. For example, a rule may prevent the receiver 108 from forwarding, printing, copying or saving the message such that another recipient who is not authorized by sender 104 is prevented from accessing and/or using the message and one or plural attachments. Some embodiments can sunset and sunrise the rules to make them applicable during a time period.
  • the rules are embodied in intents or verbs that the TCB 128 applies to the message and/or attachments inside the CSC 132.
  • verbs or intents are disclosed in US Pat. No. 5,715,403 issued to Stefik on 2/03/1998; US Pat. No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; and US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997.
  • Other intent or verb embodiments are disclosed in the InterTrust patents. For example, a "save" intent could be specified to allow the receiver 108 to save an attachment locally outside the protection of the TCB and any CSCs. Once saved, the control of the unprotected saved version is lost.
  • a usage clearinghouse 136 audits a message as it is packaged and sent by sender 104 and/or received and accessed by receiver 108. Information from the TCB 128 of the sender and receiver is available to the clearinghouse 136. This audit information can be used to check compliance with the rules, and as a foundation for value-added services, such as "certified delivery”, “non-repudiation", and other value-added services.
  • the messaging program accesses the facilities of the TCB through abstraction layer as shown in Figure 6.
  • the abstraction layer provides an API consisting of messaging related functions, non-limiting examples of which include "package this message”, “package this attachment” "package these rules", and any other trusted functions and/or capabilities provided by messaging program 116.
  • computer or appliance is a hardware context on which operating systems and applications are run. Non-limiting examples of computers or appliances include PCs, Macs, Windows CE machines, cell phones, personal digital assistants, game machines, digital cable boxes, WebTV, and other devices.
  • the operating system controls the hardware and peripheral devices and provides services to and a software execution context for applications and other software.
  • Operating systems include various Microsoft Windows versions including XP, MAC OS, Linux, Unix, and other operating systems.
  • the TCB 212 may be thought of as a middleware operating system extension that provides security and trust related services to applications that use its services which are accessed through a TCB API 216.
  • TCB services for example a first mail client 224-1 interfaces with the OS 208 exclusively.
  • Figure 6 also shows that the trusted messaging system may be integrated .with any number of mail clients.
  • a second mail client 224-2 may obtain services from the TCB through the TCB API 216.
  • many TCB API calls are required to accomplish common and repetitive tasks, such as packaging rules, messages, and/or attachments in one or more CSCs.
  • a third and n" 1 mail clients 224-3, 224-n are enabled to make use of TCB services through a trusted mail client abstraction layer API 220, which is in contrast to the second mail client 224-2 that makes use of the TCB services directly through the TCB-API 216.
  • the first mail client 224-1 makes no use ofthe TCB 212.
  • FIG. 6 also shows that a mail client may present its information and services to a user through a graphical user interface (GUI) 232 that may vary from mail-client-to-mail-client.
  • GUI graphical user interface
  • FIG. 6 shows that a mail client may present its information and services to a user through a graphical user interface (GUI) 232 that may vary from mail-client-to-mail-client.
  • GUI graphical user interface
  • the information in these localization files is then used by the mail client GUI interface 232.
  • abstraction layer API 220 makes the task of creating an interface between a mail client 224 and TCB services 212 much easier because higher level functional calls to abstraction layer API 220 may hide the underlying complexity of multiple TCB API 216 calls per function. The programmer then is free to concentrate on the particular issues in interfacing with the mail client at hand.
  • An advantage of the present invention(s) is that programmers who are already familiar with mail clients are less likely to have to learn the details and complexities of the TCB API 216.
  • enhancement, modification, bug fixing are enhanced since in many cases one need only change the abstraction layer 220 once to provide these improvements to users of many different mail clients 224, assuming that the abstraction layer calls themselves do not require alteration.
  • Solutions to Contextual Problems In the implementation of the preferred embodiments, a number of issues are presented and resolved including the resolution of contextual problems. More specifically, the description provided below provide methods used by messaging program 116, stand-alone packager 120 and/or rendering program 124 to to resolve various issues related to protecting electronic messages from unauthorized access and use . Solutions to Contextual Problems - Providing for auditable email path tracking, credentialed and trusted email applications, and email clearinghouse services
  • the chain of repackaging authority for the contents of an email message can be traced. This is to be accomplished by associating two attributes for each content object (or some other suitable object) within a message. Each repackaging of the contents of a message by messaging program 116 and/or by the standalone packager 120 will causes an instantiation of one or more content objects.
  • the first attribute will be assigned a value containing a unique Object ID for the latest instantiation of the content object.
  • the second attribute will be assigned the full parentage (each Object ID which has included it in this path) of all prior instantiations.
  • Repackaging authority within messaging program 116 and/or the stand alone client 120, is handled by a custom intent, that is, by a verb or controlled action that is not standard verb of, and/or known to a TCB, but which in the preferred TCB embodiment has been in part programmed and certified by the provider of the preferred embodiment TCB .
  • the provider of the TCB may evaluate the security, trustedness, and/or functionality of a proposed trusted application, and upon determining that the application is secure, trustable, and performs certain controlled actions in accordance with the TCB verb(s) or intent(s), the TCB provider associates with the certifiable application one or more trusted credential such as a "digital certificate" or signed object.
  • This certificate or signed object is referred to as an "application credential" whose presence and/or validity may be checked by the TCB at least one or more times as the certified or credentialed application uses capabilities of the TCB through the TCB API 216 or through an abstraction layer API comprised at least in part of higher level or more holistic function call.
  • the abstraction layer uses one or more TCB API 216 calls to accomplish the higher level tasks.
  • the application credential(s) associated with messaging program 116 and/or stand-alone packager 120 are known in a trusted and protected manner by rendering program 124.
  • the application credential(s) associated with the certified messaging program 116 and/or the stand-alone packager 120 are stored in each CSC prepared by said programs so that the rendering program 124 can readily tell CSCs prepared by said programs.
  • the rendering program 124 will only be process those CSCs created by messaging program 116 and or stand-alone packager 120.
  • other 3 rd -party CSC rendering programs are not to process CSCs created by messaging program 116 and/or stand-alone packager 120.
  • one non-limiting example of a CSC is an InterTrustTM DigiBox secure container.
  • a clearinghouse needs to be involved for processing and reporting the audit trail, which in the presently preferred embodiment is at least in part described in the aforementioned WIPO publication WO9,810,381, Shear, et al.
  • Audit/usage records are created at the time the email is secured within the CSC by the TCB (see Fig.7) and again when the email is first viewed (the CSC is opened and content is presented after the authorization rules are met) (see Fig. 8).
  • an audit record can be produced each time the email or attached files are viewed, printed, or saved.
  • the real subject line of an email message is saved in a protected fashion and replaced by a non- informative subject line during public transport, after receipt by the intended recipient the original subject line is restored
  • this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non- informative subject line to use.
  • the non-informative text may be stored as a default subject line available to sender 104 each time stand-alone packager 120 and/or messaging program 116 is used.
  • the messaging program 116 and/or the stand-alone packager 120 creates a replacement message that contains the non-informative subject line along with an attached CSC file that contains the original subject line along with other components of the message.
  • the replacement message is then submitted by messaging program 116 and/or stand-alone packager 120 to sender 104 email client via some standard interface, for example the Messaging Application Program Interface (MAPI) proposed by MicrosoftTM and now implemented by many email system vendors or some other suitable interface.
  • MAPI includes functions for harvesting the real subject line of a message, thus an advantage of subject line replacement is to protect the sender 104 and receiver 108 from unwanted tracking of the subject of exchanged messages.
  • the rendering program 124 Upon receipt of the replacement message by receiver 108, the rendering program 124, according to rules decodes the message in the CSC and the real subject line is made available by replacing the default subject line in the rendered message.
  • the real sender's name and address is saved in a protected fashion and replaced by a non- informative name and/or address during public transport, after receipt by the intended recipient the original name and address is restored. In one embodiment, this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non-informative name and address to use.
  • this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non-informative name and address to use.
  • the messaging program 116 and/or the stand-alone packager 120 creates a replacement message that contains the non-informative name and address along with an attached CSC file that contains the original name address and along with other components of the message.
  • the replacement message is then submitted by messaging program 116 and/or stand-alone packager 120 to sender 104 email client via some standard interface, for example the Messaging Application Program Interface (MAPI) proposed by MicrosoftTM and now implemented by many email system vendors or some other suitable interface.
  • the rendering program 124 Upon receipt of the replacement message by receiver 108, the rendering program 124, according to rules decodes the message in the CSC and the real subject name and address is made available by replacing the spoofed name and address in the rendered message.
  • Other fields in the message header could be replaced by default values.
  • the rendering application in conjunction with the TCB would replace the default values with the real values. For example, for a message sent to many receivers could have the other receivers suppressed until viewing such that viewing the message during transport would only reveal one of the receivers.
  • a medical specialist's doctor's office may send a trusted email to a patient and choose to mask who the sender is less so that some interloper cannot infer from the sender what medical condition(s) the patient might have.
  • a rule profile is a named collection of rules, specified by a sender 104 or established by some other enterprise, governmental or institutional body and selected by sender 104, for controlling how a receiver 108 may use an email. Selection of one of the predetermined groups of rules applies those rules to the message more efficiently and consistently. Rules specify how and when an email may be used. Rules include but are not limited to specification for the handling of messages that allow or disallow for printing, viewing, saving into the clear (unencrypted), as well as a time range when such actions are valid, so called "sunrise" and
  • sender 104 provides a list of e-mail recipients to messaging program 116 and/or stand-alone packager 120 and selects a rule profile. Messaging program 116 and/or stand-alone packager 120 processes the recipient list and applies the rules contained in the selected rules profile to message packaged for each recipient.
  • Rule profiles are stored in Extensible Markup Language (XML) (non-limiting example details of which are provided in Appendices 1, 2, and 3) anticipating that the set of rules/options covered in a profile will likely grow over time (see Figs. 9 and 10).
  • XML is defined via http://www.w3.org/XML/ as a vendor- independent standard. Microsoft extensions may also be used in the implementation and they are documented at http://msdn.microsoft.com/XML. Referring to Appendix 1, the first line identifies this as an Email Settings XML and identifies the namespace to use (for datatypes). The second line begins the definition of the "Individual" settings, which in one embodiment indicates which of a possible hierarchy of rules profiles the present instance belongs.
  • XML Extensible Markup Language
  • Rules profiles might reflect any class distinctions), one example of which might be a hierarchical Corporate/Department/Individual settings of options in a rules profile.
  • Corporate settings would overrule Department settings which would overrule Individual settings. Distinctions would be made between "defaults" being specified at a higher level vs. a required value being specified at a higher level.
  • Corporate settings in a given profile might default secured emails to expire (sunset) after 1 year while requiring that those emails NOT have SAVE intent enabled. This would allow Individuals to set their corresponding profile to a different sunset date but would NOT allow them to enable the SAVE intent.
  • the third line describes the "Ind_Print" option attribute.
  • Ind_Print anticipating the hierarchy of options described above to allow for "Corp_Print” and "Dept_Print” option attributes. It is defined as an integer (“int”) datatype using the specified XML NameSpace ("xmlns"). It is assigned a value of 1 and the attribute description is terminated ( ⁇ /Ind_Print>).
  • the messaging program 116 and/or the stand-alone packager 120 interprets a value of 1 to mean that the intent is enabled and a value of 0 means the intent is disabled.
  • the fourth line describes the "Ind View” intent option attribute. See the description of the third line for the details.
  • the 1 indicates “View” is to be enabled.
  • the fifth line describes the "Ind_Edit” intent option attribute. The value of 0 indicates the "Edit” option is NOT to be enabled.
  • the sixth line describes the "Ind_Save” intent option attribute. The value of 1 indicates the “Save” option is to be enabled.
  • the seventh line describes the "fr ⁇ d_Reply” intent option attribute.
  • the value of 0 indicates the "Reply” option is NOT to be enabled.
  • the eighth line describes the "Ind Forward” intent option attribute. The value of 0 indicates the “Forward” option is NOT to be enabled.
  • the ninth line describes the "Ind_Sender_Name” replacement value. It is defined as a string. It has the value “Default” which would become the sender name on the email if the next attribute (Ind_Sender_NameJOverride) is enabled (has a value of 1).
  • the tenth line describes the "Ind_Sender_Name_Override” option attribute. It is an integer (“int”) assigned a value of 1.
  • the messaging program 116 and/or the stand-alone packager 120 When interpreting the XML representation of a rules profile, the messaging program 116 and/or the stand-alone packager 120 considers the value of 1 for this attribute to request that the sender's name on the email be replaced during the "Make Secure" operation so that the value specified in the attribute " ⁇ nd_Sender_Name” is shown instead. Only after the rendering program 124 caused the successful opening by a TCB of a CSC according to rules will the actual sender name be displayed when the email is opened.
  • the eleventh line describes the "Ind_Subject" line option attribute. It is defined as a string and the value assigned, "TRUSTDATA Secure Message" in this case, is to be the value assigned as the subject line of the email replacing the actual subject line.
  • the actual subject line would only be visible once the CSC was opened by the trusted viewer or rendering application. The value is only used to replace the actual value if the next attribute "Ind_Subject_Override" has the value of 1.
  • the twelfth line describes the "Ind_Subject_Override” option attribute. It is defined as an integer. When it is assigned a value of 1 (as in this example), it indicates the value of the attribute "Ind_Subject” should be used to override the actual entered subject line for the email message. A value of 0 for "Subject_Override" indicates the actual entered subject line should be used.
  • the thirteenth line describes the "Ind_Sunrise” option attribute. It is defined as a dateTime attribute.
  • the value assigned indicates the earliest time (GMT) at which the email may opened.
  • the fourteenth line describes the "lhd_Sunset" option attribute. It is defined as a dateTime attribute.
  • the value assigned indicates the latest time (GMT) at which the email may be opened.
  • the fifteenth and sixteenth lines provide closure to the elements defined.
  • the XML representation includes: (1) validity date in days from packaging date/time - this option would allow a number of days to be specified for the validity period. The sunrise date would be assigned as the packaging date and the sunset days would be calculated to be the number of days as specified in this attribute after the packaging date. (2) usage auditing options - What audit records should be prepared from use of this email Options include but are not limited to combinations of; at packaging time, on first open, on every open, on first save, on every save, on every print, on first print, no auditing at all.
  • the messaging program 116, stand-alone packager 120, and or rendering program 124 will provide a recipient level ID test will authenticate that the specified recipient email address has one or more associated valid TCB UserfiOs.
  • An email address may have one or more valid TCB UseriODs This is defined as allowing many UseriODs for one email address to allow for eventual web-based email access and shared file access where the intended recipient may have UserlDs on many different TCBs for the same user (e.g., work computer, home computer, notebook computer, etc.).
  • the alternative of many email addresses associated with the same UserlD seems attractive at first glance (lots of people have more than one email address).
  • a protected digital data structure that we refer to as a "Digital Credential Object" may represent, signify, warrant, and/or attest to any one or more identity characteristics, attributes, and/or memberships.
  • the DCO contains data elements for the name of the DCO, one or more memberships, information that may include cryptographic information indicating the authority that associated the membership with the entity, and information that may include cryptographic information indicating the entity with whom the one or more memberships are associated, and any other fields providing relevant information. Since the DCO is never released from or directly exposed for manipulation outside the control of the TCB, there is no requirement for the calculation of either an integrity check, such as a checksum or cryptographic message digest, and/or the validation of an integrity check using other cryptographic means. In the presently preferred embodiment these DCOs are "Membership Cards" as described, for example, in the aforementioned U.S. Patent No. 6,112,181 to Shear, et al.
  • the messaging program 116, stand-alone packager 120, and or rendering program 124 will allow email to be sent to general membership groups where that group could expand or contract over time and the access to attachments sent with historical messages to be enabled without having to be a specific recipient.
  • There is both a revocation mechanism (the presence of a revocation of a membership indicates the membership is no longer valid) as well as a way of expiring memberships (date range limits).
  • a given individual can have many memberships.
  • a general membership management application could be of use beyond secure emails and files.
  • a membership can be granted for free or for some information (filling out a survey for example) or for some payment.
  • This membership mechanism may be used to assign a membership specific to each authorized user of our secure email products and automatically include a test for this membership in every rule of every email/file we package.
  • One non limiting benefit of this mechanism would allow RM 134 to quickly revoke that user's access to all secure emails/files should circumstances warrant.
  • Each email message may have one or more specific membership cards.
  • RM 134 will provide membership cards in the form of a protected digital data structure with expiration dates. This will be coordinated with the use of the date validity range mechanism and may be revoked using appropriate revocation token(s) also provide by RM 134.
  • Messaging program 116, stand-alone packager 120 and rendering program 124 will process membership cards according to rules. The use of memberships per email message is primarily to enable revocation of a given recipient's authorization to read a given email message. In some embodiments the memberships would be delivered to the recipients via the same CSC that included the email message.
  • revocations could be sent in CSCs later either from the sender or potentially from an administrator, such as RM 134. All of this requires that the rules defined in the CSC for the email include a test for the membership in addition to whatever other tests are appropriate.
  • Expired and/or revoked membership cards and other objects may be deleted by a utility application.
  • function calls in the API allow membership cards (or other objects) to be found and examined for validity. If invalid, the membership card is deleted. For example, a membership card may have exceeded its validity date. Upon its next use, the membership card is deleted.
  • an identifying application ID or application IDs would be associated with rendering program 124 and would protect the email messages. This mechanism is managed between the messaging program 124 or the stand-alone 120 and the TCB.
  • the messaging program 124 and the standalone packager 120 always includes an identifying application ID(s) in CSCs said program cause to be created by a TCB.
  • the rendering program 124 and TCB always test for the presence of that application ID(s) (see Figs. 7 and 8) before the receiver 108 can view the message and any attachments.
  • Third party rendering programs do not work with CSCs created by the messaging program because the third party rendering program does not have the proper application ID. By use of the application ID, a rendering program that may be generally be able to process a CSC is prevented from processing CSC from messaging program 116 and stand-alone packager 120.
  • the messaging program 116 and/or the stand-alone packager 120 causes replacement message to include instruction or directions for obtaining a TCB and/or appropriate rights and controls, perhaps from RM 134.
  • the TCB is software that can be downloaded for use in decoding a message.
  • the messaging program 116 and/or the stand-alone packager 120 obtains the body of the email message and includes it in the CSC as part of the content.
  • the messaging program 116 and/or the stand-alone packager 120 then replaces that body portion of the email message with either blanks (an empty message) or with user/administrator supplied text (if there is some provided) (see Fi - 7)
  • the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification and enforcement of rules that specify that the set of "reply" recipients cannot be expanded Reply can be to some or all, but not more than, the list of authorized recipients
  • the set of recipients and the UserlD test that we infer to include in the rules that govern access to the message is constrained to be just those in the original email's recipient list and the sender Even if the email user sends the message m a CSC to some other email address, the other receiving email address won't have a UserlD that is m the rules specified and therefore won't be able to access the message
  • this is implemented as a protected object within the CSC that is removed from the container by the rende ⁇ ng program 124.
  • Reply capability can be specified with or without decoding of the message such that a reply can be made without a TCB. Without decodmg, the recipient cannot read the body of the message Rules in the reply email limit it to being read by the same set of people who received the original or a proper subset of that group. The email could be delivered to others (perhaps by mistake) but the rules enforced by the TCB would prevent those others from reading the message
  • Edit capability can be specified as to identified parts of the email. Such that some portions of the header or body of the message can be edited while other portions cannot For example, the attachments could be editable while the email body could not
  • Reply without Edit capability means that reply text is entered without any edit access to the original email text This is most likely to be done by leveraging the fact that we do have editing capability for the body of emails with the messaging program A rule will allow viewing and replying to the message, but will not allow editing or deleting text m the email body.
  • Reply with Edit capability is more complex since that implies that the body of the email can be changed This could range from limiting changes to being additions (no modification of existing text but allow m-hne addition) to full edit capability (deleting original text or modifying it). There may be distinct options for those types of controls. When the options include modification and deletion of original text, it is essentially the creation of a new document more so than a forwarding of the original and should imply a SAVE intent for the forwarding author.
  • Attachments have more complex processing.
  • content viewers for a wide variety of attachment file types (e.g., the content viewer from INSOTM). These content viewers do not, however, support CSC that are opened by TCBs.
  • Some editors have options for tracking changes (MS Word for example) but these off-the-shelf editors are not used.
  • MS Word for example
  • the “Contrast” sort of approach is also "after the fact” which is not generally a well-received ergonomics choice.
  • uses of the trusted messaging system disclosed herein is to conduct asynchronous electronic commerce transactions.
  • an EDI system may in part be comprised of a data structure or form with standardized fields. There may be plural forms defined either because there are plural variant forms for a given purpose and/or transaction, and/or there may be many forms-based transactions necessary to accomplish the commerce functions of the system. For example, there may be variant healthcare claim forms that differ in the arrangement and sequencing of the fields. In another example, there may be claim forms and payment forms, the latter resulting in, and/or constituting instructions for a funds transfer system, two non-limiting examples of which are the S.W.I.F.T network and the Automated Clearinghouse (“ACH”) system.
  • S.W.I.F.T network the Automated Clearinghouse
  • the trusted messaging system disclosed here provides the basic capabilities of prior art EDI systems. CSCs can be used to securely transport the EDI information from one party to another and to provide authentication and non-repudiation of sending and receiving parties. Using the trusted messaging system disclosed herein, the sender may create rules that govern the access and/or used of field specific information. In one non-limiting example, a healthcare claims form may be sent to a person or process that can only view and/or modify selected portions of the information contained in the form. Such differential access and rights may depend at least in part on rules that are conditional on the presence and/or absence of credential information securely associated with the receiving person or process.
  • Said credential information may be represented, contained, conveyed, and/or stored in various kinds of objects, non-limiting examples of which are digital certificates known to those skilled in the relevant arts and "membership cards” or “membership objects” is, for example, disclosed in aforementioned U.S. patent No. 6,112,181, Shear, et al.
  • the present invention(s) enable "acceptance of terms” using protected digital objects comprised at least in part by HTML, XML, JAVA, and/or Active X code.
  • one or plural preferred embodiment clearinghouse(s) may handle charges for non-digital goods and services via the payment processing systems interfaces disclosed in the InterTrust Patents.
  • the security of EDI transactions would be enhanced though the use of time-based thresholds such as "sunrise/sunset" parameters, In this non-limiting example, a given EDI transaction would be valid only during a certain pre-specified time interval.
  • the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification of rules that grant authority to forward a message.
  • Authority to forward may be limited only to new recipients within a specified set of domains.
  • Domain in this context means the email domain (the part after the @ in the email address).
  • dconley@trustdatasolutions.com is in the domain trustdatasolutions.com. This technique may be used to limit the forwarding to addresses within a company or other organization, for example.
  • the rights of the original receiver define the maximum rights of anyone the original receiver forwards the message to. Rules may require subsequent receivers get a more limited set of intents.
  • the forward intent can be specified with or without an edit intent (same concepts as with Reply above).
  • the edit intent can be specified as to identified parts of the email, such as: attachments and email body.
  • the messaging program 116 provides for the reuse of the rules profiles and rules selection dialogs found in the messaging program 116 to allow creation of a CSC for any file. These dialogs are used in a stand-alone packager. This allows the stand-alone packager 120 to apply rules governing their use to any file whether sent as email attachments or not.
  • the code that invokes the packager routine and rules compiler routine of the messaging program is also reused. Since there isn't a "recipients" list per se with files, we add dialogs to prompt for authorized UserlDs or memberships to the stand-alone packager.
  • the file packager works both as a plug-in to some MS Office products (e.g., Word, Excel, etc.) in addition to being available as a standalone executable, which can prompt for the file to be packaged (most software routines are reused across these two settings).
  • MS Office products e.g., Word, Excel, etc.
  • Usage can be both governed in terms of who is allowed to use (view, print, save are separate types of usage intents with separate authorization rules) and what if any audit trail (usage records) are created to document this (see Fig. 8).
  • the messaging program 116, stand-alone packager 120, and/or rendering program 124 utilize the user ID of the TCB (i.e., UserlD) and Password for authentication of the user.
  • the user ID of the TCB i.e., UserlD
  • Password for authentication of the user.
  • One choice is to place the signature(s) to match (biometric or other) inside the CSC and test against them before invoking the other authorization tests.
  • a second choice is to interact with an authentication service (perhaps via a directory service) which would manage the signature(s) to be tested against. In any case, we would interact with the biometric device or cardkey or other in the conventional ways suggested by the makers of those products.
  • the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification and enforcement of full usage rights of the embedded content may always be granted to the originator of the new secured email. Rule may be applied by default to allow the "originator" full access to the content regardless of additional specified rules. The originator must have an option to allow "sunset” emails to become unreadable by the originator also.
  • digital information may be persistently protected using the facilities of the DTE.
  • TCBs and associated information security and trust applications provide mechanisms to effectively control dissemination, access, and/or use of military-related digital information, non-limiting examples of which include imagery and geospatial digital information within one or more levels of security and trust, within (re)defmable limits by class of digital information user.
  • a feature of the invention(s) disclosed herein is that certain TCB technologies originally developed to provide a secure and trusted context for commerce (eBusiness) are equally applicable to high-security situations such as for military uses including battlefield uses.
  • eBusiness TCB capabilities can be applied to monitoring and documenting battlefield use of imagery and geospatial digital information.
  • the DTE and its TCB technologies may be used to simulate a classified environment with a presently unclassified commerce system, including governing the secure and trusted access to protected digital information through usage rules that may vary according to military/diplomatic coalition class and/or status.
  • an non-limiting demonstrable real-world example may include the use of the Distributed Trust Environment for military applications to address the following example requirements and or situations: (i) requirement to quickly disseminate U.S. imagery and geospatial information to a variety of battlefield related participants with multiple usage rules that vary according to coalition status and/or class membership; (ii) among a coalition group in whom there are varying degrees in confidence, non-limiting examples of which may include (a) representative battlefield participants; (b) unified commands; (c) tactical commands and units; (d) NATO; (e) coalition partners (long-time and onetime allies); and (f) UN and other non-governmental organizations ("NGOs"); (iii) create secure and trusted audit trail for monitoring actual use of digital information, including without limitation imagery and geospatial products; (iv) aid in planning and resource allocation, including communications resources and/or digital information resources; and (v) establish a dynamic feedback loop that is comprised at least in part of information, judgments, conclusions based on the analysis of actual
  • the inventions may be better understood though the following non-limiting example scenario and embodiment that is based upon a hypothetical renewal of conflict with Iraq over its military actions against Kuwait at some future point.
  • Coalition partners participating in the conflict any number of coalition partners may be participants in the system(s) disclosed herein: UK, Canada, Saudi Arabia, and Kuwait.
  • Coalition partners not participating in the conflict Iran and France.
  • By-stander countries to be influenced any number of by-standers countries may participate in the system(s) disclosed herein: Iran, UAE, Jordan, and Russia. US action is undertaken with support of UN. Active involvement by Red Cross and World Health Organization and potentially other non-governmental organizations (NGOs).
  • Operational Concepts The operational concepts underlying the example disclosed herein includes (without limitation) 1.
  • One assumed example environment includes client server and/or distributed, peer-to-peer applications, services, and network connections
  • Residing on networks may be one or more sources of protected battlefield related digital information, including imagery and geospatial libraries of historical digital information and/or realtime and/or near-realtime digital information sources
  • Non-limiting examples of digital information include battle-related messages, orders, intelligence, and any other battlefield relevant digital information
  • CSC cryptographicly Secure Containers
  • a participant's access to hbra ⁇ es and/or sources of protected battlefield information may be conditional on the presence and/or absence of pre-specified digital credential objects (MCO).
  • MCO digital credential objects
  • Certain participants and/or classes of participants may retrieve only products they are authorized to access and use them subject to rules governing usage
  • the Distributed Trust Environment is a distributed, peer-to-peer application for governing the autho ⁇ zed access and use of digital mformation in any format in a military context, up to and including hot battlefield contexts
  • the DTE relies on a Trusted Computing Base (TCB) to evaluate requests to access protected information and to then make that information available to the requestor, non-limiting examples of which include individuals, both military and civilian, devices, appliances, software applications, processes, and artificial intelligences
  • TTB Trusted Computing Base
  • the DTE also relies on cryptographically secure software containers to protect digital information and/or rules governing authorized use from unauthorized disclosure, use, and/or modification.
  • the features and capabilities of the DTE include, but are by no means limited to (l) Automated means for restricting access to protected digital information to requestors having one or more Military Credential Objects (MCO), nonlmutmg examples of which include so-called digital certificates and "membership cards" disclosed in U.S. Patent No. 6,112,181 to Shear et aLEnsuring that only authorized requestors access and use protected digital information, (n) Digital information rendenng components that ensure that only autho ⁇ zed uses of digital information take place; (in) Digital mformation usage auditing and reporting with non-repudiation; and (iv) Other features and functions noted elsewhere this document.
  • Credential-based Access Control MCO
  • a protected digital data structure that we refer to as a "Military Credential Object” may represent, signify, warrant, and/or attest to any one or more identity characteristics, attributes, and/or memberships. We refer to these identity characteristics, attributes, and/or memberships equivalently as “memberships.”
  • the MCO contains data elements for the name of the MCO, one or more memberships, information that may include cryptographic information indicating the authority that associated the membership with the entity, and information that may include cryptographic information indicating the entity with whom the one or more memberships are associated, and any other fields providing relevant information. Since the MCO is never released from or directly exposed for manipulation outside the DTE, the DTE does not require the calculation of either integrity check, such as a checksum or cryptographic message digest, and/or the validation of an integrity check using cryptographic means.
  • seven fundamental membership groups are defined together with an overall determination of their access to battlefield-relevant digital information as follows: (i) Trusted Allies (Highest Access - Full Functionality); (ii) Fighting Coalition Partners (Operational combat Access); (iii) By- standing Coalition Partners (Non-Combat Access); (iv) By-standers to Be Influenced (Informational Access); (v) affiliates Not-Participating (Operational Access Not Allowed); (vi) Humanitarian affiliates (Focused Dissemination); and (vii) Public/Media Outlets (Controlled/Balanced Dissemination).
  • the first four membership groups represent the direct sphere of influence surrounding the actual battlefield or other related military-relevant operations. These members have varying degrees of access to protected digital information. Access to protected digital information can range from full access down through viewing, printing modifying, local storage and printing. The lowest or most restrictive access (other than total denial of access) is to view (display) the digital information, to execute a software executable or interpretable, to play digital audio, and to present/play digital video information.
  • the fifth membership is the null group used to demonstrate that this membership group cannot open a cryptographically secure container even though they may have an operable system and under other circumstances would have access to information.
  • Israel for example, might be a good candidate member. To enhance this point, this membership (and all memberships) could be given access to the Public/Media files as well.
  • Two other non-limiting example classes may also be participants in and/or receive battlefield- relevant protected digital information:
  • Humanitarian affiliates - Image files and other digital information could be disseminated, with full or partial access, to assist in the logistic and support processes associated with a humanitarian situation caused by the military conflict.
  • These protected files could contain photographs or satellite images of refugee migration paths and logistical plans.
  • Dissemination could be specifically controlled by MCOs as well as time/access controls on the encapsulated content packages provided by the Command authority to Humanitarian organizations. Though most members could have access to the Humanitarian information, access to this protected digital information should not be assumed to be a default condition for all members. It should be selectable since in combat situations, refugees, and their support, at times have become a political football. The Command authority may want to restrict access accordingly.
  • Class Membership Granularity Within each membership grouping or class, individual entities can be identified and unique content streams can be directed to that individual entity.
  • Participants associated with each country could be individually identifiable using an appropriate MCO or combination of MCOs.
  • MCO Mobility Control Commission
  • a practical real world example would be the country of Jordan. Due to the proximity of Jordan to Israel, the Command authority may want to individually encapsulate a communique to Jordan that only Jordan, or a selectable group and Jordan, would have access to.
  • members could be allowed to redistribute their one or more Military Credential Objects to authorized and authenticated recipients.
  • military Credential Objects For example, in the case of the UK, they could be allowed to redistribute their MCO(s) to their units m the field. This capability is significant because though coalition combat is "cooperative", each country wants to maintain its control over its own military command process. Giving the UK the ability and requirement to distribute then * Military Credential Objects could reduce the ⁇ sk that in the present example, the US/UN Command authority would be accused of withholding mformation or access to information.
  • the above example shows the UK (a full access partner) having MCO redistribution capabilities, MCO but redistribution capability applies to all membership groups as well. For the purposes of the demonstration, governmental membership redistribution should be limited to only the US, UK and Canada.
  • the appropnate MCOs would be given to organizations including, but not limited to UPI, BBC, AP, MS-NBC, CBS, and CNN etc Each, in turn, would redistribute the appropriate MCOs mside their own information, security, and trust infrastructures
  • MCOs can also be used to add an additional layer of access protection in the combat strig ⁇ o.
  • the encryption process usually changes every four to six hours Adapting the
  • the Command autho ⁇ ty may protect the intelligence process from compromise In the event a forward unit is overrun, and the encryption tokens are captured, in less than four hours the card expires and secure communications are reestablished
  • Generating membership cards with fixed penods of operation could provide the same sort of combat adaptability that exists in traditional cipher processes The concept would be that even if a machine (a forward deployed laptop) were captured, MCO updates would render the machine useless and out of the ⁇ sk profile for the Command autho ⁇ ty
  • the operational MCOs could be structured on the following single day rotation (all times GMT/Six Hour Rotation) (l) Blue MCO Deployment (All Classes), valid 0000 to 0615, (u) Green MCO Deployment (All Classes), valid 0600 to 1215, (in) Red MCO Deployment (All Classes), valid 1200 to 1815, and (iv) Black MCO Deployment (All Classes), valid 1800 to 0015
  • any kind, type, or format of digital mformation may be protected to ensure that access and/or use is in accordance with rules securely associated with the protected information.
  • m addition to image and geospatial files most battlefield processes include a variety of text-based elements that align with or expound on the image information.
  • image rendenng application the image rendenng application
  • unique file types may be generated as well.
  • the operational image type may be prop ⁇ etary to a specific military or national secu ⁇ ty application
  • Images, video, audio, software, multimedia may contain information in hidden channels using watermarking technologies known and/or presently unknown (classified) publicly.
  • Information carried in wartermarks may be any kind of information that can be encoded using the available watermarking bandwidth, for example, watermarked information that indicates using cryptographic means the integrity of the watermarked file, its creator and/or owner, and any control information that may be used by the preferred embodiment DTE as disclosed in U.S. Patent 5,943,422, Van Wie et al.
  • the image type disseminated to the Humanitarian or Public/Media members may be a standard file type (JPEG, GIF, Bit Map, Text etc.)
  • the same or different watermarking methods may be used for these kinds of files as for those distributed to parties such that a much higher level of security and trust is required. Generating digital information in these file types or other common file types would be done by a function in the Command Authority.
  • Protected information may be transmitted over any channel capable of carrying the required bandwidth.
  • the distribution system may be a satellite-based high rate burst transmission channel.
  • all systems in the field may have download access, capacity and processing capability. Securely encapsulated digital information could be packaged and delivered using such a transmission system.
  • CSCs can be delivered m "Broadcast” mode if required. Because MCOs may control access to the CSCs locally, so that even if a CSC was received at a location not intended by the sender, access could not occur. This broadcast burst "preemptive" delivery could be an important military advantage in a hot conflict where the example satellite-based high rate burst transmission channel goes into full transmit mode.
  • CD based systems that are forward deployed with the combat units.
  • These CSC protected CDs could have a base set of images and battle plans that set the baseline. Depending upon the application, these could be the templates upon which "Modify/Overlay" images could be rendered. This could be used in a battlefield configuration where the CDs are the base images (accessed through Membership) and the updates or overlays are delivered via a 3DID system. The updates/overlays are delivered in CSCs and controlled by Memberships as well.
  • the CD configuration could apply to a small "infield" unit that had minimal local storage (e.g., A hand held unit with a CD reader, max RAM, Fast Processor, Hard Drive with OS, IRP and a Single Application and COM/LPT ports only.)
  • minimal local storage e.g., A hand held unit with a CD reader, max RAM, Fast Processor, Hard Drive with OS, IRP and a Single Application and COM/LPT ports only.
  • the primary difference between the operational CSCs and the Public Media CSCs is in the classification level of the contents.
  • the Public/Media CSCs would contain non-classified material but they still require CSC control.
  • the reason to encapsulate and disseminate unclassified CSCs is to control the timing of the release of information and to ensure authenticity.
  • the Public/Media Memberships would allow opening a CSC at the prescribed time and the recipient would know that it came only from the Command authority. By default all memberships should be allowed access to the Public/Media CSCs.
  • Each element of content could be assigned a date/time driven lifecycle.
  • the encapsulated information could have a Sunrise and Sunset (SR SS) parameter that could be set by the Command authority.
  • SR SS Sunrise and Sunset
  • the SR/SS parameter would be utilized and a predetermined time "No earlier than” access and "Access Denied After” value would be set.
  • base overlays standard geographic image with no overlays or intelligence attached
  • the SR/SS value could be set to immediate access and infinite life.
  • content would be defaulted to an immediate access option.
  • the DTE TCB enforces rules specifying which actions, "verbs", or “intents” will be allowed.
  • a Digial Property Rights Language is the means for expressing governed actions.
  • a digital information rendering process akin to the View intent.
  • Modify/Overlay is a base imaging application function that allows local users to overlay and modify the image files once retrieved and decrypted from the CSC.
  • a governed action that allows local users to select, cut and paste all or part of files once released and decrypted from the CSC.
  • CSC repackage
  • This may mean access to a local packager that takes the image information (possibly after modification), assigns some DRM rules and repackages it for transmission.
  • a non-limiting example would be a battlefield update process.
  • a CSC arrives at the local system, is opened and annotated with the latest local information (e.g. 57MM Guns marked by the X's, 43MM marked by the Y's). The local user would repackage this information and transmit it to other elements and the Command authority.
  • this forward capability could be controlled by allowing the local DRM packager to operate subject to membership parameters.
  • the DRM packaging process may exist in all distributed applications, however it is not accessible unless the membership authorized it.
  • a Commander and/ or other authorities may choose between immediate usage gathering (processing) and deferred usage gathering (processing).
  • immediate processing could become a communication bottleneck depending upon available bandwidth.
  • a Commander would also like to know if a field unit received and opened a particular file.
  • the communication of CSCs containing usage information may entail a transport accessible parameter indicating the communications priority assigned to the CSC communication task.
  • An example Command autho ⁇ ty way request that the DTE provide a usage report that gathers identity and membership elements about the end user. Information aggregated at the Command authority would provide the analysis element.
  • the DTE may provide a usage report that gathers initial and subsequent access events including, for example, the number of times the file was printed etc. Information aggregated at the Command authority would provide the analysis element.
  • the DTE may provide a usage report that gathers information pertaining to the pe ⁇ od of time that a file was open for each access event. Information aggregated at the Command authority would provide the analysis element.
  • the issue of authentication is important to intelligence and its use m combat operations.
  • a variety of authentication elements may be involved.
  • the mvention(s) disclosed herein may be used to create a wide variety of battlefield relevant applications.
  • Operational Content CSC - Contains a classified image whose access (display) and utilization are driven by the membership rules.
  • the image is combat operations related picture. Not accessible by members of the affiliates Not-participating, Humamtanan or Public/Media groupings. Use of the content (Modify, Overlay, Print etc.) will be governed by rules affecting each membership group.
  • Humanitarian Content CSC - Contains a classified image whose access (display) and utilization are driven by the membership rules. The image could depict a Humanitarian event, possibly a refugee migration. Membership access is selectable by the Command authority at the time of generation. Not necessarily available to all members and definitely not available to the Public/Media members. Use of the content
  • Rest ⁇ cted Access CSC - Contains a classified image whose access (display) and utilization are driven by the specific membership rules.
  • the image could depict a non-combat event, possibly an Israeli troop deployment/staging on the West Bank of the Jordan River.
  • Membership access is specifically directed by the Command authority at the time of generation. Available only to the Trusted Allies and the Specific affected Member (Jordan). Not available to any member outside these limits. Use of the content (Modify, Overlay, Print etc.) will be governed as directed by the Command authority.
  • Purpose Deploy a specifically focused content file with directed use and access as governed by Membership rules. Under normal circumstances, Jordan can only display files. Only Jordan and the Trusted Allies are allowed access. In this case, Jordan is allowed full access and use of the directed file. (See Fig. 11)
  • Public Access CSC - Contains an unclassified image/text file that is intended for full public disclosure and dissemination.
  • the image/text could depict or describe any event, possibly medal award ceremony.
  • Membership access is controlled in order for the Command authority to affect dissemination time and source authenticity. All membership groups would also be provided access to this file.
  • Purpose Deploy a public relations/media content file whose dissemination timing and source authenticity can be controlled by the Command autho ⁇ ty. At a fixed future time, only those with authorized Membership status can open the file. Assumed to be available to all members in the chain of command. (See Fig. 11) While the present invention has been described with reference to certain preferred embodiments, it is to be understood that the present invention is not to be limited to such specific embodiments.
  • Email_Settings x lns :dt urn: schemas-microsoft-com-. datatypes' ⁇ ⁇ Individual>

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L"invention porte sur un système de gestion d"informations numériques circulant entre un expéditeur et un ou plusieurs destinataires comportant: (i) un empaqueteur d"informations numériques selon un ensemble de règles spécifiées par l"expéditeur et des informations de niveau d"accès; (ii) un ou plusieurs moteurs sécurisés de transmission des informations en paquets entre l"expéditeur et le ou les destinataires; (iii) un programme de rendu manipulant les informations numériques reçues en fonction desdites règles et desdits niveaux d"accès aux informations, associés aux différents destinataires.
PCT/US2001/046818 2000-11-07 2001-11-07 Procedes relatifs a un environnement partage securise WO2002039224A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US24633800P 2000-11-07 2000-11-07
US24642000P 2000-11-07 2000-11-07
US60/246,338 2000-11-07
US60/246,420 2000-11-07

Publications (2)

Publication Number Publication Date
WO2002039224A2 true WO2002039224A2 (fr) 2002-05-16
WO2002039224A3 WO2002039224A3 (fr) 2002-08-22

Family

ID=26937904

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/046818 WO2002039224A2 (fr) 2000-11-07 2001-11-07 Procedes relatifs a un environnement partage securise

Country Status (1)

Country Link
WO (1) WO2002039224A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8291224B2 (en) 2005-03-30 2012-10-16 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US9954848B1 (en) 2014-04-04 2018-04-24 Wells Fargo Bank, N.A. Central cryptographic management for computer systems

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4791565A (en) * 1984-06-20 1988-12-13 Effective Security Systems, Inc. Apparatus for controlling the use of computer software
EP1515216B1 (fr) * 1995-02-13 2014-09-24 Intertrust Technologies Corporation Systèmes et procédés de gestion de transactions sécurisées et de protection de droits électroniques
AU1690597A (en) * 1996-01-11 1997-08-01 Mitre Corporation, The System for controlling access and distribution of digital property
EP0912954B8 (fr) * 1996-07-22 2006-06-14 Cyva Research Corporation Outil d'echange et de protection d'informations personnelles
US5958005A (en) * 1997-07-17 1999-09-28 Bell Atlantic Network Services, Inc. Electronic mail security

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8291224B2 (en) 2005-03-30 2012-10-16 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US8635446B2 (en) 2005-03-30 2014-01-21 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US9634834B1 (en) 2005-03-30 2017-04-25 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US11477011B1 (en) 2005-03-30 2022-10-18 Wells Fargo Bank, N.A. Distributed cryptographic management for computer systems
US9954848B1 (en) 2014-04-04 2018-04-24 Wells Fargo Bank, N.A. Central cryptographic management for computer systems
US11212273B1 (en) 2014-04-04 2021-12-28 Wells Fargo Bank, N.A. Central cryptographic management for computer systems
US12126610B1 (en) 2014-04-04 2024-10-22 Wells Fargo Bank N.A. Central cryptographic management for computer systems

Also Published As

Publication number Publication date
WO2002039224A3 (fr) 2002-08-22

Similar Documents

Publication Publication Date Title
US11349819B2 (en) Method and system for digital rights management of documents
US7467415B2 (en) Distributed dynamic security for document collaboration
JP4575721B2 (ja) ドキュメント・コンポーネント用セキュリティ・コンテナ
RU2332704C2 (ru) Публикация цифрового содержания в определенном пространстве, таком как организация, в соответствии с системой цифрового управления правами (цуп)
US7930757B2 (en) Offline access in a document control system
RU2344469C2 (ru) Публикация цифрового содержания в определенном пространстве, таком, как организация, в соответствии с системой цифрового управления правами (цуп)
RU2501081C2 (ru) Многофакторная защита контента
US8627489B2 (en) Distributed document version control
US8627077B2 (en) Transparent authentication process integration
CN1713106B (zh) 为应用程序提供保密和授权应用程序访问保密对象的方法
US7707642B1 (en) Document access auditing
EP1303097A2 (fr) Systeme virtuel réparti de sécurité
US20130212707A1 (en) Document control system
US20070271618A1 (en) Securing access to a service data object
JPH1185622A (ja) コア・データ機密事項の保護記憶
EP1867095A2 (fr) Procede et systeme pour creer des espaces de projet virtuels securises
GB2378539A (en) Controlling propagation of decryption keys
EP4218204B1 (fr) Commande de fichier chiffré
Petrovska et al. Soa approach-identity and access management for the risk management platform
Miller et al. Security for the Meteor workflow management system
WO2002039224A2 (fr) Procedes relatifs a un environnement partage securise
Birnstill et al. Building blocks for identity management and protection for smart environments and interactive assistance systems
Abghour et al. Specification of authorisation services
Karp et al. The client utility architecture: the precursor to E-speak
Nicomette et al. Intrusion-tolerant fine-grained authorization for Internet applications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CA CN JP KR SG US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

AK Designated states

Kind code of ref document: A3

Designated state(s): CA CN JP KR SG US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A OF 22.07.2003)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载