Techniques for attesting to content

[0001] The invention relates generally to security and more particularly to techniques for attesting to content received from an author (sender) over a network.

[0002] Increasingly more and more communication is occurring via the Internet. Electronic mail (email) is now a desired form of communication with most individuals and enterprises. Moreover, instant messaging, text messaging, and on-line chat forums are growing exponentially in their popularities. With these electronic communications, there are growing and crying needs for an improved ability to certify the authorship of content that is included with a message.

[0003] Email is a good example of the need to certify authorship of content. Consider that an average email user may receive tens or hundreds of emails daily. Some of the senders of these emails may appear to be known to the recipient, but because of the ease of spoofing the “From” field of an email, the email may not actually have originated from the sender that the recipient believes it to have come from. In addition, and even without spoofing, the average user may receive scores of emails from unknown sources on a daily basis, some of which the user may be interested in reading. These emails from spoofed known users and from unknown users are the basis of many virus attacks and provide the mechanism through which virus attacks are propagated.

[0004] The concept of securing email has been discussed, but it has not been implemented due to the overhead associated with managing the necessary certificates, which it is believed that such a deploying technology would require. The result is that secure email has been very limited in its deployment, and spammers and phishers continue to abound on the Internet.

[0005] Therefore, there is a need for techniques that attest to an author's content for purposes of verifying the content from that author (sender).

[0006] In various embodiments, techniques for attesting to content are presented. More specifically, and in an embodiment, a method for attesting to content is provided. Content is received in a message from a sender. A signed version of a message digest for the content is acquired from the message and the signed version of the message digest is attempted to be validated. In response to the validating, an appropriate policy is processed.

[0011] A “resource” includes a user, service, system, device, directory, data store, user, groups of users, combinations of these things, etc. A “principal” is a specific type of resource, such as an automated service or user that acquires an identity. A designation as to what is a resource and what is a principal can change depending upon the context of any given network transaction. Thus, if one resource attempts to access another resource, the actor of the transaction may be viewed as a principal.

[0012] A sender and a recipient are special types of resources. A sender (which may also be referred to as an author of content herein and below) constructs messages that have content and sends or transmits them over a network to one or more recipients. Again, a sender may become a recipient and vice versa depending upon the context of a transaction.

[0013] Another type of resource discussed herein is an identity service. The identity service can perform a variety of beneficial functions. Some example identity services may be found at U.S. patent application Ser. No. 10/765,523 entitled “Techniques for Dynamically Establishing and Managing Authentication and Trust Relationships;” at U.S. patent application Ser. No. 10/767,884 entitled “Techniques for Establishing and Managing a Distributed Credential Store;” and at U.S. patent application Ser. No. 10/770,677 entitled “Techniques for Dynamically Establishing and Managing Trust Relationships.” All of these are incorporated herein by reference.

[0014] The identity service discussed herein and below augments these existing identity services with yet more beneficial features that provide an attestation mechanism for content of a sender and, optionally, a verification service for recipients of content. This will be discussed in greater detail below.

[0015] Content is embodied in a message and transmitted over a network from senders to recipients or receivers. The message may be in a variety of formats, such as but not limited to, Multipurpose Internet Mail Extensions (MIME), Secure MIME, (S/MIME), Extensible Markup Language (XML), Standardized Generalization Markup Language (SGML), Really Simple Syndication (RSS), Transmission Control Protocol (TCP), and others.

[0016] A message includes content plus other metadata. Some example enhanced metadata, which is discussed herein and below, is referred to as an Authorship Attestation Certification (AAC). As will be detailed below, an AAC may include a signature of an identity service and a message digest for content of a message. The AAC serves as an attestation as to the authenticity of content sent from a sender and received by a recipient.

[0017] Various embodiments of this invention can be implemented in existing network architectures. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novelle® network and proxy server products, email products, operating system products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.

[0018] Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.

[0019] FIG. 1 is a diagram of a method 100 for verifying content that has been attested to, according to an example embodiment. The method 100 (hereinafter “recipient service”) is implemented in a machine-accessible and readable medium. The recipient service is operational over and processes within a network. The network may be wired, wireless, or a combination of wired and wireless.

[0020] The processing of the recipient service occurs after a piece of content has been attested to by an identity service or by a trusted third-party and the signature of the attestation service is included within a message digest of the content within the message. The recipient service receives the message, and the message includes the content, a signed version of the message digest and perhaps other metadata, as will be discussed below.

[0021] At 110, the recipient service receives content in a message from a sender (author). Before the content is opened for viewing or consumption by a recipient, the recipient service inspects the message to separate and segment the signed version of a message digest from the content.

