Method and apparatus for generating a figure of merit for use in transmission of messages in a multi-level secure environment

PRIORITY AND RELATED APPLICATION INFORMATION

p-0002This application claims priority from U.S. Provisional Patent Application Ser. No. 61/162,774, filed Mar. 24, 2009, and U.S. Provisional Patent Application Ser. No. 61/253,243, filed Oct. 20, 2009, the contents of which are incorporated herein by reference in their entireties.

p-0003This application is related to co-filed applications U.S. patent application Ser. No. 12/652,266 entitled “METHOD AND APPARATUS FOR SIMULATING A WORKFLOW AND ANALYZING THE BEHAVIOR OF INFORMATION ASSURANCE ATTRIBUTES THROUGH A DATA PROVIDENCE ARCHITECTURE”, U.S. patent application Ser. No. 12/652,298 entitled “METHOD AND APPARATUS FOR PROVIDING INFORMATION ASSURANCE ATTRIBUTES THROUGH A DATA PROVIDENCE ARCHITECTURE”, and U.S. patent application Ser. No. 12/652,356 entitled “METHOD AND APPARATUS FOR MONITORING AND ANALYZING DEGREE OF TRUST AND INFORMATION ASSURANCE ATTRIBUTES INFORMATION IN A DATA PROVIDENCE ARCHITECTURE WORKFLOW”, the contents of which are incorporated herein by reference in their entireties.

BACKGROUND

p-00041. Field of the Disclosed Embodiments

p-0005The disclosed embodiments relate to message integrity verification techniques.

p-00062. Introduction

p-0007In conventional communications environments, data provenance involves tracking the origin of data and subsequent transformations performed on the data. This process is useful for “large science” projects in areas like astronomy, genetics, etc. where a large repository of data is continually being modified and it is important to validate and be able to recreate results derived from the data repository. However, data source and processing information, such as data provenance information, may mot be able to be transmitted across security boundaries.

SUMMARY

p-0008A method and apparatus that generates a figure of merit for use in transmission of messages in a multi-level secure environment is disclosed. The method may include receiving a message having a data provenance wrapper, wherein the message may or may not have attachments and the data provenance wrapper contains a data provenance record with data provenance information for the message and each attachment, examining each data provenance record of the message and any attachments for discrepancies, wherein the examination of each data provenance record of the message and any attachments includes: verifying signatures of senders of the message and any attachments, calculating a hash value for the message and any attachments, verifying that the hash value for the message and any attachments matches the values in the data provenance record for the message and any attachments, verifying the timestamp of the message and any attachments, and verifying information assurance attributes of the message and any attachments, the information assurance attributes being at least one of authenticity, confidentiality, integrity, non-repudiation, and availability, identifying any discrepancies in the examination of each data provenance record of the message and any attachments, generating a figure of merit based on objective and subjective information, wherein the objective and subjective information includes at least one of information assurance attributes, certificate of authority confidence information, and workflow component confidence information, substituting the figure of merit for the data provenance information, and transmitting the figure of merit with the message across the security domain.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0009In order to describe the manner in which the above-recited and other advantages and features of the disclosed embodiments can be obtained, a more particular description of the disclosed embodiments briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical disclosed embodiments and are not therefore to be considered to be limiting of its scope, the disclosed embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

p-0010<figref idrefs="DRAWINGS">FIG. 1</figref> is an exemplary diagram of a communication network environment in accordance with a possible embodiment of the disclosure;

p-0011<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary communication device in accordance with a possible embodiment of the disclosure;

p-0012<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of the wrapping and de-wrapping process in accordance with a possible embodiment of the disclosure;

p-0013<figref idrefs="DRAWINGS">FIG. 4</figref> is a diagram of an exemplary message envelope in accordance with a possible embodiment of the disclosure;

p-0014<figref idrefs="DRAWINGS">FIG. 5</figref> is a diagram of an exemplary message envelope with attachments in accordance with a possible embodiment of the disclosure; and

p-0015<figref idrefs="DRAWINGS">FIGS. 6A</figref> and B are an exemplary flowchart illustrating one figure of merit generation process in accordance with one possible embodiment of the disclosure.

DETAILED DESCRIPTION

p-0016Additional features and advantages of the disclosed embodiments will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the disclosed embodiments. The features and advantages of the disclosed embodiments may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present disclosed embodiments will become more fully apparent from the following description and appended claims, or may be learned by the practice of the disclosed embodiments as set forth herein.

p-0017Various embodiments of the disclosed embodiments are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosed embodiments.

p-0018The disclosure may describe a variety of embodiments, such as a method and apparatus and other embodiments that relate to the basic concepts of the disclosed embodiments.

p-0019The disclosed embodiments may concern data provenance which may involve tracking the origin of data and subsequent transformations performed on it. In particular, the disclosed embodiments may concern the use of data provenance techniques and information that needs to be added to an existing messaging system to provide data provenance. Two parts may be described and utilized as separate pieces, namely the original messaging system and the data provenance section. This division may simplify both the addition and removal of any data provenance information. Real world implementations may provide the desired fields by (a) changing the message format used for a Service Oriented Architecture (SOA) system, or (b) by augmenting an existing SOA-based workflow. Separating the two components also provides flexibility in implementation.

