Network security is of critical importance to sending data and communications over the internet. Numerous prior art solutions have been developed to address security issues. Public Key Infrastructure (PKI) key exchange (also called Diffie-Hellman key exchange) was first published publicly in 1976 by Whitfield Diffie and Martin Hellman. It was later discovered that the British signals intelligence agency, Government Communication Headquarters (GCHQ) had invented the practice first, but kept the practice classified. Early prior art solutions include U.S. Pat. Nos. 4,200,770; 4,218,582; 4,405,829; and 4,424,414.
PKI provides three powerful features: first, it enables Person A to generate a public key and a private key, and distribute the public encryption key to Person B in an insecure manner, receive a communication encrypted with the public key from Person B, which may then be decrypted only by Person A's private key. Additionally, Person A can encrypt a message with Person A's private key and transmit it to Person B, who may decrypt the message using Person A's public encryption key. The second scenario is called a ‘digital signature’ and serves to authenticate Person A to Person B, since it is assumed that only Person A has access to Person A's private key. An additional benefit is that encrypted communications cannot be decrypted if the contents of the message are modified, which serves to ensure that a message wasn't modified or otherwise subject to a man-in-the-middle attack during transmission.
Since PKI uses so-called asymmetric keys—a public key and a private key—the concept is challenging for non-technical individuals to understand. PKI is like a door lock that has two keys, one for encrypting (locking) and the other for decrypting (unlocking). Since the decrypting (unlocking) key is intended to remain a secret known to only one person or entity no shared secrets), the number of keys for exchanging encrypted information bi-directionally increases from one key in a scenario using a symmetric key to four keys in a scenario using PKI asymmetric keys. If there are two sets of keys, one set of keys for signing a digital work and another set of keys for encrypting a digital work, the number of keys increases to eight keys for exchanging information bi-directionally between two entities. Conceptually, this is difficult for non-technical individuals to grasp. Operationally, it is difficult to configure and use.
Anyone with access to a PKI key generation system can generate a pair of public and private encryption keys. Thus, sending an encrypted communication is effectively open to anyone. However, without additional security measures PKI can be used to impersonate a person or entity. Digital certificates were developed to validate the identity of a person or entity associated to a key using a mutually trusted authority, called a Certificate Authority (CA). When an encryption key is received within a digital certificate, the receiving computer system can use the attributes of the digital certificate to validate the certificate and encryption key with the trusted CA to ensure the identity of the person or entity associated to the encryption key.
Digital identification (ID) certificates may use PKI technology to sign contractual documents. Technically, a digital signature on a digital document is considered stronger than a physical ink signature on a paper document. The reason for the increased trust is that a digital signature can verify the person signing the digital document, while also ensuring that the digital document hasn't been modified after the signature was applied. Digital signatures may vary in the strength to which they can positively identify a person or entity. A digital ID, such as a Class-1 Digital IDSM from Verisign™ or a Personal Email Certificate from Thawte, matches a digital ID to an email address and preferably includes a person's name. These digital IDs verify the email address, but not the person using the email account unless further measures are taken.
To effectuate a binding contract, a certificate authority should require stronger forms of verifying the identity of a person or entity. Strong forms of identification verification typically require two forms of government issued ID, usually consisting of at least one government-issued photo ID (e.g., a driver's license, a passport, etc.) and another form of government issued ID (e.g., a birth certificate, a Social Security number, etc.). Address verification usually involves a copy of a telephone, cable or utility bill that also contains the name of the person seeking authentication. This stronger form of authentication is more expensive to administer. Web of trust notaries, attorneys, public notaries, bank managers, etc. can verify a person's identity to a certificate authority, provided the certificate authority can also identify the certifying party. These processes can be expensive, time consuming and cumbersome, which discourages people from adopting digital IDs for email and for signing contracts.
Several protocols have been developed to hide the complexity of PKI key exchange from users. The most common use of PKI encryption technology involves the use of the Secure Socket Layer (SSL) protocol or its successor, Transport Layer Security (TLS) as described in U.S. Pat. No. 5,657,390. SSL was developed to address the need for secure communication over Internet Protocol (IP). SSL technology provides several very powerful features: first, it provides a means of negotiating ciphers and hash functions between a client and a server in a ‘socket layer’ that resides above the transport layer (or the transport layer in TLS); second, it provides an exceptionally convenient means of conveying an encryption key for use with a web browser or other client: for example, the user of a browser client merely clicks a Secure Hypertext Transfer Protocol (HTTPS) hyperlink, which returns a hypertext document (e.g., HTML, XML) and facilitates key exchange, whereby the keys are configured for use automatically. SSL technology usually involves digital certificate validation with a certificate authority to reduce the risk of interacting with fraudulent vendors. The combination of convenience, security, and trusted keys is effectively the backbone of global electronic commerce. However, an important reason for the success of SSL/TLS is that it doesn't require the user to learn anything about the underlying technology. Ordinary people use SSL/TLS without any training and typically just marginal awareness that an exchange of encryption keys is taking place.
Secure Shell (SSH) protocol is another easy-to-use protocol that was developed to enable data exchange over a secure channel between two computers. SSH replaced insecure shell protocols like Telnet, which transmitted login and password credentials in clear text. SSH-1 was supplanted by SSH-2, which uses Diffie-Hellman Key Exchange and strong integrity checking to provide a means of thwarting man-in-the middle attacks. While SSH is user friendly, it is principally used by network engineers and system administrators.
One reason for the success of SSL and SSH is that they involve the user of a client application establishing a connection with a server. The server can automatically accept an encryption key/certificate from a client and can automatically provide an encryption key/certificate to a client, where the key/certificate exchange and configuration is completely transparent to the user.
Individuals involved in exchanging sensitive information over electronic networks may utilize numerous technically effective prior art solutions that employ encryption technology for authentication, message integrity and encryption such as Pretty Good Privacy (PGP) and its open standard, Open PGP. However, people have not adopted these solutions en masse largely due to the cumbersome nature of key exchange and key management. Each person must provide an encryption key or certificate to every person they communicate with in order to establish secure communications. Yet, there is no common key exchange method like SSL/TLS or SSH that makes the process seamless or simple enough for ordinary persons.
Diplomats, espionage agencies and others have exchanged encryption keys or ciphers using non-electronic means of exchange for as long as cryptography has existed. However, it is not customary for ordinary individuals without a significant technical background to exchange encryption keys using non-electronic means of exchange. Strong encryption keys are typically lengthy and cryptic, so people do not write them down, print them, or type them into computer systems. This fact makes the non-electronic exchange of strong encryption keys excessively burdensome. Consequently, ordinary people eschew available encryption technologies.
Many prior art solutions assume that people exchange encrypted communications using email exclusively. Prior art encryption key exchange solutions include key servers (e.g., OpenPGP, LDAP, X.500, etc.); however, these key servers have numerous drawbacks: first, while a non-secure public encryption key was historically considered a virtue overcoming the key exchange problem (i.e., Diffie-Hellman), a person disseminating his or her encryption key may not wish to allow any person who wants the public key to receive it. Most key servers allow a person to publish their public key to a key server, but they do not typically restrict access to the key or allow the key owner to approve requests for the key. One significant problem with unrestricted access to a public key used for encryption is that spammers, virus propagators and others can encrypt email using the public key and bypass spam, virus, malware and other filters. U.S. Patent Application No. US 2008 0137859 (Jagadeesan) and U.S. Patent Application No. 2005 0069137 (Landrock) express a need for secure exchange of public keys to prevent man-in-the-middle attacks among other problems. Second, encryption keys exchanged over key servers are often bound to a particular email address, which compounds the problem of people changing their email addresses frequently, or using more than one email address or the same email address with numerous devices (e.g., mobile phones such as RIM Blackberry or Microsoft Outlook for Mobile). Third, keys may be compromised and subsequently revoked by the user. Encryption key servers do not usually make it easy to update people who previously requested the encryption key for the purposes of key rotation. Fourth, some encryption applications search for encryption keys at key servers prior to sending an electronic communication when the application does not have an encryption key for the destination. This means of ‘key discovery’ is intended to help a person build their address book or ‘key ring’ of encryption keys, but it may slow an application down substantially, so users often turn these features off—thwarting the widespread adoption of encryption solutions. Prior art leaves non-technical individuals exposed to the complexities of key exchange and key management, and this exposure reduces the likelihood that people will adopt encryption solutions when transmitting sensitive information over the internet. For a general discussion of network security, refer to Understanding PKI: concepts, standards and deployment considerations, by Carlisle Adams and Steve Lloyd, Addison-Wesley, 2002.
To dramatically increase the use of encryption technology among individuals, key exchange and configuration must become as easy as solutions like SSL/TLS and SSH, so that the user does not have to learn anything about encryption technology. In February 2009, Dr. Joel F. Brenner, the U.S. National Counterintelligence Executive, gave a speech to the 4th Annual Multi-INT Conference and said the following, “And dealing with our workforce's relentless demand for convenience, and its impatience with reasonable security requirements—that's a behavior problem. As you may have noticed, whenever convenience and security butt heads, convenience wins hands down, every time.”
Email is an area with significant security risks. According to the Radicati Group, over 1.2B people worldwide used email in 2007 and this number is expected to grow to 1.6B people by 2011. Leading web properties serve a substantial portion of the world's email users (e.g., in February 2008 Yahoo claimed 254.6M users; Microsoft claimed 256.2M users, Google claimed 91.6M users; and AOL claimed 48.9M users). According to Comscore, 93.4% of internet users in the United States use web-based mail services that usually present email to users within web browsers. Today, people still exchange email primarily in unencrypted form, and the consequences are substantial. Unencrypted and unsigned email leaves people vulnerable to privacy violations, the theft of intellectual property and fraud. Financial institutions, government agencies, utilities, and other public institutions often send email messages without signing them. So recipients cannot verify the identity of the purported sender.
People using email to communicate with others frequently receive unwanted email (called spam). Spam can involve unsolicited marketing offers that overflow a user's inbox and thereby reduce the utility of email. Spam can also be malicious in that it is intended to fool the user as to the identity of the sender and the system from which the email was allegedly sent. Misrepresenting identity can be done for many reasons, but several motivations include: falsely presenting an identity presumed to be trusted by the recipient, so that the recipient will act on the contents of the message such that the recipient becomes the victim of a phishing attack or inadvertently downloads malware; and, misrepresenting the identity of the sender to thwart authorities and other persons from tracking the true sender and the source of the message.
Numerous solutions have been developed to address the problem of identity misrepresentation in the sender address: SMTP-AUTH is an extension to the Simple Mail Transfer Protocol (SMTP) to require the user to login prior to sending an email via an SMTP server so that the true identity of the sender is known. A false header is still possible with SMTP-AUTH unless the server is configured to restrict email addresses and domains the sender is authorized to use.
Sender Policy Framework (SPF), Sender ID and DomainKeys Identified Mail (DKIM) as described in U.S. Pat. No. 6,986,049 to Delany (assigned to Yahoo) verify that an email message came from the domain that appears in the email header; however, it does not verify the sender's identity. One advantage of DomainKeys is that when it is used with Author Domain Signing Practices (ADSP), Mail Transfer Agents (MTA) may be configured to disregard unsigned emails from a domain that purports to send only DomainKeys signed messages. Another advantage is that the decryption key is retrieved ‘out-of-band’ (i.e., the decryption key is not contained within the email message itself). Signed Email for Anti-Phishing (SEFAP) is similar to the approach used in DomainKeys, but it utilizes identity-based encryption (i.e., the public key is the sender's email address) rather than a PKI public key retrieved from a DNS server.
Unfortunately email fraud (often called ‘phishing’) can use SPF and DomainKeys. These technologies do not stop fraudulent email; they stop misrepresentation of the message's originating domain. In SEFAP: An Email System for Anti-Phishing by Qiong Ren, Yi Mu, and Willy Susilo, University of Wollongong 2007 the authors stated, “Most of email-based phishing attacks succeed in large part because they fabricate the origin of email.” Some studies suggest that over half of all spam email is authenticated by these types of technologies. For example, a fraud perpetrator may send an email intended to impersonate a nationally chartered bank, such as ‘BigCitybank’ using a domain such as http://bigcitybank.custserve.com or bigcitybanksupport@bigcitybank.custserve.com where the inclusion of the term ‘bigcitybank’ as a Canonical Name (CNAME) extension to the domain name is sufficient to fool a recipient that it came from BigCitybank. Since many firms outsource services with third party providers, it is not uncommon for a CNAME extension to represent a legitimate business operation. However, SMTP-AUTH, SPF, DomainKeys and SEFAP still cannot not detect that the message is fraudulent before it is transmitted to the recipient. According to the Anti-Phishing Working Group, a leading industry authority, 81% of domains used for phishing are compromised or ‘hacked’ domains. Since DNS hacking has become a significant problem, even publishing a public encryption key on a DNS server for use with DomainKeys involves some risks. In U.S. Pat. No. 6,986,049, Delany acknowledged this risk stating, “Using the DNS could present a security risk because the DNS itself is currently vulnerable.” These security risks also apply to SPF, which is computationally less expensive than DomainKeys (i.e., it verifies the IP address of the sending domain).
Unsigned email is a significant component of identity theft. Major organizations have no generally effective means of knowing which recipients have the ability to decrypt a signed message with a public encryption key (i.e., when the clear text message isn't included) or an encrypted message with a private key, so organizations continue to send unsigned (unauthenticated) and unencrypted (clear text) email. One reason that verifying sender domains is insufficient is that fraud perpetrators are able to copy and utilize the Cascading Style Sheets (CSS) and graphics of major organizations such as banks to impersonate their identity—inducing unsuspecting people who believe they are communicating with a trusted major public institution into providing identity, authentication and other information. Analysts estimate that these email-induced ‘phishing’ scams result in over a billion dollars in losses per year ($3.2B in 2007, $1.7B in 2008 according to Gartner Group) in the US alone. Perpetrators are bold enough to use the style sheets of government agencies such as the IRS and the FBI with impunity.
Fraud perpetrators have recently developed highly sophisticated phishing attacks using email to induce email recipients into navigating to what they think is a trusted site (e.g., an online banking application). These sites emulate the application pages of the target site so that the phishing attack may go undetected. In some embodiments, the phishing attackers emulate every functional page in the site and perform a ‘double dispatch’ by presenting the features of the target site on a phishing web site such that the functionality looks identical in almost every way; then, passes the requests of the user to the actual site—virtually emulating all the functionality (e.g., incorrect password notification). In such cases, the perpetrator may remain logged in or return to the site at a later time, for example, to track financial information of competitors, to write unauthorized checks or send unauthorized bank wires from an online banking site, or to learn about the health conditions of a particular person, among other unauthorized uses of secure information. Phishing attacks have used the foregoing techniques to spoof supposedly secure two-factor authentication solutions employed by business banking sites, which has led to unauthorized bank wires of hundreds of thousands of dollars from both public and private institutions. If email messages were strongly authenticated, this practice could be curtailed significantly.
There remains a long felt but unsolved need to authenticate the source of a communication and to ensure that it was encrypted and not tampered with during transit. A number of impediments to adoption persist: first, most PKI solutions available on the market were developed for desktop email clients (e.g., MS Outlook), but most email users send and receive email using browser-based solutions. Another impediment is that major organizations have a need to defer encryption until content checking modules ensure that personnel within an organization only send authorized data; and, major organizations have a need to decrypt early so that anti-phishing, anti-spam, anti-virus and other modules can operate before distributing the communication to the intended recipient within the organization. While SEFAP teaches modifying SMTP servers and clients to sign and verify respectively, its authors have stated, “Identity-based property removes the unrealistic full PKI infrastructure deployment requirement . . . ” SEFAP's authors demonstrate the long-felt but unsolved need for easier PKI key exchange.
Large organizations have begun to adopt email encryption solutions that hide key generation, key exchange, and key management from end users. Solutions like Voltage and IronPort PXE hide encryption technology, but it can be cumbersome to use (see U.S. Pat. Nos. 6,014,688 and 6,304,897). IronPort PXE requires the recipient of an encrypted communication to sign up with each email sender (or a centralized registry), and the solution sends an email notifying the user that an attached and encrypted sensitive message is pending decryption. The user then must save the encrypted message, open it in a browser (i.e., it is usually encapsulated within HTML), login to the sender's encryption solution (or centralized registry), and download the decryption key to decrypt the message each time they receive an encrypted message. Advantages of this solution include the fact that there is no need to install ‘plug-in’ applications on email client applications (although this approach does download JavaScript and Java applications embedded within the HTML), there is no need to utilize key rings or maintain relationships between users, and the decryption key is retrieved ‘out-of-band’ from a trusted source (i.e., not within the message). Disadvantages of such solutions include the fact that the recipient must save the attachment to a file, use a browser to present the message, must login to retrieve a decryption key for each message, and must develop a means of archiving messages for regulatory compliance (e.g., Sarbanes Oxley, Graham Leach Bliley, HIPAA, etc.) since the message itself will not reside in an ‘inbox’ in unencrypted form, and must be willing to accept email attachments including embedded applications (i.e., some firewalls may block messages for fear of malware). The encryption solution must maintain the encryption keys for substantial time periods too. While the IronPort PXE message itself is probably difficult to spoof (i.e., it contains JavaScript, Java, and an encrypted message attachment; JavaScript builds the client-side representation), it may still be subject to a man-in-the-middle phishing attack, because the notification email is often sent in clear text without signing it.
Some solutions provide secure messaging with an email-like user interface with no transport layer. Messages reside in a centralized database and users login with web browsers using SSL/TLS connections for added security. These solutions send clear text notifications via email when a new message is received. Therefore, these solutions may be vulnerable to phishing schemes too, because they allow a person to send an encrypted message to a secure server for an intended recipient who does not already have a public encryption key. In the case of an invitation, the intended recipient receives an insecure email invitation to sign up with the service in order to retrieve the secure message. The recipient is required to validate the email address prior to receiving any messages. Such solutions are also subject to phishing attacks when sending notifications. For example, a fraud perpetrator may intercept or mimic the contents of a clear text notification message and induce the intended recipient to navigate to a phishing site wherein they may be further induced to provide authentication credentials to the fraud perpetrator.
Secure web-based email firms like HushMail provide a means of exchanging encryption keys with other members of its service. HushMail takes into account the risk of storing a private key on a public server as described in U.S. Pat. No. 6,154,543 to Baltzley (assigned to Hush Communications Anguilla, Inc.). Despite the ease of use for users of HushMail, and the ability to exchange keys with non-HushMail systems (e.g., OpenPGP), slow adoption and the cumbersome nature of exchanging and managing keys with email users outside of the system demonstrates a long-felt, but unsolved need to address key exchange and key management seamlessly for email and other forms of network based communications.
One approach to addressing phishing attacks against major organizations (i.e., usually depository institutions) that induce victims with email involves signing a message with a private key. There are several problems with signing a message: first, the organization may need to know if the intended recipient can decrypt the encrypted message if it does not provide a clear text message too; second, if the recipient doesn't receive the public key out-of-band from a trusted source (e.g., as with IronPort), the user has to verify the authenticity of the key with a certificate authority, because the inclusion of a public key in a message can be replicated easily by a fraud perpetrator. In Request for Comment (RFC) 3709, a document developed by an industry working group for extending digital certificates with logos, industry experts stated, “Many investigations have shown that users of today's applications do not take the steps necessary to view certificates. This could be due to poor user interfaces. Further, many applications are structured to hide certificates from users. The application designers do not want to expose certificates to users at all.” While users are lackadaisical about verifying digital certificates with SSL (probably because cryptic encryption codes are intimidating and difficult to understand), the lack of a general purpose solution for verifying a signed email using a standard web-based email system from a leading vender (e.g., YahooMail, Hotmail, AOL, GMail, Comcast, etc.) leaves the broader market without a means of positively identifying a trusted sender from torrential flood of spam and fraudulent phishing emails that users receive on a regular basis.
Another major problem preventing the widespread adoption of encryption technology with email and other forms of communication is that different types of users have different types of systems. For example, an online banking application may need to send a notification to a customer using a web-based email solution or a desktop-based email solution; and needs to know if the user can receive a signed message; and, further may need a means of receiving a public key from the recipient in order to encrypt the communication if necessary. This asymmetry between large organizations with complex enterprise-class applications and users of web-based email and desktop email solutions creates another seemingly insurmountable obstacle to wide spread adoption of encryption technology with email.
While depository institutions and financial services companies have been the primary target of phishing attacks, firms such as PayPal and eBay and their users have been victimized by phishing schemes in substantially higher volumes. In July of 2009, Google announced that it had added a visual icon (a graphic of a key) to GMail messages in order to indicate that DomainKeys-enhanced email messages received from eBay or PayPal were actually sent from eBay or PayPal (i.e., the “sent from” domain name is @paypal.com or @ebay.com respectively). To prevent so-called ‘false positives,’ a firm like Google must verify the validity of each domain when using a technology like DomainKeys coupled with a confirming visual indicator; and must take additional steps to ensure that any digital certificate verification not only validates the key, but the name of the institution and the domain used, because DNS hacking is a principal means of waging phishing attacks. Iconix provides a browser plug-in that decorates an email message (via the DOM tree) of an inbox when an email header contains Sender ID, SPF, DomainKey or DKIM metadata (see U.S. Pat. Nos. 7,422,115 and 7,487,213 assigned to Iconix). In addition to the shortcomings of this approach to authentication, the Iconix approach requires individuals to install browser plug-ins, which can be inconvenient; using a plug-in to modify or decorate the DOM tree may conflict with solutions that thwart man-in-the-browser attacks by preventing modifications to the DOM tree; the approach involves micropayments, which may impair adoption; and the approach requires retrieving a “stemp” for each message received (i.e., rather than using a public key).
Ad hoc approaches to verifying the identity associated to an email address or domain may be effective in the short run, but they are subject to what economists call the “Law of Diminishing Returns” as each communication provider (e.g., Google and each firm verified by Google) must individually develop such agreements and functionality to ensure that the domain validated by DomainKeys is in fact operated by a legitimate entity. This is another major impediment, since the duplication of effort across enterprises likely precludes medium-sized and smaller firms needing such protection from being able to achieve it with multiple providers at low cost.
Encryption keys can also be broken by brute force methods. Consequently, it is prudent to change or ‘rotate’ keys on a regular basis. Key rotation multiplies the complexity associated with key exchange and key management.
Prior art includes software- and hardware-based solutions for encrypting communications between domains. These solutions typically involve out-of-band asymmetric key exchange and are typically used for point-to-point encryption and decryption with Wide Area Networks (WANs) that use the internet in lieu of a dedicated connection, or for sending secure communications between large organizations. These solutions are effective too; however, they generally do not address the problem of an asymmetry between different organizational sizes. Key exchange and key rotation become expensive when the number of bi-directional relationships and unique encryption keys increases.
An emerging market for email gateways that provide SSL/TLS connections between two devices also helps to secure email (see RFC 2595, RFC 2487). The drawbacks of these SMTPS and STARTTLS solutions include the fact that both the sender and the recipient must have such a device to set up the SSL/TLS connection, which makes it impractical for individuals and small businesses. Additionally, people send email to many different addresses in a serial manner. Consequently, the slow nature of setting up and taking down secure network connections and the finite number of connections supported by the gateway in a high traffic environment is often too slow or limited to make it practical for large organizations.
PGP Corporation has developed a gateway-based email encryption solution that can act as an SMTP or IMAP proxy server. The solution is capable of retrieving keys from LDAP servers and OpenPGP key servers, and it can sign, encrypt, verify and decrypt emails using OpenPGP or S/MIME protocols. It is a significant positive development for large organizations, because it does not require end users to install desktop solutions or learn about email encryption. However, key exchange has some drawbacks: first, in the OpenPGP paradigm, public keys are published to OpenPGP key servers and are exchanged in unencrypted form each time the intended recipient doesn't have a key within the gateway solution. If available, the keys may be retrieved by anyone who requests one without approval. Some people are reluctant to publish public keys using the OpenPGP approach, because it enables email adversaries retrieve the public keys to encrypt spam, viruses, Trojan horses, and other unwanted data. Additionally, an unrestricted means of distributing keys enables an adversary to begin a brute force process to discover the private key if they already know the public key and the contents of an encrypted communication. A gateway service that doesn't enable person-to-person key exchange via a personalized identifier, approval of requests for an encryption key, and secure exchange of keys is a drawback to adoption.
Other economic factors preclude adoption of PKI among major organizations too. Implementing PKI technology with each enterprise application may be economically infeasible. The process of encryption and decryption may be too computationally intensive for legacy applications (i.e., it may materially adversely affect system performance) and may be too expensive to implement (e.g., adding functionality to mainframes, thus requiring the purchase of more expensive mainframe hardware).
The market needs at least the following functionality: a means of identifying persons and entities without them having to provide government-issued IDs manually through trusted third parties; a means of exchanging at least one set of PKI keys between individuals, organizations and/or network devices securely without requiring non-technical individuals to be aware of key generation, exchange, configuration, or management; a means of enabling large organizations with custom enterprise-class applications to exchange encryption keys with individuals and send signed and/or encrypted communications to individuals who use web-based email applications or desktop-based email clients (among other types of applications); a means of presenting a communication recipient with verifying indicia that gives the recipient strong assurance that the message was sent by the purported sender; a transparent method of rotating encryption keys that does not require significant user interaction; and, relatively economical network hardware components to accelerate encryption/decryption such that enterprise applications do not require radical or expensive modifications and do not suffer from significant increases in Computer Processing Unit (CPU) utilization.
USPTO Backgrounds
USPTO Backgrounds