[0022] Accordingly, at 120, the recipient service acquires the signed version of the message digest for the content from the received message. In an embodiment, the message may also include other metadata that may prove useful to the recipient service. For example, at 121, the recipient service may identify a name of the service provider that signed the message digest. Other information may also be included within the metadata, such as usage limitations with respect to the content of the message. So as an example, if the content is intellectual property, such as an image, music, or a video, then the usage limitations may restrict simultaneous viewing or prevent copying of the content.

[0023] At 130, the recipient service validates the signed version of the message digest for purposes of authenticating the content from the sender. This may be done in a variety of manners using a signature associated with the content and the message digest included with the content.

[0024] For example, at 131, the recipient service may generate its own independent message digest from the included message. If this independent message digest is equal to the included message digest with the message, then the recipient service may at least assume that the content has not been tampered with from how it was originally produced from the sender.

[0025] However, the content may not have originated from the sender that it is purported to be coming from, which may indicate that the content is being feigned. Thus, the recipient service may also verify the signature associated with the message digest. If the signature is associated with a known trusted third party signing or identity service, then the signature and the message digest combine to attest to the authenticity of the content from the sender. If the signature is unknown or encountered for a first time, then the recipient service may enlist the signing service or another trusted identity service to assist in verifying the signature.

[0026] At 140, the recipient service processes one or more policies in response to attempting to validate the signed version of the message digest. Policies may be processed if validation was successful and policies may be processed if validation was unsuccessful. Some example policies that may be processed are now described. It should be noted that virtually any desired processing may be associated with a validated or not validated signed version of a message digest from a sender. Thus, any conceivable and desired policy processing is intended to be included with the embodiments discussed herein.

[0027] According to an embodiment, at 150, the recipient service may assume that the content is authentic and from the purported sender in response to the signature. That is, the signature is associated with a known and trusted identity service of the recipient service and is known to the recipient service. Therefore, the mere presence of the signature from that trusted identity service serves as an attestation that the content is from the purported sender.

[0028] In another embodiment, at 160, policy may dictate that if the signature is from an unknown party to the recipient service, then the recipient service may request the identity service associated with the signature to verify the signature of the message digest. In some cases, the recipient service may request that a different and known identity service act on its behalf in acquiring a verification of the signature. That is, the different identity service may know and interact with the signing identity service, such that if the recipient service request assistance from the different identity service that it trusts, the recipient service can acquire a determination as to whether the signature associated with the message digest is legitimate or not legitimate.

[0029] In some cases, at 170, the recipient service may add the signing entity and its signature, which is acquired from the signed version of the message digest, to a list of trusted and valid signing services, if the recipient service is able to verify the signature. This permits the recipient service to more readily process and authenticate content from senders in the future if these messages include a previously validated signature from a known and trusted signing service.

[0030] In yet other embodiments, at 180, the recipient service may not be able to verify the content and/or the identity of the purported sender. In such a situation, the recipient service may notify the sender or purported sender that the message, which was sent to the recipient service, is being rejected because it cannot be authenticated. If the sender was legitimate, then this may suggest to the sender that a message was feigned on its behalf or that a legitimate message was tampered with by a man-in-the-middle. The sender may then more closely monitor its message transmissions to discover the root problem and may again attempt to send the message, assuming the message was in fact legitimate.

[0031] The policy that is processed may be identified within the recipient service's environment or may be identified for the recipient service via other metadata included with the message digest. Moreover, the recipient process may configure the policies to provide unique processing in response to a particular sender. For example, unique graphics or effects may be used to identify messages that authenticated from a particular sender. These unique graphics and/or effects may be displayed in a header or abbreviate view of the message in a list of unopened messages. As another example, authenticated messages from a particular sender may be routed to a designated mail inbox folder.

[0032] The processing of the recipient service reflects processing of a recipient that receives a message having content. The content includes a signed message digest, which the recipient processes to determine if the content from the sender is authentic or not. Policy may be processed automatically by the recipient service in response to the evaluation of the signed message digest.