p-0020This system may be designed to work with both peer-to-peer and message/workflow services. In an SOA, client applications may talk directly to the SOA servers and processes communicate using protocols like Simple Object Access Protocol—(SOAP) or Representational State Transfer (REST), for example. The disclosed embodiments may have a routing service that supports both explicit destinations and role-based destinations and the framework may be language-independent, for example.

p-0021The data provenance data may be decoupled from the actual message. That is, the data provenance information may be sent in parallel with the actual message. This process may allow the data provenance section to be sent independently from the normal workflow. Data provenance records may then be associated with the message. However, data provenance records may also be transmitted using a separate communication channel. Note that may also be possible to use Out-Of-Band SOAP headers to include the data provenance data in the same packet as the message itself.

p-0022The data provenance system should allow flexible implementations. Multiple SOA systems can exchange data over the SOA enterprise bus. Some systems may act like routers in forwarding messages to the proper workflow recipient. For instance, the sending system may send the information to a role, such as an “analyst”. A workflow system may then decide on the next available analyst, and forward the message to that individual, for example. The data provenance system may also support the use of gateways, protocols that encapsulate (or tunnel) data, multi-level security, and encrypted data, for example.

p-0023However, data source and processing information, such as data provenance information, may mot be able to be transmitted across security boundaries. To overcome this limitation, the trust in data may be captured via a figure of merit. In this manner, as the data (or message) crosses a security domain, if the data provenance information cannot be passed on, then the data provenance information may be replaced by the figure of merit value.

p-0024The figure of merit may be calculated from a number of components. These components may be classified as objective and subjective information, for example. The objective values may be independent of an analyst and can be incorporated automatically in the determination of figure of merit. Subjective values may depend on an analyst doing the analysis and the context of the workflow. The subjective value that an analyst places on an entity may even evolve over time.

p-0025The objective and subjective information may include: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0025">The values associated with the Information Assurance attributes of Authenticity, Confidentiality, Integrity, Non-Repudiation and Availability which may be objective values.</li><li id="ul0002-0002" num="0026">The confidence in Certificate Authority that provide certificates involved in the workflow which may have objective as well as subjective component.</li><li id="ul0002-0003" num="0027">The confidence in the components of the workflow which may be subjective.</li></ul></li></ul>

p-0026The data provenance architecture may be flexible and may automatically capture objective values and allow analysts to specify their subjective confidence in workflow components. These subjective and objective values may then combined to generate a figure of merit value for transmission with the message.

p-0027<figref idrefs="DRAWINGS">FIG. 1</figref> is an exemplary diagram of a communication network environment <b>100</b> in accordance with a possible embodiment of the disclosure. In particular, the communication network environment <b>100</b> may include one or more communication devices <b>120</b>, <b>130</b>, <b>140</b> which may communicate through communication network <b>110</b>. Communications network <b>110</b> may represent any communications network used to communicate with other entities, including the Internet, an intranet, a radio network, a wireless network, hardwired network, satellite network, etc.

p-0028The communication devices <b>120</b>, <b>130</b>, <b>140</b> may be any device capable of sending and receiving messages and/or attachments, such as a processing device, a mobile communication device, a portable computer, a desktop computer, a server, a network router, a gateway device, or combinations of the above, for example.

p-0029<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary communication device <b>120</b>, <b>130</b>, <b>140</b> in accordance with a possible embodiment of the disclosure. The exemplary communication device <b>120</b>, <b>130</b>, <b>140</b> may include a bus <b>210</b>, a processor <b>220</b>, a memory <b>230</b>, a read only memory (ROM) <b>240</b>, a data provenance information analysis unit <b>250</b>, a user interface <b>260</b>, a communication interface <b>270</b>, and a figure of merit generator <b>280</b>. Bus <b>210</b> may permit communication among the components of the communication device <b>120</b>, <b>130</b>, <b>140</b>.

p-0030Processor <b>220</b> may include at least one conventional processor or microprocessor that interprets and executes instructions. Memory <b>230</b> may be a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor <b>220</b>. Memory <b>230</b> may also store temporary variables or other intermediate information used during execution of instructions by processor <b>220</b>. ROM <b>240</b> may include a conventional ROM device or another type of static storage device that stores static information and instructions for processor <b>220</b>. Memory <b>230</b> may include an internal or external storage device that may include any type of media, such as, for example, magnetic or optical recording media and its corresponding drive.

p-0031User interface <b>260</b> may include one or more conventional input mechanisms that permit a user to input information, communicate with the communication device <b>120</b>, <b>130</b>, <b>140</b> and/or present information to the user, such as a an electronic display, microphone, touchpad, keypad, keyboard, mouse, pen, stylus, voice recognition device, buttons, one or more speakers, etc. Communication interface <b>270</b> may include any transceiver-like mechanism that enables the communication device <b>120</b>, <b>130</b>, <b>140</b> to communicate via a network. For example, communication interface <b>270</b> may include a modem, or an Ethernet interface for communicating via a local area network (LAN). Alternatively, communication interface <b>270</b> may include other mechanisms for communicating with other devices and/or systems via wired, wireless or optical connections. In some implementations of the communication device <b>120</b>, <b>130</b>, <b>140</b>, communication interface <b>270</b> may not be included in the exemplary communication device <b>120</b>, <b>130</b>, <b>140</b> when the communication process is implemented completely within the communication device <b>120</b>, <b>130</b>, <b>140</b>.

