Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2119—Authenticating web pages, e.g. with suspicious links

Definitions

• This invention relates generally to information delivery and management in a computer network. More particularly, the invention relates to techniques for protecting users against computer viruses, phishing and pharming.
• BACKGROUND OF THE INVENTION e-Commerce can be threatened by a phisher who sets up a website, often called a pharm, that might pretend to sell some good or service.
• the pharm induces the browsing visitor to make a purchase, often by entering financial details like a credit card number.
• the pharm might have images of seals from various electronic assurance companies. To persuade the visitor that the site is real. But these seals might be bogus, since images of real seals can be trivially copied on the Web.
• viruses and worms are also serious and continuing problem in computer usage.
• viruses and worms are also “worm”.
• viruses and worms propagate by various means. Often, via email or by a user downloading a file from a website. In both cases, typically there might be comments in the email or on a web page from which the file was downloaded, that claims the attachment or file is benign or that it will do some given task. Whereas, once on the user's computer, it actually does a subversive task.
• a virus is in binary form. Though it might also exist in a higher level format, like ASCII, where perhaps it attempts to be compiled on the user's computer, by some means. Also, viruses exist in every scripting language, like Perl or PHP, where these scripts are written in ASCII. Plus, common proprietary formats like Postscript or PDF (both from Adobe Corp.) are effectively computer languages. Viruses exist in these languages. There have been many attempts to detect viruses. A comprehensive recent description is in "Virus Research and Defense" by Szor (Addison- Wesley 2005). Most of the current methods involve researchers at an anti-virus firm obtaining suspected files, and then doing intensive manual analysis. The results of this analysis are then propagated to customers of the firm, usually in the form of virus "signatures".
• a signature might be a checksum or hash of a known virus. But polymorphic viruses have been written in response. These can change their instantiations, resulting in different checksums or hashes. Which renders a simple hash signature useless.
• the anti-virus firm then has to investigate each polymorphic virus, for some invariant internal structure that can be used as an effective signature. Quite apart from the often difficult manual nature of this investigation, it often has to be repeated for each new type of polymorphic virus that is detected. The problem is ongoing. The above solutions need to be continually found.
• Amy be a phisher.
• the new phishing version involves the phisher targeting a specific company.
• Amy then sends messages to those users. Typically, these messages might claim to be from the company's personnel or IT department. Often, there is a link to an external website run by the phisher. If the unwary user clicks on it, then the user is shown a web page where he is meant to enter various personal data. Sometimes this might just be his company password. Because then the phisher can use this and the user's username, to login and do other attacks. Or, the user might be asked to furnish other types of personal data, that might let Amy impersonate the user in contexts external to the company.
• This type of attack is sometimes called “spear phishing”. Because only a few users are targeted at a time. The low multiplicity of the messages can make it hard for some antiphishing methods to find them.
• Spear phishing also tries to avoid another antiphishing method. This involves user education, where a user is warned not to divulge personal data in response to a message claiming to be from that user's bank or credit card company or similar institutions. But when a user at work gets a message claiming to be from someone else in the same company, often her guard might be lowered.
• the virus instead of having a link to an external domain run by Amy, it has a link back to the virus's computer.
• the virus is also assumed to be able to run a web server. Then, a recipient of a message from the virus has a much harder time discerning its bona fides. Here, the virus is able to take any users' replies and then relay them to a destination outside the company.
• Agg Aggregation Center
• the plug-in can validate the user and the website to each other, making a transaction more likely. And the transaction details can be handled at the Agg, which can act akin to a clearinghouse.
• the website essentially outsources the transaction processing to the Agg. This can also enable a greater usage of micropayments.
• Our Invention has three main sections - using the antiphishing plug-in for e-commerce, using tags against viruses, and enhanced anti-spear phishing and anti-pharming.
• a common, unifying theme is the central role played by an
• Agg Aggregation Center
• the plug-in can also present information to Nu about Jane.
• Nu might expose an Application Programming Interface (API) or Web Service, to be used by the plug-in, if the latter exists on the browser.
• API Application Programming Interface
• Nu might perform some validation procedure with the plug-in and possibly the Agg, such that Nu has confidence that the plug- in is itself valid. This procedure might involve some type of zero knowledge protocol.
• Nu might ask the plug-in for some information about the plug-in, which Nu then sends to Agg for confirmation.
• Nu could assume that Agg, which is located on the network, is a valid authority. Depending on Agg's reply, other steps might be forthcoming.
• the information about Jane that is sent to Nu can be controlled by her in some simple fashion. For example, at an earlier point in time, she might bring up the browser, login to the plug-in and then set this information. The actual information sent to Nu is some combination of this and other information from the plug-in.
• the idea is that the plug-in and Agg offer information to Nu that preserves Jane's privacy, while still furnishing reliable data on her. For example, the plug-in might send some type of credit assessment of Jane. Or some spending limit that it and the Agg can validate, and which Jane is willing to tell another website, in this fashion.
• the Agg stores electronically monetary accounts of several (or many) of its users; specifically including Jane, in our examples. Users can access these accounts by various means. And the Agg might also have interactions with established financial networks, like that used for Electronic Funds Transfer.
• the information about Jane that is passed to Nu should be written in some standard structured form. Possibly in XML. If so, then perhaps in some extension to one or more of the Electronic Commerce Markup Language (ECML), the Web Service Description Language (WSDL) or the Business Process Execution Language (BPEL).
• ECML Electronic Commerce Markup Language
• WSDL Web Service Description Language
• BPEL Business Process Execution Language
• the passing of such structured information from Jane's computer to Nu should not be confused with the functionality of electronic wallets.
• These are programs that reside on a user's computer, and are often little more than convenient form fillers. That is, the user might enter various information about herself, and these are later passed to websites, saving her the manual retyping. But typically, there is little validation of such information. For a website getting information from a wallet, there is usually no increase in the reliability of such information.
• the Agg can also ask each of its corporate customers for a list of its valid push accounts. Typically, these are made public. Since one attack is for a message or pharai that pretends to be from or of Nu to then give a false push account address. To the extent that such addresses can be extracted programmatically from a message or web page, the plug-in can extend its efficacy. This also has merit in helping Nu guard against a subversive attack. Where one of its employees is a phisher, who then changes a web page and gives her own account address, or does likewise in outgoing messages. It assumes that the actual valid push addresses have not been compromised when they were sent to the Agg.
• Another problem is having the website maintain elaborate financial software to handle such micropayments, as well as expecting users to do likewise on their machines.
• the Agg addresses the latter problem, by centralizing this software on itself.
• the plug-in addresses the former problem. It can present numerous options to Jane, that let it pay such transactions, without any manual involvement by her, except perhaps in an exception mode. For example, Jane can set several of these values:
• the validator might also let its customer display the seal in electronic messages sent by the customer, where there messages might be written in some markup language that has hyperlinks (like HTML). So that if the message's recipient views it in a program that can show the markup language, like a browser, then she can also get reassurance from that seal, and click on it for more information.
• some shameless phishers have written seals into their messages and pharms, without any permission from the validators.
• the Agg can have validators as customers, in the specific role of validator, where they give the Agg information which will be described below.
• the Agg can periodically download such validator lists and their associated data to a plug-in, in the same way as it does for regular customers and their Partner Lists and other data ["2245"-, "2458"].
• This new type of customer extends the capabilities of the Agg and plug-in. It is also then a possible extra revenue source for the Agg, inasmuch as the Agg and its plug-ins help protect the value of a validator's seal.
• the invalid() refers to various steps, along the lines of those described in ["2245", "2458"], to be done when a web page or message is invalidated by the plug-in.
• the order of the above tests has no particular meaning. In a given implementation, one might choose a specific order to optimize performance. In part because some of the above tests are unlikely to be often true, but are listed for conceptual completeness.
• the Agg obtains from each of its validators information that includes, but is not limited to, the following: 1. List of customers that have a right to display seal. 2. 2. Can a seal be shown in a customer's website?
• the list of information from a validator assumes that for all of its customers, the items after the first item apply equally. That is, if a validator says that a seal cannot be shown in a customer's message, then it applies for all the validator's customers.
• the pseudocode also assumes this. But clearly, all the items after the first item can be generalized to be functions of a customer. (Vectors instead of scalars.) In this case, there would be the obvious generalizations of the tests in the pseudocode. For example, consider the test that currently states "if ( image not clickable AND B's seal must be clickable )".
• a validator B might have an antiphishing measure that consists of requiring that its seal be loaded from its website.
• B's web server records the network address of whoever is downloading a seal.
• B can then send out spiders, or do manual perusal, of these addresses, to try to detect unauthorized usage. Note that this fails if a phisher sends out messages with a seal, where the seal is loaded from B whenever a reader views such a message. In this case, all B knows is that a message at a given message provider has a seal. In general, B does not have access to the text of that message or the links (if any) in it. Whereas our method applies equally well to both messages and websites.
• the validator Q it is possible for the validator Q to keep a record of the addresses of nodes that go to Q, and of the URLs they present, where these URLs point to locations in Q. But in this case, those nodes are browsers, and unlikely to yield information about any phishing.
• the presented URLs do potentially have more information, under some limited circumstances.
• an URL is valid, as determined by Q. But Q may be unable to tell if the query came from a user at the customer's website or at a pharm imitating the customer, or in a message purporting to be from the customer. But the biggest drawback for Q is simply that the seal is not loaded from its website. Many users do not usually click on a seal. They simply treat its visual presence as sufficient validation.
• a variation on the above is where the phisher uses scripting to generate dynamic addresses for loading images, or for (outgoing) links. She is attempting to conceal where she is loading the seal from, or where it points to. We can use our antispam methods of "1698" to detect her attempts.
• the phisher might try to load a seal from a location not in V, and have it clickable, but not to any domain in V. If the browser is viewing a message with the seal, the latter might be an image which is loaded from an attachment in the message.
• the plug-in might run image recognition algorithms against such loaded messages, to possibly identify close matches against images of its validators' seals. Several heuristics are possible. For example, most seals are fairly small, because they are meant to only take up a fraction of a page or message. The plug-in can have a maximum size found over all its validators' seals. So it can ignore images in a message or page outside those dimensions. An important computational saving. Plus, the images it does look up are then small, and would be quicker to analyze. These remarks also apply if the seal is not clickable.
• a validator might require its customer to insert a special piece of HTML, and possibly scripting code, into the customer's page. So that, if there is a script, then when the page is loaded into a browser, the script might execute (if the user enables scripting), get some information about the browser and the computer, and then show the seal's image. This might involve the script going back to Vs website and downloading the image.
• Amy might also use an image editor to deliberately produce a visually similar, but different, copy of a seal image. Where she starts with an exact copy of the seal image. This has to do with trying to evade an image comparison method. Exact matches of two sets of data are easy to test for. So she can use the editor to introduce variations into her image, that cannot be detected visually. For example, randomly toggling the low intensity bits that code for color. Plus, she might also change the x or y dimensions of the image, as well as other changes inside the image. Our method refers to external image comparison methods. But it can be seen from this that quantifying the difference between two images can be subjective. Hence, while our other steps are deterministic, this comparison is qualitatively different.
• ISP can also use the plug-in methods described above, to search for fake seals in its messages, both incoming and outgoing. Then, if it finds any, it could perhaps reject those messages, or mark them as suspect in some fashion. So that any such incoming messages might go into the recipient's bulk folder, for example. While the detection of fake seals in outgoing messages might cause it to scrutinize the senders. Perhaps to see if they are phishers, or if those accounts might have been hijacked by phishers. (Maybe the rightful owners of the accounts had their passwords discovered by phishers, by some means?)
• An ISP can do more steps to detect fake seals, that a plug-in cannot perform.
• the toughest scenario to detect is where Amy, the phisher, uses an image of a seal that is not loaded from a validator, and which does not link to a validator. But where that image can be construed by a casual observer as a real seal.
• the ISP picks a random set of messages. Or, it might already be making Bulk Message Envelopes (BMEs), as part of the antispam measures of "0046". If it has BMEs, then it can pick randomly, out of the top 20%, say, of the BMEs, where we rank the BMEs by the number of messages in each BME.
• BMEs Bulk Message Envelopes
• Amy is sending forth many messages, then statistically we are likely to have these amongst the chosen messages. And the more messages she sends, the more likely this is true.
• a user on her computer would have a plug-in to her browser. This would detect emails or websites that she is viewing in the browser, and which have the notphish tag. Then, the plug-in could extract any links in the email or web page, and compare these to those in the PL for that company, where the plug-in gets the PL from the Agg. That usage could be applied to any type of electronic message.
• That usage could be applied to any type of electronic message.
• methods to be used against viruses Especially "3878”, where we discussed a method of authenticating electronic messages and arbitrary files. Where the latter (and of course the former) are expected to be disseminated in any fashion across the Internet. Plus, the method of this Invention can be explicitly applied to data written in any binary format, as well as higher formats like ASCII.
• binary format we mean a format of ones and zeros that can be directly executed by a CPU. Or by a simulated CPU, as in the case of Java bytecode, for example.
• the data to be analyzed might be an attachment in an email. Or it might be a file that is already on the user's computer, where the file has arrived on the computer by some means.
• the data is from a company that implements our method.
• At or near the start of the data is a code written in some standard format (like ASCII perhaps). Without loss of generality, assume that ASCII is the chosen format.
• ASCII is the chosen format.
• tags like those in HTML, SGML or XML. This choice is arbitrary, and our method is not confined to this specific choice. But given the widespread use of HTML 5 we suggest that the choice offers a useful familiarity to many.
• the tag has an attribute, shown, above as "a”, that designates the author or owner of the data. Call this the "author attribute”. Its value is some quantity that identifies the author. In the example, we imagine that the author has a website, called author.com.
• Kappa that analyzes data (files) and classifies the data into one of these categories:
• unvalidated Suppose it finds a tag. Then it looks for the author attribute and value. If this is missing, then it might classify the data as "invalid”. This is considered to be worse that unvalidated, because it suggests an actual attempt to mislead the program.
• the data might be classified as
• the blacklist is optional. Entries in it might be put there for various reasons. Some might be spammer domains, for example. Alice might determine what reasons she will use for the blacklist. Here, the blacklist need not be a simple list of domains. Instead, associated with each domain might be a datum that indicates some classification of that domain. So the reasons filter the blacklist. Also, this determination of what reasons to use might be done at a higher level than Alice; by the sysadmin, for instance. Suppose the domain is not on the blacklist. Then Kappa finds a hash ("h") of the data. The choice of hashing function will be some widely used one. Currently an example of this is SHA-I , though others may arise in the future.
• the hash is made of all the data. This is crucial. Because a hash is a very sensitive function of its input bits. In principle, and usually in practice, inverting just one bit in the input will pseudo-randomly flip about half the output bits.
• checksum must not be used in place of a hash.
• Virus writers have discovered that with a commonly used checksum function, the following can be attempted. Take a given file, into which the writer wants to insert a virus. Find the checksum of the file. Then insert the virus and systematically make certain other changes to the file, such that the checksum of the file is the same as the original checksum. While this is not possible for every choice of file and virus, the fact that it works for some choices renders the usage of a checksum very problematic.
• Kappa now sends (author.com, h) to the Agg. It is asking the Agg, is author.com in your list of companies, and if so, is h in author.com's list of valid hashes? If author.com is not in Agg's company list, then it replies "no" to Kappa, who then marks the data as "invalid”. While if author.com is an Agg customer, then it at some earlier time has presumably sent h to the Agg. Along with hashes of any other data that it might be promulgating. If the h sent from Kappa is in this list, then the Agg replies "yes” and Kappa marks the data as "valid”. Otherwise the Agg replies "no" and Kappa marks the data as "invalid".
• a status of "invalid” is worse than "unvalidated", because it appears that someone is trying to fake a tag. More suspicious than merely lacking a tag.
• Kappa finds that the data is invalid, due to its computed hash not being in author.com 1 s official hashes, then it might alert that company or the Agg. Indicating that someone is trying to pass off data as coming from author.com.
• Kappa might offer to upload the invalid data to the company or the Agg, so that they could analyze it. This might be overridden by Alice or by her sysadmin.
• Kappa Because a virus writer might sent up a domain, possibly appearing similar to a "respectable” domain, and then direct Kappa there. Where Kappa will then be told that the data's hash is valid. However, it is possible for Kappa to have a whitelist of domains. So that if author.com is in this list, then instead of Kappa presenting (author.com, h) to the Agg, it presents (h) to the Web Service at author.com.
• Our method is deterministic, when it classifies data as valid or invalid. (When the data lacks a tag, then existing anti-virus methods have to be used on it.) Some anti-virus methods use heuristics (rules of thumb) to try to identify a virus. These are probabilistic classifications.
• An extension of our method is where a company can associate ancillary data with its published hashes. This data might include short descriptions about the file. Like a title and version number, for example.
• the concept of a tag at the start of certain types of data is known.
• the first four bytes of every Java class file has the hexadecimal magic number OxCAFEBABE. It is used by various Java tools as a quick indicator of whether a file is a Java class file or not.
• the start of a Postscript file should have "%!PS-Adobe-1.0". (The 1.0 version could be different in some Postscript files.) In our method, we have a more expressive usage.
• a Web Service accepts data, it can use our method to validate the data. Especially if the Service were perhaps to later install and run the data. That is, the data is treated as a program.
• the main approach taken by the Web Service Description Language and the Business Process Execution Language is to permit the use of digital signing (PKI) of various portions of the XML data that is transmitted between two (or more) Web Services.
• PKI digital signing
• Our method is especially appropriate in the context of Web Services. As discussed earlier, it is meant for programmatic interaction, and the client companies of the Agg run a Service that answers queries about hashes of its published data. And, as above, it is more lightweight (faster) than PKI.
• the program Kappa that we have described above could be implemented in several ways. For example, it might be incorporated into Alice's runtime environment, such that she can only run (or in general access) the data if Kappa validates it. Depending on her user privileges, she might be able to override this constraint or not.
• Kappa has a user interface, it might indicate in some simple way the state of data that it has attempted to validate. For example, it might have a widget that turns green when the data validates, and red when it invalidates. This follows our suggestions in the Antiphishing Provisional for an antiphishing browser plug-in.
• Kappa could be also as a browser plug-in.
• Rho a company
• Rha a company that needs a special program
• Theta might be made by the company (“Phi”) that owns the format.
• Phi is different from Rho.
• One approach to prevent unauthorized changes is for the format to have some type of intricate encoding or encryption. This is used by Theta such that if it detects invalid data (caused presumably by unauthorized changes), then it will not display the data, or do whatever else it might normally do with valid data.
• Rho can be a customer of the Agg, and furnish hashes of its valid data. Phi can write a version of Theta such that whenever Theta encounters a file, it queries the Agg.
• the tag author notation can designate any website. Or, more generally, it could use another type of identifier. (A phone number, for example.)
• Kappa classifying data into one of 3 states
• Kappa or the Agg
• Kappa could contact a Web Service at that site, and presenting the hash of the data.
• Kappa could classify the data as, say, "conditional”. This would be a state less reliable than "valid” but more reliable than "invalid”.
• Kappa (or the Agg) might consult various resources that might have data about someone.com. For example, if an antispam website labels someone.com as a spammer, then this could translate into some value between "valid” and "unvalidated”. Whereas if someone.com is considered to be a phisher, then another, worse value might be chosen.
• our method does not preclude the use of existing antivirus methods. Rather, our method is a way to easily detect valid data from major, reputable companies. It could be used as a pre-filter to the current methods; offering a quick way to reduce the load on those methods. Plus, if users get to expect that most of the new data encountered by them should be validated by our method, then it reduces the chance that they will use data that is not validated. That in itself adds pressure on the virus writers. 2.3 Registrar We now discuss other extensions of "3878". In it, we described the general case of three parties: A sender ("Jane”) and her ISP.
• An Agg which we termed a Registrar, that holds hashes of Jane's outgoing messages, and possibly of some files that she disseminates. And a recipient (“Dinesh”) and his ISR
• ISP ISR
• the Registrar is Jane's message provider. It has the simplifying consequence that Jane does not need a special plug-in to be integrated with her browser. Instead, she can use her browser to go to her provider's website, and there she types and sends a message. Her provider has logic that can then hash her message, or designated subsets thereof. Effectively, the plug-in gets collapsed into the Registrar. Hence, her provider could offer a Web Service that answered queries from external (or internal) recipients like Dinesh.
• Dinesh may still need a plug-in at his browser, in order to compute a hash from Jane's message, and to then submit this and her electronic address, to Jane's provider. Or, perhaps, Dinesh gets his messages at an ISP that can perform these tasks.
• An extension is where the hash is written into the message in some fashion.
• the hash might be written into the header. Or, it might be written as a tag into the body.
• This id might even be independent of the message; and perhaps be chosen randomly. In this case, the id would have to be transmitted with the message, in some format that was made public. Dinesl ⁇ s plug-in (or his ISP's mail client) can use this known format to extract the id. It can then ask her provider (Registrar) if this pair (Jane's address, id) matches an entry in its records. The usage of an id that is independent of the message can lead to spoofing.
• id or hash is written in the outgoing message, along with an expiration time for that id or hash. This might be written in some standard format, like Universal Time. It tells Dinesh's mail reading program that after that time, the Registrar will no longer validate the id or hash. So, for efficiency, if Dinesh reads the message after that time, his software will not attempt to, say, make a hash and ask the Registrar about it.
• a phishing message comes from outside the company or from inside the company.
• a message server at company.com gets a message from an external computer, that purports to be from company.com, then it should not be forwarded to its recipient. It should be discarded, or routed to a sysadmin for scrutiny, in order to detect a possible attack. But perhaps the company does not or will not check for this. It might have a policy of permitting incoming messages to claim to be from company.com. In general, this is undesirable, but suppose this is the situation. Then we effectively have the next case.
• ape.b53.com has the base domain b53.com
• g3.h00.co.uk has the base domain hOO.co.uk.
• Most medium sized or large companies might extend their base domain into subdomains. So imagine that company.com has it.company.com, hr.company.com, sales.company.com and some other domains. It can make several internal PLs, each corresponding to a subdomain. For example, it.company.com could have the PL ⁇ it.company.com, comp 1.com, tech2.com ⁇ , and hr.company.com could have the PL ⁇ hr.company.com ⁇ . The latter means that a valid message from hr.company.com can only have links to that domain (or possibly its subdomains).
• the program that Mark uses to write his message can insert a Notphish tag ["2458"] that has an attribute.
• the recipient's plug-in or the company's mail server) sees this attribute and then finds the hash of the message. It queries the above server, presenting the hash, and asking if a message from hr has that hash. If so, then the message is considered valid. If not, then it is bogus. It did not come from Mark.
• Amy sends a message claiming to be from joe@company.com. It goes to alice@company.com.
• the message text pretends to be a request from Human Resources, and contains links to hr.company.com, for verisimilitude. But it also has a link to a computer that Amy controls. If the link goes outside the company, then our standard use of a PL can detect this and invalidate the message. But suppose that link goes to deskl5.company.com? We apply the concept of the Restricted List (RL) from "2640". Imagine that the company defines its RL to include hr.company.com.
• the plug-in detects that a message has any links to the latter, and links to domains not in the RL (like deskl5.company.com), it might classify the message as "MildWarning", which is not as severe as invalid. Plus, the plug-in might visually indicate in some fashion the latter link.
• “2640” we used the RL primarily for users who receive mail at addresses outside company.com, where the mail purports to be from company.com. It can be seen that here, we are essentially applying the same RL internally.
• Another merit of our method is that it is a means of detecting a company computer that has been subverted by a vims, if that virus releases spear phishing messages that refer back to the computer. If a virus is present, it could also perform other types of attacks on the company. So having an extra means of detecting it is useful.
• Our method considered as a virus detection technique, is entirely separate from, and complements, conventional antivirus methods. (Cf.
• the browser plug-in that we described here and in the Antiphishing Provisionals can also have its functionality extended to combat a type of browser hijacking.
• the latter can arise if the user gets a message with an attachment that ends up being run. Or possibly if a virus gets installed on the user's machine by whatever means.
• the attachment or virus waits till the user completes her login at a bank's website. (It might also have key logging ability that records her keystrokes.)
• the attachment has an internal record of various banks (or similar institutions), as well as information about how to recognize a successful login. Once the latter happens, the virus makes the browser session invisible and makes another window that the user uses. From the phisher's viewpoint, this circumvents any login mechanism like a hardware two factor. The virus is then able to empty the account.
• the plug-in can implement several methods. It could indicate (warn) the user whenever a session is being made invisible. Or it could prevent such an action. (To be able to do this depends on the given browser.) More specifically, the plug-in might do this only when the user is at a domain in the plug-in's set of domains.
• BanlcO with a (real) website, bankO.com.
• Amy sets up a fake website that imitates bankO.com.
• She then does various techniques to drive clients of BanlcO to her website, and once there, to enter in their personal data. So that she can drain their accounts or use that data to set up fake identities.
• Wikipedia defines it as "the exploitation of a vulnerability in DNS server software that allows a cracker to acquire the domain name for a site, and to redirect, for instance, that web site's traffic to another web site.” (Cf. en.wikipedia.org/wiki/Pharming.)
• Our meaning includes this, but we also include the more general case where, by whatever technical means, a phisher has set up a website (“pharm”) that pretends to be another website.
• the MITM attacks might be mostly directed toward mobile computing.
• Jane has a laptop, PDA, mobile phone or some other device capable of browsing the network.
• the network is the Internet.
• Jane takes her mobile device to a hot spot, like a cybercafe or a hotel, say, and then logs in to the network.
• Her connection could be wireless or wired.
• Amy might have perhaps done DNS poisoning of the hot spot machine that connects Jane to the network. This poisoning might map "bankO.com" away from the real Theta address to Amy's Rho.
• K secret key
• Jane's machine might have a browser plug-in, say, that has, at that earlier time while she was connected to the network in a more secure context, recorded the mapping from bankO.com to Theta. Hence, a simple check by the plug-in of Theta against the Rho will reveal a difference and thus alert Jane to the fake website.
• her plug-in computes the following hash - h(K+Phi).
• h() designates a common hash function.
• the plug-in can find Phi and it already knows K.
• Phi is assigned to Jane's machine via some method like DHCP.
• h(K+Phi) is passed to what is actually Amy.
• BankO makes a login page, in which Jane or her plug-in has typed her usemame in the appropriate box.
• Kappa cannot be usefully concealed from BankO. It is the sender address in the packets that go from Kappa to BankO. Granted, Amy can change that sender field to anything she wants. If it is changed to another machine which she runs, then this is effectively the same as leaving it unchanged as Kappa. Suppose she changes the field to that of a machine she does not run. Then she does not get any reply sent by BankO, and her MITM attack fails. Above, we used the notation "K+Phi". Here the plus sign means some function of two variables, K and Phi. It does not necessarily mean arithmetic addition or the appending of the bits representing Phi to those representing K. Though it could.
• the method is very simple to implement. And the hashing is faster than a PKI cryptographic approach. Plus, unlike a two factor hardware device, it does not need an accurate hardware clock in order to generate one time passwords.
• a variant on the above is that Jane or BankO might not want her to reveal even her regular usemame, on the principle of denying as much information as possible to an attacker. Instead, just as they established a common key at an earlier time, they might also have established a temporary username, for her to use when traveling.
• Another variant is that at that earlier time, they might have established several keys or several temporary usernames.
• Amy For Amy, one thing she might then try to do is write malware that can control the assigning of a network address to Jane. This is more involved, and this extra intricacy in itself acts to protect Jane, because it makes it more unlikely that a phisher could accomplish this step. But suppose somehow Amy is able to do this. So that in the full network, she picks a Kappa from which she will contact BankO, pretending to be a Jane customer. And in the hot spot subnet, Amy hands out a "Kappa" address to be Jane's Phi.
• T be a string or bit sequence to be sent from BankO to Jane.
• BankO can send the doublet (T, h(T+K)) 5 for example.
• Amy reads T as plain text. But if she changes either item in the doublet or both items, then Jane can detect this. Because when Jane's plug-in gets the doublet, it takes the first argument, T, and independently computes h(T+K). If this is not the same as the second argument, then the message from BankO was tampered with. And she does not proceed further. So assume that Jane finds the message is untampered.
• Her plug-in combines T with K in some manner to find the key for encrypting a (new) channel between her and BankO. Where this manner of combining is also performed by BankO. As above, the programmers of the plug-in and BankO ensure that they are using the same method to get a key, and, of course, the same subsequent encryption method that uses the key. In the above, when we said that BankO sends a doublet to Jane, the reverse might happen. Their abilities are symmetric, in this respect.
• K which might conventionally be Jane's password.
• Jane and BankO might have earlier predefined a separate password to be used in. this context.
• a variant of the channel encryption method involves a different choice of K.
• Y(t) where Y is a function of the time, t.
• Y is a function of the time, t.
• Jane and BankO have separate implementations of a stable clock, that were synchronized at some earlier time. And that the drift in the clocks over the duration that they will be used is small enough that both parties will generate the same Y(t). More generally, Y might be a function of both K and t.
• Another situation is where Jane is a person, but instead of her carrying a mobile computer around, she might instead carry a fob that can plug in to a computer at a cybercafe or library.
• the fob might have what we have referred to above as a plug-in to a browser.
• our channel encryption method can be used in a situation where two parties have a shared secret and wish to defend against a MITM attack.
• the offset corresponds to the T in the doublet (T, h(T+K)) used above.
• T the doublet
• h(T+K) the communication between the ISPs could be in plain text, because an evesdropper gains very little useful information, if any. And to the extent that she finds information, there is little direct financial advantage to be gained from it, if any. So in "0046", a MITM attack has minor significance.
• ISPs may be reasonably expected to have the personnel and resources to guard against such malware attacks as DNS poisoning. And ISPs are often closer to the network backbone, which is more heavily defended against attacks than a hot spot on the peripheiy of the network.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Computing Systems (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Virology (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (8)

Publications (1)

Family

ID=37727661

Family Applications (1)

Country Status (1)

Cited By (4)

• 2006
  • 2006-08-07 WO PCT/CN2006/001987 patent/WO2007016869A2/fr active Application Filing

Similar Documents

Legal Events