[0033] FIG. 2 is a diagram of method 200 for requesting content that is attested to, according to an example embodiment. The method 200 (hereinafter “author service” is implemented in a machine-accessible and readable medium and is operational over a network. The network may be wired, wireless, or a combination of wired and wireless. In an embodiment, the author service provides the message having the content with the signed message digest to the recipient service represented by the method 100 of the FIG. 1.

[0034] Initially, the sender service, which is acting on behalf of a sender of a message, desires to send some content via a message to a recipient. In advance of sending that message, the sender service contacts and interacts with an identity service in the manners discussed below.

[0035] Before contacting the identity service, the sender service generates a message digest from the desired content associated with the message. The message digest is a hash of the content to produce a string or number; the hash can be reproduced by other services executing the same function with the same content. The message digest is used to verify that the content of the message has not been tampered with, but it does not also verify the author of the content or the sender. For this, the identity service is enlisted for assistance.

[0036] Accordingly, at 210, the sender service submits the message digest of the content to an identity service. It is noted, that at 211, the sender service may first authenticate itself to the identity service before the message digest is submitted to the identity service for processing.

[0037] In response to authenticating itself to an identity service and submitting the message digest for content of a desired message, the sender service receives from the identity service an Authorship Attestation Certification (AAC). The AAC is a signed version of the message digest. That is, at 221, the AAC includes a signature of the identity service with the originally submitted message digest.

[0038] According to an embodiment, at 222, the sender service may also receive other metadata with the AAC. For example, the metadata may identify the identity service; this may prove helpful to any recipient of the message if that recipient has not dealt with the identity service before and lacks a valid signature for the identity service. The metadata may also include attributes associated with the sender or may include usage limitations associated with the content of the message. In some cases, the metadata may also include policies or policy identifiers that the recipient is to adhere to when receiving the content.

[0039] At 230, the sender service then sends the AAC and content as a message to one or more desired recipients. At 231, the message may be sent using a variety of protocols, such as but not limited to, MIME, S/MIME, TCP, RSS, etc. Moreover, the format of the message may be in XML, SGML, Hypertext Markup Language (HTML), etc.

[0040] Furthermore, at 240, the sender service may send the message as an email, an IM, or a text message over a network to one or more recipients. So, the message may be received in a variety of message clients using a variety of different network protocols or network transport mechanisms and when the recipient(s) receive(s) the message, the processing discussed above with respect to the recipient service represented by the method 100 of the FIG. 1 is processed for purposes of verifying the signed message digest to attest to the authenticity of the content from the sender.

[0041] While FIG. 1 discusses how an attested piece of content is authenticated or relied upon for authenticity and while FIG. 2 discusses how an author or sender initially constructs a message having information that attest to its content, FIG. 3 discusses the identity service that generates that information (e.g., signed message digest for content of a sender) for a sender and optionally verifies it for a recipient.

[0042] FIG. 3 is a diagram of a method 300 for providing an attestation to content from an author (sender), according to an example embodiment. The method 300 (hereinafter “identity service” is implemented in a machine-accessible and readable medium and is operational over a network. The network may be wired, wireless, or a combination of wired and wireless. In an embodiment, the identity service generates the signed message digest for sender service represented by the method 200 of the FIG. 2 and in some cases validates the signed message digest on behalf of the recipient service represented by the method 100 of the FIG. 1.

[0043] The identity service interacts with senders via a sender service, such as the one depicted above with respect to the method 200 of the FIG. 2, for purposes of attesting to content of messages being sent from the senders to recipients. In some embodiments, the identity service may also interact with receivers via a receiver service, such as the one depicted above with respect to the method 100 of the FIG. 1, for purposes of verifying a signature associated with a signed version of a message digest received with content of a message from a sender.

[0044] At 310, the identity service, receives a message digest for content from a sender. The sender is the author of the content. At 311, the identity service may have previously authenticated the sender before it attempts to generate a signature for the message digest.

[0045] According to an embodiment, the identity service may also generate the message digest on behalf of the sender. In such an embodiment, the content of the desired message that is being sent from the sender to one or more recipients is received by the identity service. Thus, the identity service may be used to generate the message digest from the content in some embodiments.

[0046] At 320, the identity service generates a signature for the message digest. That signature attest to the authenticity of the content and the sender or author associated with the content by the mere fact that the identity service has signed and vouched for its authenticity.

[0047] That is, the identity service is a trusted and reliable third-party known to the sender and knowable to the recipient. So, the identity service may be known in advance by a recipient of the message or may become known via another mechanism to the recipient. Another mechanism may include a situation where the recipient enlists the services of a different identity service, to which it knows and trusts to vouch for the identity service. Once known by the recipient, the identity service and its signature may be relied upon for future messages that include it.

[0048] According to an embodiment, at 321, the signed message digest may also be augmented with other metadata. This other metadata may include, by way of example only, usage limitations, sender attributes, policy identifiers, signature identifiers that identify the identity service, and the like. The other metadata may prove useful to the recipient of the message having the content with the identity service's signed message digest. A variety of examples of how this metadata may prove useful were provided above with respect to the recipient service represented by the method 100 of the FIG. 1. It should be noted that the identity service may receive the entire content from the sender and generate its own message digest that is signed and supplied to the sender.

[0049] At 320, the identity service supplies the signature and message digest (signed version of the message digest) back to the sender. The sender then sends the signed version of the message digest and the content to one or more recipients for consumption. Examples of processing associated with the sender were provided above with respect to the sender service represented by the method 200 of the FIG. 2.

[0050] In an embodiment, the signed message digest may be supplied back to the sender as an assertion in a Security Assertion Markup Language (SAML) format. The assertion may be used by the sender to attest to the authenticity of the content and the sender who sends the content via a message to one or more recipients.

[0051] In some embodiments, at 350, the identity service may subsequently receive the signed message digest from a recipient that acquires the content from a sender having the signed message digest. In response to this, the identity service verifies its own signature on behalf of the recipient.

[0052] In other situations, at 360, the identity service may receive the signed message digest from a different identity service enlisted by the recipient on the recipient's behalf. That different identity service may present the signature to the identity service for verification and the identity service verifies it for that different identity service. The different identity service then notifies the recipient that the signature is authenticated and that the content from the purported sender may be relied upon.

[0053] The identity service is a trusted-third party service that signs and vouches for message digests associated with content of messages being sent from senders. The processing associated with the senders was presented and discussed in detail above with respect to the method 200 of the FIG. 2. The processing associated with the recipients that receive the messages was discussed in detail above with respect to the method 100 of the FIG. 1.

[0054] It is now understood how content may be attested to and authenticated on the bases of that authentication in a manner that is easily implemented. This permits content of messages and the senders of those messages to be authenticated, which may be used for a variety of beneficial purposes, such as but not limited to, detecting spoofed messages, performing special and configured processing on the basis of validated messages from a specific sender, or performing special and configured processing on the basis of non validated messages.

[0055] FIG. 4 is a diagram of a content attestation system 400, according to an example embodiment. The content attestation system 400 is implemented in a machine-accessible and readable medium and is accessed and processed over a network. The network may be wired, wireless, or a combination of wired and wireless. The content attestation system 400 implements, among other things, the identity service represented by the method 300 of the FIG. 3 and interacts with the sender service represented by the method 200 of the FIG. 2 and the recipient service represented by the method 100 of the FIG. 1.

[0056] The content attestation system 400 includes an AAC 401 and an identity service 402. The identity service 402 interacts with a sender service 410 and, optionally, a receiver service 420. Each of these will now be discussed in turn.

[0057] The AAC 401 is a signed version of a message digest for content of a message. The message digest may be submitted by the sender service 410 on behalf of a sender to the identity service 402 or in some cases, the identity service 402 may generate the message digest from content supplied by the sender service 410. The message digest is a hash of the content associated with the message. The signed message digest is a version of the message digest that includes a signature of the identity service 402.

[0058] The AAC 401 accompanies the content of a message when transmitted from a sender service 410 to a receiver service 420. In some embodiments, the AAC 401 may also be augmented with additional metadata, such as but not limited to usage limitations associated with the content, policy identifiers, identifiers associated with identifying the identity service 402, sender attributes, etc.

[0059] According to an embodiment, the AAC 401 may also be represented as an assertion. The assertion may be in a standardized assertion language, such as but not limited to SAML. The assertion accompanies the content of a message and may be relied upon by the recipient service 420 if the recipient service 402 recognizes the identity service 402. The presence of the assertion attests to the authenticity of the content from the sender.

[0060] The identity service 402 interacts with the sender service 410 to generate instances of the AAC's 401 for different content and different messages of the sender service. The identity service 402 also supplies the AAC 401 to the sender service 410 for use with message sending to the recipient service.

[0061] The identity service 402 may also serve as a verifier of its own AAC 401 for a recipient service 420. That is, a recipient service 420 may request that the identity service 402 verify the AAC 401 included with content of a message.

[0062] In some embodiments, the identity service 402 may indirectly serve as a verifier of its own AAC 401 for a trusted and different identity service associated with the recipient service 420. So, the recipient service 420 may use a third-party to contact the identity service 402 to verify the AAC 401.

[0063] The sender service 401 may represent and send the AAC 401 with a message in a variety of manners. For example, the AAC 401 may be represented within tagged information associated with a message sent via MIME, S/MIME, RSS, TCP, etc. Furthermore, the AAC 401 may be in any data format, such as XML, HTML, SGML, etc. Moreover, the message itself may be associated with an email, an IM, a text message, an on-line chat communication, etc.

[0064] It is now understood how content associated with a message may be seamlessly attested to and subsequently authenticated for the content of a particular sender. This streamlined technique presents a practical approach to authenticating content in a highly diverse environment, such as the Internet.

[0065] The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0066] The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0067] In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.