p-0032The communication device <b>120</b>, <b>130</b>, <b>140</b> may perform such functions in response to processor <b>220</b> by executing sequences of instructions contained in a computer-readable medium, such as, for example, memory <b>230</b>, a magnetic disk, or an optical disk. Such instructions may be read into memory <b>230</b> from another computer-readable medium, such as a storage device, or from a separate device via communication interface <b>270</b>.

p-0033The communication network environment <b>100</b> and the communication devices <b>120</b>, <b>130</b>, <b>140</b> illustrated in <figref idrefs="DRAWINGS">FIGS. 1 and 2</figref> and the related discussion are intended to provide a brief, general description of a suitable computing environment in which the disclosed embodiments may be implemented. Although not required, the disclosed embodiments will be described, at least in part, in the general context of computer-executable instructions, such as program modules, being executed by the communication device <b>120</b>, <b>130</b>, <b>140</b>, such as a general purpose computer. Generally, program modules include routine programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that other embodiments of the disclosed embodiments may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.

p-0034Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

p-0035<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of the wrapping and de-wrapping process <b>300</b> in accordance with a possible embodiment of the disclosure. A possible system level objective while adding data provenance information is to do it with minimal impact on an existing workflow. The existing workflow is shown at the top as a message being sent from process<b>1</b>/person<b>1</b><b>310</b> to process<b>2</b>/person<b>2</b><b>320</b>.

p-0036In the disclosed embodiments, wrappers <b>340</b> may be used in the message sending process <b>330</b> that will add the appropriate data provenance information and a de-wrapper<b>1</b><b>360</b> will be used in the message receiving process <b>350</b> that will strip the data provenance information before the message reaches its destination.

p-0037Note that the data providence architecture of the disclosed embodiments may be a peer-to-peer architecture or a service oriented architecture, for example.

p-0038<figref idrefs="DRAWINGS">FIG. 4</figref> is a diagram of an exemplary message envelope <b>400</b> in accordance with a possible embodiment of the disclosure. The exemplary message envelope <b>400</b> may include an envelope <b>410</b>, a message list <b>420</b>, one or more messages <b>430</b>, <b>440</b>, a data provenance list <b>450</b>, one or more data provenance records <b>460</b>, <b>470</b> that correspond to the one or more messages <b>430</b>, <b>440</b>, and an information assurance verification section <b>480</b>. The exemplary data provenance record <b>400</b> may also include one or more attachments, as discussed below in relation to <figref idrefs="DRAWINGS">FIG. 5</figref>.

p-0039A system providing data provenance may include two types of information components: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0042">A message list (messages in a list format which may include attachments and/or references to additional messages)</li><li id="ul0004-0002" num="0043">Data provenance records</li></ul></li></ul>

p-0040The message list may be a list of messages. There may be at least one message and one data provenance record. However, the data provenance records may be created in parallel of an existing workflow. For example, the data provenance records can be created at a higher security level than the messages. Attachments may be included in this list.

p-0041The message body may be the data being sent. It may be text, images, etc. Each message may have a unique message-identification (ID) value. Attachments may be considered messages as well therefore; they may also have a unique message-ID.

p-0042Attackers may attempt to fabricate and modify messages. The data provenance verification may detect these attempts if proper information is available. However, it is important that different messages do not have identical message-ID values.

p-0043Note that one way to reduce the risk of collisions of message-ID's is to force each entity to have a unique name, and to base the message-ID on the entity name combined with a value—either based on date and time, or based on a monotonically increasing integer. The message ID may also include a reference to the location of the message in a message retrieval system (similar to a Uniform Resource Locator or URL in a web browser). The disclosed embodiments may have the ability to archive and retrieve messages based on the message-ID value so that someone may verify the data provenance with first-hand investigation.

p-0044Note that the message may include a variant part and an invariant part (note, however, that it may be possible that the entire message will be invariant). The variant part may contain information that changes such as, for example, the routing information as the message is forwarded.

p-0045The invariant part may always contain the same values, or can be combined, reassembled, converted or reordered to have the same value. The data provenance information may include information from the invariant part of the message. For example, hash algorithm identification information and a hash value may be data provenance information that are included in the invariant part of the message. Any system that retrieves the message, converts the message into a predetermined format, and calculates a one-way hash of that message, will always get the same value, and the hash value stored in the data provenance record. Note that multiple formats, hash algorithms, and hash values may be used as part of the data provenance record. Alternately, a digital signature can be stored in a data provenance record instead of a hash and hash value.

p-0046When the invariant part is described, it is important to note that it is the components that are invariant. The process may store the components in multiple places, and the message body may not even be part of the data provenance record. But in validating the data provenance record, these components must be re-assembled into a known order, and the hash can therefore be calculated,

p-0047Certain fields may be contained inside the invariant section of the message. These fields may be included when the hash of the message is calculated, and therefore may be authenticated. Some of the fields may include: <ul><li id="ul0005-0001" num="0000"><ul><li id="ul0006-0001" num="0052">Message-ID</li><li id="ul0006-0002" num="0053">Creator of the message (e.g. From) (Note: The creator of the message may be part of the message-ID. For instance, if it comes from a machine, the message-ID might be created by concatenating the machine name and the timestamp.)</li><li id="ul0006-0003" num="0054">Security Label: This field may contain the security classification as specified by the creator. Could be left undefined.</li><li id="ul0006-0004" num="0055">To—the destination—by name or by role (while both of these fields could be null, it is assumed for this discussion that at least one is non-null. If both are specified, applications may determine how to handle possible inconsistencies. The process may have a similar structure for the From field.)</li><li id="ul0006-0005" num="0056">References: Any message-ID values of attached messages.</li><li id="ul0006-0006" num="0057">Message-Body—The contents of the message (may also be stored elsewhere).</li><li id="ul0006-0007" num="0058">Message Body Type—(Optional) used to distinguish between binary and ASCII.</li><li id="ul0006-0008" num="0059">MIME-Type—(Optional) Useful to display binary information.</li><li id="ul0006-0009" num="0060">Timestamp—(Optional) May reduce the risk of a replay attack.</li><li id="ul0006-0010" num="0061">Digital Signature—of a message. This performs a similar function as a hash and hash value.</li></ul></li></ul>

p-0048Variant fields might change when routing is applied. That is, the value of these fields may change as messages are routed through the workflow process. Examples might include: <ul><li id="ul0007-0001" num="0000"><ul><li id="ul0008-0001" num="0063">Route List—may be used for source routing</li><li id="ul0008-0002" num="0064">Next Hop Destination—Might change when messages are routed.</li></ul></li></ul>

p-0049The information assurance verification section of the message list may be used to verify the security attributes of the contents of the message (confidentiality, authenticity, integrity, non-repudiation, etc.), and would be provided by the SOA security stack. For example, if used for authentication, the information assurance verification section may contain a signature of the contents of the message list. If used for encryption, the information assurance verification section may include a reference to the encryption key.

p-0050Since data provenance records may reference one or more data provenance records, the actual data structure for a message may be complex (i.e., contain attachments). However, consider a single data provenance record of a message with no attachments. This process corresponds to a sender transmitting a message to a receiver; and so there are two different perspectives of any single message transmission—outgoing and incoming.

p-0051The outgoing perspective may be the intended transport data provenance characteristics from the perspective of the sender. The incoming may be the observed transport properties from the receiver's perspective. The appropriate party may sign each perspective. The receiving perspective may include the outgoing (intended) perspective. Therefore, the receiving party may sign the data provenance record from the sending party.

p-0052The sender's data provenance section may include the following pieces of information <ul><li id="ul0009-0001" num="0000"><ul><li id="ul0010-0001" num="0069">Message-ID—this must be unique. This may also provide enough information for someone who wishes to verify the data provenance record to retrieve the message.</li><li id="ul0010-0002" num="0070">Outgoing Security Attributes—These are the security characteristics of the message from the sender's perspective. This may include measurements of confidentiality, authenticity, and integrity (may also include channel availability).</li><li id="ul0010-0003" num="0071">Timestamp—This might be optional, but is recommended as it provides extra protection for availability and non-repudiation analysis. Note that information that is more accurate may be obtained with a synchronized clock.</li><li id="ul0010-0004" num="0072">Owner of the signature—This may provide information to someone who wishes to verify the signature.</li><li id="ul0010-0005" num="0073">Hash of the Invariant part of the message—If one were to obtain the message specified by message-ID, and perform a one-way hash function as specified in the next field, this field may store the resulting value. Note that it may include all of the fields in the invariant section, for example.</li><li id="ul0010-0006" num="0074">The Hash Algorithm used—Given this information, and the message, someone may obtain the message, calculate the hash, and see if it agrees with the hash value in the data provenance record.</li><li id="ul0010-0007" num="0075">Security Label—To simplify data classification of a multi-part message.</li><li id="ul0010-0008" num="0076">Digital Signature—of a message. This performs a similar function as a hash and hash value.</li><li id="ul0010-0009" num="0077">Optional Information—As needed for specific applications.</li></ul></li></ul>

p-0053Note that there may be benefits of including the recipient's name in the sender's data provenance section, as that would allow a recipient to check if the message was intended for him/her and not that he/she received it due to some error or deliberate intent. This is importance especially when the message recipient is determined as it is forwarded and the real recipient information is in variant part which can easily be modified without detection.

p-0054The sender's data provenance information may be used to verify the data provenance of a message. That is, if one obtained a message referred to by the record, combined with this record, they may verify that the creator of the record saw the message (or at least makes the claim that they saw the message) whose hash is inside the data provenance record. That is, one may decrypt the signature using the public key of the owner, and the results should match the hash of the invariant part of the message. The message may either be sent with the data provenance record, or retrieved after reading the data provenance record, using the message-ID as a means to locate and retrieve the message. More than one hash type and value may be stored in the data provenance record. Another implementation may store one or more digital signatures of the message as part of the data provenance record. This allows multiple mechanisms to be used to verify the integrity and/or the authenticity of the message. This allows verification by multiple authorities and technologies, in case of a failure.

p-0055Some of the information may be missing, however. For instance, suppose a sender does not provide any data provenance information to a receiver. The receiver may fill in empty values into the appropriate fields. This might happen in case an embedded system (such as an Unmanned Aerial Vehicle (UAV)) sends information from the sensor to an Automatic Target Recognition (ATR) system. The receiver may provider the sender's ID in the record, leave the hash and signature blank, fill in its section, and sign the resulting information.

p-0056Note that the message ID of the attachment may not need to be specified in this data provenance record, as it may be specified inside the message itself. Some implementations may wish to include references to messages inside the data provenance record.

p-0057Note also that the user and/or the application may sign the data provenance record. The XML stack may perform the signature in the XML envelope, for example. Therefore, the certificates and the signing algorithm might differ. The signature for the data provenance might be performed by a multi-purpose private key, or a dedicated key may be used, for example. However, some systems may lack the ability to sign a document, and as such, the signature information may be blank. The receiver may provide/modify the information if the data provenance record was not signed.

p-0058When receiving the message, the receiver may add data provenance information for analysis. The data that may be signed by the receiver may include the sender's signed information, for example. The data (and function) of the receiver's data provenance record may be similar to the sender's data provenance information. However, the information may not include the message ID because that information is included in the sender's data provenance information. By having the receiver sign the sender's data provenance record, the process may provide non-repudiation in case the sender denies sending the message.

p-0059The hash value and algorithm may be included in case the sender and receiver use different hash algorithms (or if the sender does not provide the information). More than one hash and hash value pair may be provided.

p-0060After a message is transmitted (that is, it goes from the sender to receiver), a completed data provenance record may be created. To simplify the parsing of the data provenance records, the sender may transmit a completed data provenance record, but with the receiver's section blank. When the receiver accepts the message, it may complete its section and sign the record. This process may waste bits but may simplify the implementation.

p-0061The data provenance information may be used towards each of the information assurance attributes. These information assurance attributes can be used to address various attacks as set forth below.

p-0062Authenticity: Since each data provenance record may be signed by the sender, anyone receiving the message may: <ul><li id="ul0011-0001" num="0000"><ul><li id="ul0012-0001" num="0088">1. Examine the message;</li><li id="ul0012-0002" num="0089">2. Calculate the hash of the message using the same algorithm as specified by the sender;</li><li id="ul0012-0003" num="0090">3. Obtain the name of the user from the data provenance record;</li><li id="ul0012-0004" num="0091">4. Verify that the name of the user is also inside the message as well (so that someone can not pretend to be the author) and make sure they agree;</li><li id="ul0012-0005" num="0092">5. Encrypt the hash with the public key of the sender; and</li><li id="ul0012-0006" num="0093">6. Determine if the hash value agrees with the one stored inside the data provenance record.</li><li id="ul0012-0007" num="0094">Alternately, a digital signature can be used, as the signature contains the owner, encrypted hash value, and hash type. The signature can also be created by another, allowing for a second part to authenticate a message, or verify the integrity of the message.</li></ul></li></ul>

p-0063Integrity: Since a hash function is a one-way calculation based on the contents of the message, it may be used to verify the integrity. If the authentication step is done, the integrity may also be checked. Note that integrity may be checked even if the data provenance record is not signed. However, the sender of the information may not be validated. One may just ensure the message arrived intact because the receiver and the sender validate the hash values. The final recipient may also verify if what was received is the same message as the one sent by original source, by verifying that the hash values are identical.

p-0064Confidentiality: It may be impossible to verify that a message is confidential, as a true attack may be completely passive, and cannot be measured. A secure channel may have a covert monitoring device. However, one can verify that the sender intended to send a message using an encrypted channel or if due to some error, a message was received was not encrypted, and therefore one may infer that it may not be confidential.

p-0065Since there is a data provenance record for every hop, each hop may be examined independently to ensure all information assurance attributes. However, if integrity is needed, but not authenticity, only the first and last hop may be examined. If any of the hops were not encrypted, then there may have been an unintentional exposure of confidential information.

p-0066There may be four conditions that may be examined at each hop:

p-0067<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Encryption Perspective over a Hop</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><tbody valign="top"><row><entry /><entry /><entry>Sender's</entry><entry>Receiver's</entry><entry /></row><row><entry /><entry>Case #</entry><entry>perspective</entry><entry>Perspective</entry><entry>Conclusion</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>1</entry><entry>Encrypted</entry><entry>Encrypted</entry><entry>Encrypted</entry></row><row><entry /><entry>2</entry><entry>Encrypted</entry><entry>Unencrypted</entry><entry>Error or Attack</entry></row><row><entry /><entry>3</entry><entry>Unencrypted</entry><entry>Encrypted</entry><entry>Error or Attack</entry></row><row><entry /><entry>4</entry><entry>Unencrypted</entry><entry>Unencrypted</entry><entry>Unencrypted</entry></row><row><entry /><entry namest="offset" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0068In Case 1, the conclusion may be that the message was transmitted encrypted, to the best knowledge of the participants. Either one may publish the information using another channel, for example, which lowers the confidentiality of the message. However, if one party published the information, the other may not detect this by examining the data provenance records. Also, the data provenance records indicate the number of parties that did have access to a message, and the calculation of the confidentiality may be based on the number of individuals who have access to the information. For example, the larger the number of people who have access to a message, the greater risk in the loss of confidentiality of the message.

p-0069In Case 4, both parties may conclude that the message was not sent in a confidential form.

p-0070In Case 2, the receiver may receive a message that was encrypted but arrived unencrypted. This situation may indicate a bug in the implementation, or if the message cannot be authenticated, it may be an intrusion, such as replay attack or a man-in-the-middle attack, for example.

p-0071In Case 3, the message was sent unencrypted, but is received encrypted. This situation may indicate either be an implementation error, the sender is mistaken, or a man-in-the-middle attack with the input unencrypted but with the output that is encrypted, for example. One instance may involve a dumb device transmitting a message using a secure communication channel, but the receiver is more sophisticated and knows the channel is secure, for example. In this case, the receiver may state the channel was secure because it has additional knowledge, or more sophistication, than the sender.

p-0072Both case 2 and 3 may also occur if either party intentionally lies about the characteristics. Someone might accuse the other party that they made a mistake, and lied about the characteristics to provide “evidence.” Unfortunately, there may be no way to determine which party is fabricating information without an observation from a third party (log files, etc.).

p-0073If no logs or third party auditing is done then that may potentially cause a problem. One could create a data provenance record on a data provenance record to make sure it has not been tampered with. However, this process may only protect the data about the transmission, and not the data that was transmitted.

p-0074If multi-hops occur, the entire chain from origination source to destination may have to be examined. If there are discrepancies, they may have to be resolved. External knowledge may be necessary to properly evaluate the risk of eavesdropping, for example.

p-0075Non-Repudiation: The data provenance records, by their very nature, may provide protection from non-repudiation. Since the data provenance records may be signed, it may be difficult for someone to retract this statement. For example, someone could send a message, and then claim that their key was compromised. One may have to examine the sequence of events to determine if the retraction occurred while the key was considered secure or not. One could also claim the message was not sent at the time that was logged. However, the receiver places a timestamp on the message, and then signs it, so it becomes harder for the sender to lie about the time the message was sent.

p-0076The timestamp may also be useful in dealing with compromised and expired certificates. Someone can claim that their digital signature has been compromised. The timestamp may provide a timeline of any activity, which may be used to verify any claims.

p-0077Availability: There may be two different ways this architecture can be used to detect attacks on availability. The first approach may assume the data provenance analyst knows historical information about transmission times. The second approach may be used if the data provenance system provides historical information along with the record.

p-0078In the first approach, the data provenance records, if the timestamp is included, may provide the information to determine the total transmission time for each hop. There are two transmission models that may be used, reliable and unreliable. If a reliable transmission model is used, (e.g. TCP) then the sender may include in the data provenance record at the time it was initiated. The receiver may record the time the message arrived. The difference between these two times may provide the total transmission time. If the “typical” time is, 5 minutes for example, and one of the data provenance records indicates the arrival time was 5 hours, this might be an indication of some attack (or some other system problem), for example.

p-0079If an unreliable transmission model is used (e.g., User Datagram Protocol (UDP)), then there may need to be historical information to determine if there is a problem. For instance, if the data provenance record indicates the source normally sends out a report every 15 minutes, then if one examined the record for a time period, and counted how many times reports arrived during that time, this information might indicate an attack. In another instance, if the previous report was 2 hours ago, and there should have been 8 reports during this period, but only one arrived, then perhaps an attack occurred.

p-0080Another way to detect attacks may be to have a monotonically increasing value. That is, if each report had a number, such as 1, 2, 3, 4, 5, . . . and the current report has a value of 22, then if there was no record of report <b>21</b> arriving, then this might indicate an attack.

p-0081A second mechanism may be used to detect availability, but this mechanism may require knowledge of the sender and/or the receiver. If we assume that the sender and/or receiver have knowledge about the availability from their perspective, they may include this information in the data provenance records. For example, if a receiver is getting transmission errors, the number of retries needed to receive a message may double. If the receiver included this information in the data provenance record, the data provenance analyzer may use this information, and past knowledge, to consider whether there was an attack on availability.

p-0082Replay and Freshness: The data provenance analysis may also detect replay attacks. There may be two mechanisms that can be used.

p-0083The first mechanism may be the analysis of the timestamp records. This process assumes knowledge of previous transmissions. Someone could capture and intercept a message, and retransmit it later, for example. If scenario occurred, the data provenance record would have a timestamp that may be much earlier that expected. In this example, the scenario may be very similar to an attack on availability, as the message may be simply delayed. The difference may be a question of degree to distinguish between a delaying attack (on availability) and a replay attack if the receiver has no way to detect old messages. Also, note that a variation may cause packets to arrive out of order. Unusual activity may also indicate some sort of attack.

p-0084If the receiver or data provenance analysis keeps track of messages, and can detect messages that have arrived earlier, then it may become easier to detect a true replay attack, assuming the transmission mechanism does not create duplicate messages.

p-0085<figref idrefs="DRAWINGS">FIG. 5</figref> is a diagram of an exemplary message envelope <b>500</b> with attachments in accordance with a possible embodiment of the disclosure. The exemplary message envelope <b>500</b> may include an envelope <b>505</b> and within the envelope the information assurance verification section <b>560</b> and within that, a message list <b>510</b>, one or more messages <b>515</b>, one or more attachments <b>520</b>, a data provenance list <b>525</b>, and one or more data provenance records <b>530</b>/<b>535</b>, <b>540</b>/<b>545</b>, <b>550</b>/<b>555</b> that correspond to the one or more messages <b>515</b> and/or attachments <b>520</b>.

p-0086In each transmission of a message, there may be multiple data provenance records added. In the case of a message being forwarded unchanged, then each hop may provide a data provenance record, for example. Forwarded messages may occur if the message is unchanged, for example. In other words, in the case of workflow routers, or someone who uses a messaging service, a data provenance record may be added even though the message is unchanged.

p-0087For instance, if Alice sends a message M<b>1</b> to Bob, who forwards it to Carol, who forwards it to Dave, then there may be 3 data provenance records sent with message M<b>1</b> to Dave: <ul><li id="ul0013-0001" num="0000"><ul><li id="ul0014-0001" num="0120">Alice to Bob of message M<b>1</b></li><li id="ul0014-0002" num="0121">Bob to Carol of Message M<b>1</b></li><li id="ul0014-0003" num="0122">Carol to Dave of Message M<b>1</b></li></ul></li></ul>

p-0088Since the message is unchanged, and potentially verifiable, this route information may not need to be retained. Therefore, Dave could accept the message from Carol, but create a data provenance record with Alice in the sender's section. The other records may be deleted in the data provenance record. For instance, if the route from Bob to Carol to Dave is though an encrypted tunnel in a MLS system, the data provenance records containing information about Carol and perhaps Bob could be removed. Carol may create a single data provenance record showing that Alice sent the message to Dave directly. However, the “To” information in the invariant portion of M<b>1</b> may still remain and could identify Bob as the original recipient of M<b>1</b>. If the invariant part of the message did not include the intended receiver (i.e. the “To” field), it may be impossible to detect misrouted messages.

p-0089Alternatively, the entire data provenance record may be retained. This process may be important if the originating message was not signed and verified (i.e. from an untrusted source). In this scenario, the route from Alice to Bob, Carol and Dave may be important because Alice's ID could not be verified.

p-0090If the message is going from a high security level to a lower level, it may be necessary to remove all trace of the original source. This removal may be performed by creating a proxy author (alternatively, the security gateway might perform this creation), for example.

p-0091The second type of data provenance record may be one where a new message is created, with the previous message included or attached. If a device or person receives a message, and then forwards the message so the message is changed, it may create a new message and new message-ID. This message may identify the previous message by message-ID so any data provenance record associated with the included message may be found.

p-0092The disclosed embodiments may also support the analysis of the data provenance of complex messages. In other words, when Alice sends a message to Bob, who adds a note, and sends it with the original message attached to Carol, who forwards it to Dave, then Dave's system may be capable of performing a data provenance analysis of the data so as to determine the trustworthiness of the entire workflow.

p-0093This issue can be complex because data provenance is not a static event. Months later, one may wish to perform a data provenance analysis, and part of this analysis may concern non-repudiation. Certificates may have expired or be compromised between the original message and time that the analysis is performed. For instance, if Alice's certificate is compromised, then one may create false records of actions that Alice supposedly performed.

p-0094Another problem may be that messages may no longer exist, or may not be accessible by someone verifying the data provenance history. As an example, the record might have a different security classification. Therefore, one may not be able to retrieve the message to verify the hash. Instead, one may have to base a decision on the data provenance records of others.

p-0095A third issue may concern discrepancies between the sender's and receiver's security attributes. For example, Alice may send an encrypted message to Bob that is encrypted for confidentiality. Bob may receive the message, but claim that Alice purposely sent the message in clear text, thus violating security policy. Even though Alice has signed the document that makes claims about the transmission security attributes, Alice may insert incorrect information. Several solutions may be possible, but essentially the messaging system (such as XML) may act as a third party to resolve the issue.

p-0096Another issue may be the danger of a data provenance record being modified or changed after the fact. If a certificate is compromised, then someone who has the private key may fabricate data provenance records. This attack may allow an attacker to fabricate some of the fields, such as the security attributes of a received message. However, if the sender's attributes are signed, this fabrication may be detected by the process of the disclosed embodiments. In some cases, it might be necessary to create a data provenance record of receiving a data provenance record. However, note that data provenance records of data provenance records adds complexity, and it is not certain that this is needed in all cases.

p-0097Another implementation detail may be to ensure that when the data provenance analysis is done, all or some of the information may be available. Since some implementations may not have a mechanism to retrieve old messages, they also may not have a mechanism to retrieve old data provenance records. Therefore, a complete set of records may be provided that enables each receiver to analyze data provenance.

p-0098Messages may also contain attachments. <figref idrefs="DRAWINGS">FIG. 5</figref> shows a message with an attachment M<b>1</b>. In this example, the attachment may have message-ID values, which are referenced in message <b>1</b>. Note that if the number of messages is limited to one, with zero or more attachments, the first message may be the main message and the additional messages (<b>2</b> . . . n) may be attachments. There may also be a message type, which is used to distinguish between messages and attachments.

p-0099Note that if a message is included, then the old message may be made into an attachment, and a new message is created which references it. Also note that since the message-ID of the attachment is specified inside the message, the attachment may not be included as part of the message. If the system has a message retrieval system, the attachment may be obtained later, for example. As messages are stored and retrieved, data provenance records can be created, and also retrieved, so that an implementation using a message storage and retrieval system can have a complete record of every data transfer.

p-0100For illustrative purposes, the operation of the data provenance information analysis unit <b>250</b>, the figure of merit generator <b>280</b>, and the a figure of merit generation process will be described below in relation to the block diagrams shown in <figref idrefs="DRAWINGS">FIGS. 1-2</figref>.

p-0101<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary flowchart illustrating some of the basic steps associated with the figure of merit generation process in accordance with a possible embodiment of the disclosure. The process begins at step <b>6050</b> and continues to step <b>6100</b> where the data provenance information analysis unit <b>250</b> may receive a message through the communication interface <b>270</b> having a data provenance wrapper. The received message may or may not have attachments and the data provenance wrapper may contain a data provenance record with data provenance information for the message and each attachment.

p-0102The data provenance information may include message identification information, outgoing security attributes, timestamp, identification information of owner of signature, references, hash of an invariant part of the message, hash algorithm used, security label, authenticity objective information (based on processing device review, authentication of signatures, choice of algorithms of various strengths and encryption key lengths), authenticity subjective information (based on human input), confidentiality objective information, confidentiality subjective information, integrity objective information, integrity subjective information, availability objective information, availability subjective information, and sender's signature, for example.

p-0103At step <b>6150</b>, the data provenance information analysis unit <b>250</b> may examine each data provenance record of the message and any attachments for discrepancies. In order to examine each data provenance record of the message and any attachments, the data provenance information analysis unit <b>250</b> may perform steps <b>6200</b>-<b>6400</b> as set forth below.

p-0104At step <b>6200</b>, the data provenance information analysis unit <b>250</b> may verify signatures of senders of the message and any attachments. At step <b>6250</b>, the data provenance information analysis unit <b>250</b> may calculate a hash value for the message and any attachments. Alternately, it may verify a digital signature.

p-0105At step <b>6300</b>, the data provenance information analysis unit <b>250</b> may verify that the hash value for the message and any attachments matches the values in the data provenance record for the message and any attachments. At step <b>6350</b>, the data provenance information analysis unit <b>250</b> may verify the timestamp of the message and any attachments.

p-0106At step <b>6400</b>, the data provenance information analysis unit <b>250</b> may verify information assurance attributes of the message and any attachments, the information assurance attributes being at least one of authenticity, confidentiality, integrity, non-repudiation, and availability.

p-0107At step <b>6450</b>, the data provenance information analysis unit <b>250</b> may identify any discrepancies in the examination of each data provenance record of the message and any attachments.

p-0108At step <b>6500</b>, the figure of merit generator <b>280</b> may determine if the message is to be transmitted to a recipient across a security domain. If the figure of merit generator <b>280</b> determines that the message is not to be transmitted to a recipient across a security domain, at step <b>6550</b>, the data provenance information analysis unit <b>250</b> may calculate a degree of trust based on the security attributes and message identification information included in the message, the data provenance record and any discrepancies identified in the examination of each data provenance record of the message and any attachments. At step <b>6600</b>, the data provenance information analysis unit <b>250</b> may output the degree of trust to the user. The process may then go to step <b>6975</b> and end.

p-0109If at step <b>6500</b> the figure of merit generator <b>280</b> determines that the message is to be transmitted to a recipient across a security domain, at step <b>6650</b>, the figure of merit generator <b>280</b> may determine if the data provenance information can be transmitted with the message across the security domain. If the figure of merit generator <b>280</b> determines that the data provenance information can be transmitted with the message across the security domain, at step <b>6700</b>, the data provenance information analysis unit <b>250</b> may calculate a degree of trust based on the security attributes and message identification information included in the message, the data provenance record and any discrepancies identified in the examination of each data provenance record of the message and any attachments. At step <b>6750</b>, the data provenance information analysis unit <b>250</b> may output the degree of trust to the user. At step <b>6800</b>, the data provenance information analysis unit <b>250</b> may transmit the figure of merit with the message across the security domain using the communication interface <b>270</b>. The process may then go to step <b>6975</b> and end.

p-0110If at step <b>6650</b> the figure of merit generator <b>280</b> determines that the data provenance information cannot be transmitted with the message across the security domain, at step <b>6850</b> the figure of merit generator <b>280</b> may generate a figure of merit based on objective and subjective information. The objective and subjective information may include information assurance attributes, certificate of authority confidence information, and workflow component confidence information, for example.

p-0111At step <b>6900</b>, the figure of merit generator <b>280</b> may substitute the figure of merit for the data provenance information. At step <b>6950</b>, the figure of merit generator <b>280</b> may transmit the figure of merit with the message across the security domain using the communication interface <b>270</b>. The process may then go to step <b>6975</b> and end.

p-0112Embodiments within the scope of the disclosed embodiments may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.

p-0113Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

p-0114Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the disclosure are part of the scope of this disclosure. For example, the principles of the disclosed embodiments may be applied to each individual user where each user may individually deploy such a system. This enables each user to utilize the benefits of the disclosed embodiments even if any one of the large number of possible applications do not need the functionality described herein. In other words, there may be multiple instances of the disclosed embodiments each processing the content in various possible ways. It does not necessarily need to be one system used by all end users. Accordingly, the appended claims and their legal equivalents should only define the disclosed embodiments, rather than any specific examples given.