The books that help you most are those which make you think the most. The hardest way of learning is that of easy reading; but a great book that comes from a great thinker is a ship of thought, deep freighted with truth and beauty. - Theodore Parker
When I picture a perfect reader, I always picture a monster of courage and curiosity, also something supple, cunning, cautious, a born adventurer and discoverer. - Friedreich NietzscheThis is not intended to be an introductory text, although a beginner could gain something from it. The reason behind this is that beginners think in terms of tactics, rather than strategy, and of details rather than generalities. There are many fine books on computer and network security tactics (and many more not-so-fine books), and tactics change quickly, and being unpaid for this work, I am a lazy author. The reason why even a beginner may gain from it is that I have attempted to extract abstract concepts and strategies which are not necessarily tied to computer security. And I have attempted to illustrate the points with interesting and entertaining examples and would love to have more, so if you can think of an example for one of my points, please send it to me! I'm writing this for you, noble reader, so your comments are very welcome; you will be helping me make this better for every future reader. If you send a contribution or comment, you'll save me a lot of work if you tell me whether you wish to be mentioned in the credits (see 39) or not; I want to respect the privacy of anonymous contributors. If you're concerned that would be presumptuous, don't be; I consider it considerate of you to save me an email exchange. Security bloggers will find plenty of fodder by looking for new URLs added to this page, and I encourage you to do it, since I simply don't have time to comment on everything I link to. If you link to this paper from your blog entry, all the better.
There is no security on this earth, there is only opportunity. - General Douglas MacArthur (1880-1964)These are important concepts which appear to apply across multiple security domains.
As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert EinsteinStop for a moment and think about the difficulty of trying to list all the undesirable things that your computer shouldn't do. If you find yourself finished, then ask yourself; did you include that it shouldn't attack other computers? Did you include that it shouldn't transfer $1000 to a mafia-run web site when you really intended to transfer $100 to your mother? Did you include that it shouldn't send spam to your address book? The list goes on and on. Thus, if we had a complete list of everything that was bad, we'd block it and never have to worry about it again. However, often we either don't know, or the set is infinite. In some cases, it may be possible to define a list of good things (see 34.1); for example, the list of programs you might need to use in your job may be small, and so they could be enumerated. However, it is easy to imagine where whitelisting would be impossible; for example, it would be impractical to enumerate all the possible "good" network packets, because there's just so many of them. It is probably true that computer security is interesting because it is open-ended; we simply don't know ahead of time whether something is good or bad.
A vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. The term vulnerability is often used very loosely. However, here we need to distinguish threats, attacks, and countermeasures. - OWASP Vulnerabilities Category (http://www.owasp.org/index.php/Category:Vulnerability)Vulnerabilities can be divided roughly into two categories, implementation bugs and design flaws. Gary McGraw (http://www.cigital.com/~gem/), the host of the Silver Bullet Security Podcast (http://www.cigital.com/silverbullet/), reports that the vulnerabilities he finds are split into these two categories roughly evenly.
NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics. - NVD Home Page
International in scope and free for public use, CVE is a dictionary of publicly known information security vulnerabilities and exposures. CVE’s common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and services. - CVE Home Page
The Common Weakness Enumeration Specification (CWE) provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. Each individual CWE represents a single vulnerability type. CWE is currently maintained by the MITRE Corporation with support from the National Cyber Security Division (DHS). A detailed CWE list is currently available at the MITRE website; this list provides a detailed definition for each individual CWE. - CWE Home Page
OSVDB is an independent and open source database created by and for the community. Our goal is to provide accurate, detailed, current, and unbiased technical information. - OSVDB Home Page
On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles BabbageThis is sometimes called the GIGO rule (Garbage In, Garbage Out). Stated this way, this seems self-evident. However, you should realize that this applies to systems as well as programs. For example, if your system depends on DNS to locate a host, then the correctness of your system's operation depends on DNS. Whether or not this is exploitable (beyond a simple denial of service) depends a great deal on the details of the procedures. This is a parallel to the question of whether it is possible to exploit a program via an unsantitized input. You can never be more accurate than the data you used for your input. Try to be neither precisely inaccurate, nor imprecisely accurate. Learn to use footnotes.
Egghead was hurt by a December 2000 revelation that hackers had accessed its systems and potentially compromised customer credit card data. The company filed for bankruptcy in August 2001. After a deal to sell the company to Fry's Electronics for $10 million fell through, its assets were acquired by Amazon.com for $6.1 million. ... In December 2000, the company's IIS-based servers were compromised, potentially releasing credit card data of over 3.6 million people. In addition to poor timing near the Christmas season, the handling of the breach by publicly denying that there was a problem, then notifying Visa, who in turn notified banks, who notified consumers, caused the breach to escalate into a full blown scandal. - Wikipedia
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. - Sun Tzu, The Art of War (http://en.wikipedia.org/wiki/The_Art_of_War)After deciding what you need to protect (your assets), you need to know about the threats you wish to protect it against, or the adversaries (sometimes called threat agents) which may threaten it. Generally intelligence units have threat shops, where they monitor and keep track of the people who may threaten their operations. This is natural, since it is easier to get an idea of who will try and do something than how some unspecified person may try to do it, and can help by hardening systems in enemy territory more than those in safer areas, leading to more efficient use of resources. I shall call this adversary modeling. In adversary modeling, the implicit assumptions are that you have a limited budget and the number of threats is so large that you cannot defend against all of them. So you now need to decide where to allocate your resources. Part of this involves trying to figure out who your adversaries are and what their capabilities and intentions are, and thus how much to worry about particular domains of knowledge or technology. You don't have to know their name, location and social security number; it can be as simple as "some high school student on the Internet somewhere who doesn't like us", "a disgruntled employee" (as opposed to a gruntled employee), or "some sexually frustrated script-kiddie on IRC who doesn't like the fact that he is a jerk who enjoys abusing people and therefore his only friends are other dysfunctional jerks like him". People in charge of doing attacker-centric threat modeling must understand their adversaries and be willing to take chances by allocating resources against an adversary which hasn't actually attacked them yet, or else they will always be defending against yesterday's adversary, and get caught flat-footed by a new one.
If they were capable, honest, and hard-working, they wouldn't need to steal.Along similar lines, one can assume a monotonically decreasing number of adversaries with a certain level of sophistication. My rule of thumb is that for every person who knows how to perform a technique, there are x people who know about it, where x is a small number, perhaps 3 to 10. The same rule applies to people with the ability to write an exploit versus those able to download and use it (the so-called script kiddies). Once an exploit is coded into a worm, the chance of a compromised host having been compromised by the worm (instead of a human who targets it specifically) approaches 100%.
Men of sense often learn from their enemies. It is from their foes, not their friends, that cities learn the lesson of building high walls and ships of war. - AristophanesIn technology, people tend to focus on how rather than who, which seems to work better when anyone can potentially attack any system (like with publicly-facing systems on the Internet) and when protection mechanisms have low or no incremental cost (like with free and open-source software). I shall call modeling these threat modeling (http://en.wikipedia.org/wiki/Threat_model).
CPE is a structured naming scheme for information technology systems, software, and packages. Based upon the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name. - CPE Home PageThe first part of threat modelling should be, what is it I want to protect? And once you start to compile a list of things you wish to protect, you might want a consistent naming system for your computer assets. The CPE may help you here.
Gnothi Seauton ("Know Thyself") - ancient Greek aphorism (http://en.wikipedia.org/wiki/Know_thyself)When discussing security, it's often useful to analyze the part which may interact with a particular adversary (or set of adversaries). For example, let's assume you are only worried about remote adversaries. If your system or network is only connected to outside world via the Internet, then the attack surface is the parts of your system that interact with things on the Internet, or the parts of your system which accept input from the Internet. A firewall, then, limits the attack surface to a smaller portion of your systems by filtering some of your network traffic. Often, the firewall blocks all incoming connections. Sometimes the attack surface is pervasive. For example, if you have a network-enabled embedded device like a web cam on your network that has a vulnerability in its networking stack, then anything which can send it packets may be able to exploit it. Since you probably can't fix the software in it, you must then use a firewall to attempt to limit what can trigger the bug. Similarly, there was a bug in sendmail that could be exploited by sending a carefully-crafted email through a vulnerable server. The interesting bit here is that it might be an internal server that wasn't exposed to the Internet; the exploit was data-directed and so could be passed through your infrastructure until it hit a vulnerable implementation. That's why I consistently use one implementation (not sendmail) throughout my network now. If plugging a USB drive into your system causes it to automatically run things like a standard Microsoft Windows XP installation, then any plugged-in device is part of the attack surface (http://it.slashdot.org/article.pl?sid=08/01/13/1533243). But even if it does not, then by plugging a USB device in you could potentially overflow the code which handles the USB or the driver for the particular device which is loaded (http://www.eweek.com/article2/0,1895,1840141,00.asp, http://www.schneier.com/blog/archives/2006/06/hacking_compute.html); thus, the USB networking code and all drivers are part of the attack surface if you can control what is plugged into the system. Moreover, a recent vulnerability (http://it.slashdot.org/it/08/01/14/1319256.shtml) illustrates that when you have something which inspects network traffic, such as uPNP devices or port knocking daemons, then their code forms part of the attack surface. Sometimes you will hear people talk about the anonymous attack surface; this is the attack surface available to everyone (on the Internet). Since this number of people is so large, and you usually can't identify them or punish them, you want to be really sure that the anonymous attack surface is limited and doesn't have any so-called "pre-auth" vulnerabilities, because those can be exploited prior to identification and authentication.
Amdahl's law, also known as Amdahl's argument, is named after computer architect Gene Amdahl, and is used to find the maximum expected improvement to an overall system when only part of the system is improved. - Wikipedia (http://en.wikipedia.org/wiki/Amdahl%27s_law)Let us think of our security posture for whatever we're protecting as being composed of a number of systems (or groups of systems possibly offering defense-in-depth). The strength of these systems to attack may vary. You may wish to pour all your resources into one, but the security will likely be broken at the weakest point, either by chance or by an intelligent adversary. This is an analogy to Amdahl's law, stated above, in that we can only increase our overall security posture by maintaining a delicate balance between the different defenses to attack vectors. Most of the time, your resources are best spent on the weakest area, which for some institutions (financial, military) is usually personnel. The reasons you might not balance all security systems may include:
The NX bit, which stands for No eXecute, is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (or code) or for storage of data, a feature normally only found in Harvard architecture processors. However, the NX bit is being increasingly used in conventional von Neumann architecture processors, for security reasons. An operating system with support for the NX bit may mark certain areas of memory as non-executable. The processor will then refuse to execute any code residing in these areas of memory. The general technique, known as executable space protection, is used to prevent certain types of malicious software from taking over computers by inserting their code into another program's data storage area and running their own code from within this section; this is known as a buffer overflow attack. - Wikipedia
All cryptography lets you do is create trust relationships across untrustworthy media; the problem is still trust between endpoints and transitive trust. - Marcus RanumPut simply, you can't have a secure distributed system (with the normal assumptions of untrusted nodes and network links potentially controlled by the adversary) without using cryptography somewhere ("sine qua non" is Latin for "without which it could not be"). If the adversary can read communications, then to protect the confidentiality of the network traffic, it must be encrypted. If the adversary can modify network communication, then it must have its integrity protected and be authenticated (that is, to have the source identified). Even physical layer communication security technologies, like the KLJN cipher, quantum cryptography, and spread-spectrum communication, use cryptography in one way or another. I would go farther and say that performing network security decisions on anything other than cryptographic keys is never going to be as strong as if it depended on cryptography. Very few Internet adversaries currently have the capability to arbitrarily route data around. Most cannot jump between VLANs on a tagged port. Some don't even have the capability to sniff on their LAN. But none of the mechanisms preventing this are stronger than strong cryptography, and often they are much weaker, possibly only security through obscurity. Let me put it to you this way; to support a general argument otherwise, think about how much assurance a firewall has that a packet claiming to be from a given IP address is actually from the system the firewall maintainer believes it to be. Often these things are complex, and way beyond his control. However, it would be totally reasonable to filter on IP address first, and only then allow a cryptographic check; this makes it resistant to resource consumption attacks from anyone who cannot spoof a legitimate IP address (see 4.1.1).
Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. (They are also large, expensive to maintain, difficult to manage, and they pollute the environment. It is astonishing that these devices continue to be manufactured and deployed. But they are sufficiently pervasive that we must design our protocols around their limitations). - Network Security / PRIVATE Communication in a PUBLIC World by Charlie Kaufman, Radia Perlman, & Mike Speciner (Prentice Hall 2002; p.237)Because humans communicate in slowly, in plaintext, and don't plug into a network, we consider the nodes within the network to be computing devices. The system a person interacts with has equivalency with them; break into the system administrator's console, and you have access to anything he or she accesses. In some cases, you may have access to anything he or she can access. You may think that the your LDAP or Kerberos server is the most important, but isn't the node of the guy who administers it just as critical? This is especially true if OS security is weak and any user can control the system, or if the administrator is not trusted, but it is also convenient because packets do not have user names, just source IPs. When some remote system connects to a server, unless both are under the control of the same entity, the server has no reason to trust the remote system's claim about who is using it, nor does it have any reason to treat one user on the remote system different than any other.
Sometimes I suspect I'm not who I think I am. - Ghost in the ShellAn identity, for our purposes, is an abstract concept; it does not map to a person, it maps to a persona. Some people call this a digital ID, but since this paper doesn't talk about non-digital identities, I'm dropping the qualifier. Identities are different from authenticators, which are something you use to prove your identity. An identifier is shorthand, a handle; like a pointer to the full identity. To make this concrete, let us take the Unix operating system as an example. Your identity corresponds to a row in the /etc/passwd file. Your identifier is your username, which is used to look up your identity, and your password is an authenticator.
In cyberspace everyone will be anonymous for 15 minutes. - Graham GreenleafWhat can we learn from anonymizer, mixmaster, tor, and so on? Often one can de-anonymize. Some people have de-anonymized search queries this way, and census data, and many more data sets that are supposed to be anonymous.
Does it follow that I reject all authority? Far from me such a thought. In the matter of boots, I refer to the authority of the bootmaker; concerning houses, canals, or railroads, I consult that of the architect or the engineer. - Mikhail Bakunin, What is Authority? 1882 (http://www.panarchy.org/bakunin/authority.1871.html)When we are attempting to identify someone, we are relying upon some authority, usually the state government. When you register a domain name with a registrar, they record your personal information in the WHOIS database; this is the system of record (http://en.wikipedia.org/wiki/System_of_record). No matter how careful we are, we can never have a higher level of assurance than this authority has. If the government gave that person a false identity, or the person bribed a DMV clerk to do so, we can do absolutely nothing about it. This is an important implication of the limitations of accuracy (see 4.6).
My voice is my passport; verify me. - Sneakers, the motion pictureThe oldest and still most common method for authenticating individuals consists of using passwords. However, there are many problems with using passwords, and I humbly suggest that people start to design systems with the goal of minimizing the use of passwords, passphrases, and other reusable authenticators.
| 1 | 2 | 3 | 4 | |
| DA | D | O | X | O |
| AD | D | O | X | X |
| MF | D | O | X | X |
Doveriai, no proveriai ("trust, but verify") - Russian Proverb (http://en.wikipedia.org/wiki/Trust,_but_Verify)It is becoming apparent that there's more to computers than shell access nowadays. One wants to allow benign email, and stop unsolicited bulk email. For wikis and blogs, one wants to allow collaboration, but doesn't want "comment spam". Some still want to read topical USENET messages, and not read spam (I feel that's a lost cause now). If you're an ISP, you want to allow customers to do some things but don't want them spamming or hacking. If you have a public wifi hot-spot, you'd like people to use it but not abuse it. So I generalized IDS, anti-virus, and anti-spam as abuse detection.
Tart words make no friends; a spoonful of honey will catch more flies than a gallon of vinegar. - Benjamin FranklinNoted security expert Marcus Ranum gave a talk on burglar alarms once at Usenix Security, and had a lesson that applies to computer security. He said that when a customer of theirs had an alarm sensor that was disguised as a jewelry container or a gun cabinet, it was almost always sure to trick the burglar, and trigger the alarm. Criminals, by and large, are opportunistic, and when something valuable is offered to them, they rarely look a gift horse in the mouth. I also recall a sting operation where a law enforcement agency had a list of criminals they wanted to locate but who never seemed to be home. They sent winning sweepstakes tickets to wanted criminals who dutifully showed up to claim their "prize". So a honey trap may well be the cheapest and most effective misuse detection mechanism you can employ. One of the ways to detect spam is to have an email address which should never receive any email; if any email is received, then it is from a spammer. These are called spamtraps. Unix systems may have user accounts which may have guessable passwords and no actual owners, so they should never have any legitimate logins. I've also heard of banks which have trap accounts; these tend to be large accounts which should never have a legitimate transaction; they exist on paper only. Any transaction on such an account is, by definition, fraudulent and a sign of a compromised system. One could even go farther and define a profile of transactions, possibly pseudo-random, any deviation from which is considered very important to investigate. The advantage of these types of traps are the extremely low false-positive rate, and as a deterrent to potential adversaries who fear being caught and punished. Similarly, databases may have honey tokens, or a row of some unique data that shouldn't normally be pulled out of the database system.
We, the humans, are clumsy. The script seeks for SUPR and BACKSPACE characters in the executed commands. The script also checks if the intruder tried to change the window size or tried to forward X11 requests.
That's it man, game over man, game over! - Aliens, the motion pictureOne important thing is that you really can't defend against an intruder with full privileges. First discussed in Ken Thompson's 1984 classic, Reflections on Trusting Trust (http://cm.bell-labs.com/who/ken/trust.html), these stealthy backdoors became known as rootkits, which were installed on a compromised system (requiring root privileges) and hid the existence of various things which would give away the adversary's presence. These evolved from simple log cleaners to trojan system programs, and have now burrowed deeper into the system as LKMs (loadable kernel modules). I have heard rumors of some which reside in flash memory on graphics cards, and run on the GPU (which has DMA, direct memory access), completely bypassing the main CPU. Notice I say "full privileges" instead of "administrator rights" or "root access", because various people are experimenting with limiting these levels of access in various ways (including BSD securelevel, MAC, and tamper-proof hardware like the TPM). Some HIDS (host-based intrusion detection) systems that detect corruption, like tripwire, compare cryptographic hashes (checksums, or more generally "fingerprints") against saved values to detect modification of system files. However, this strategy has a number of limitations:
Who knows what evil lurks in the hearts of men? The Shadow knows! - The Shadow radio drama (http://en.wikipedia.org/wiki/The_Shadow)Counterhacking is using hacking techniques against hackers. It is possible to exploit vulnerabilities in malware and exploit code (http://blog.wired.com/27bstroke6/2008/04/researcher-demo.html). In fact, many PoC exploits are written in C and have buffer overflows in them, and it would be relatively trivial to exploit the exploit. One can imagine systems that listen for network attacks generated by vulnerable exploit code and automatically respond in kind, which despite usually being illegal, has a certain symmetry and poetic justice to it. Do such systems exist? Only the shadow knows.
Absence of evidence is not evidence of absence. - Scientific Adage (http://en.wikipedia.org/wiki/Argument_from_ignorance)Forensics has limits. For example, it's not uncommon when dealing with skilled intruders to find that they've symlinked a shell history file to /dev/null, or that the last line of a log file is something like rm /var/log/sudo or bash -i. It is even possible that a very skilled and disciplined adversary would leave the system in a state that the forensics indicate one thing, but is disinformation; I've never heard of anything that subtle in practice, but then again, what are the chances I would? When you're compromised, you don't know when it originally happened, and so backups are of little use; one can't be sure if the backups contain back doors. Thus, it seems like the only way to be sure of extermination is to wipe the state of any machines that might be compromised or corrupted, and start from scratch. However, before doing so, you should do your best to make a full backup of the compromised system for forensic analysis. You'd like to identify any possible intrusion vectors and make sure the new system doesn't have the same vulnerabilities, lest the situation repeat itself.
"You have zero privacy anyway. Get over it." - Scott McNealy, CEO of Sun Microsystems, 21 Jan 1999
I say we take off and nuke the entire site from orbit. It's the only way to be sure. - Aliens, the motion picture
Spamming is the abuse of electronic messaging systems to indiscriminately send unsolicited bulk messages. While the most widely recognized form of spam is e-mail spam, the term is applied to similar abuses in other media: instant messaging spam, Usenet newsgroup spam, Web search engine spam, spam in blogs, wiki spam, mobile phone messaging spam, Internet forum spam and junk fax transmissions. - Wikipedia (http://en.wikipedia.org/wiki/Spam_) Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. - Zawinski's Law (http://www.catb.org/jargon/html/Z/Zawinskis-Law.html)
In computing, phishing is the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. Communications purporting to be from PayPal, eBay, Youtube or online banks are commonly used to lure the unsuspecting. Phishing is typically carried out by e-mail or instant messaging, and it often directs users to enter details at a website. - Wikipedia (http://en.wikipedia.org/wiki/Phishing)
We just certified our x.509 SSL certs with the Department of Redundancy Department's CA certificate.When you pay a Certification Authority3 a large sum of money to certify you (and issue a certificate as a by-product of that certification process), they check your information against the system of record to make sure you are the person who owns the domain. Therefore, unless they check something else, they can never give higher assurance than the registrar, which makes you wonder why they even exist; you could just get a certificate from the registrar, and that would, in theory, give us more security. As Lynn Wheeler puts it, these are basically offline checks, derived from letters of credit (http://en.wikipedia.org/wiki/Letters_of_credit) in the sailing ship days. They are significantly less secure than an online system. To allow for revocation, all clients must check them against a certificate revocation list (CRL). To allow for instant revocation, you have to be online with the source of the CRL. Of course, if you're already doing that, why use certificates at all? Just ask the person who would have issued the certificate for the appropriate public key (see 11.6).
| W |
Ä | X |
PaX flags data memory as non-executable, program memory as non-writable and randomly arranges the program memory. This effectively prevents many security exploits, such as some kinds of buffer overflows. The former prevents direct code execution absolutely, while the latter makes so-called return-to-libc (ret2libc) attacks difficult to exploit, relying on luck to succeed, but doesn't prevent variables and pointers overwriting. - Wikipedia
Men are disturbed not by things, but by the views they take of things. - Epictetus
In my view, to have real trust, there must be consequences for betrayal. The extent of the consequences defines the extent of trust. - Terry Ritter (personal correspondence)Terry and I disagree on our definition of the word "trust", but there is some truth in what he says. A trusted person is one upon whom our security depends. A trusted part of a system is one which must operate properly to ensure the security of the system. A trustworthy person will look out for your interests even though there would be no consequences if they did not do so (apart from the effect it would have on their conscience and your relationship); in fact, a completely trustworthy person would never betray your interests regardless of the consequences to himself. In any case, trust depends on free will; a person may be trustworthy or untrustworthy, but a business or organization cannot, because they do not make decisions; people within them do. Executives of a publicly-owned corporation are legally liable if they make decisions that they know will not maximize shareholder profit, which generally means that they usually act in the corporation's financial self-interest, which may diverge from yours. Unfortunately, some people are also like this. As a consequence of this, corporations routinely breach the privacy of customers and third parties by discarding hard drives with their data on it (A Remembrance of Data Past, http://www.computer.org/portal/cms_docs_security/security/v1n1/garfinkel.pdf). They almost never take the time to encrypt laptop hard drives, even though that software is totally free (see 28.7.5). Thus, it is often desirable to use take measures to ensure that the other party's interest and your own overlap as much as possible, and to minimize your dependence on them when your interests diverge. Now would be a good time to re-evaluate anywhere your security relies on a publicly-held corporation, especially when it is a free service. Some people would think that paying money is enough, but it may not be; that kind of reasoning (that you can buy security) may work in practice but is not the kind of argument that an "absolute security" person would make (see 35.2). Would you trust your life to someone merely because you paid them? You would probably want to know if they are qualified, if they are a sociopath, and a number of other things.
No signature? No execute! - Mike AckerMost people who aren't as well-versed in security as we are often mistakenly believe that one can ensure security by only running a small, fixed list of programs that are presumed to be safe, or only visiting certain well-known web sites. You should first remember that the mere fact that something is dangerous to process suggests that our systems may not be properly designed in the first place, but operating systems which don't allow us to run new programs are pretty boring, so let's discuss the limitations of author policies. Even a well-known web site can be vulnerable to cross-site scripting (see 23.2), where they display potentially-malicious content which they did not create. What, exactly, is the criteria to determine if an author, program, or web site is safe or unsafe (see 4.1)? Microsoft has developed several signed ActiveX controls which turned out to be exploitable (http://www.kb.cert.org/vuls/id/753044, http://www.kb.cert.org/vuls/id/713779http://www.securityfocus.com/bid/999), so if you indicated that you trusted anything signed by Microsoft, any other programs could call these controls to violate your security. IBM was discovered recently by eEye to have a similarly buggy ActiveX control (http://osdir.com/ml/security.vulnerabilities.watch.announce/2006-08/msg00005.html). So clearly, even if the author is trusthworthy, we cannot be sure the program cannot violate our security. Nor can we be sure that everyone in a given organization is trustworthy; surely in a company that size, someone is untrustworthy! Knowing who the author is helps, because it increases the likelihood of punishment or retaliation in the case of misbehavior, but can't prevent incompetence. Signing code does not make it secure; even with signed code, we still have to learn to create and maintain secure systems. In fact, it's even worse than that. Some SSL certficates were issued in Microsoft's name and authorized by VeriSign to an individual not associated with Microsoft (http://www.csl.sri.com/users/neumann/insiderisks.html#132). So now, when you trust things signed by Microsoft, you're also trusting things signed by some talented third party who isn't afraid of commiting some fraud. Since many commercial products link against libraries provided by other companies, simply having a signature doesn't mean that company really wrote a particular piece of code. Similarly, many web sites use content derived from other sources, so the domain may tell us nothing about who created a particular image, or even web page. Did Youtube create all the video content on its site? If not, why should we trust (the motives of) the authors of that content as much as we trust (the motives of) the company that owns the servers and domain name? Limiting our list of acceptable software authors to a single company may help that company's profits, but it won't necessarily make us secure. One unasked question of signed code is "how do you know who to trust?", and the answer to that is "those who are trustworthy and write secure code". The more important unasked question is "given that our software may be vulnerable, how do we know what is safe?", but the answer is "until you enumerate all the vulnerabilities, you don't" (see 4.1).
Never attribute to malice that which can be adequately explained by stupidity. - Hanlon's Razor (http://en.wikipedia.org/wiki/Hanlon) Any sufficiently advanced incompetence is indistinguishable from malice. - Grey's Law (http://en.wikipedia.org/wiki/Grey)So suppose that due to a flaw in a vendor's product, you suffered a serious intrusion. Since most pieces of commercial software come with end-user licensing agreements (EULA) that specifically disclaim any liability, what are you going to do? Even if you knew it was malice, you probably couldn't prove it. This is an example where you are unable to apply the principle of removing excuses (34.13).
Crypto ergo sum.If you have any questions about cryptologic terms, first check Terry Ritter's excellent glossary: http://www.ciphersbyritter.com/GLOSSARY.HTM You may also wish to view Peter Gutmann's "Godzilla Crypto Tutorial": http://www.cs.auckland.ac.nz/~pgut001/tutorial/
The ratio of unique Greek symbols to numerical constants in any scientific equation is inversely proportional to the comprehensibility. - Dolan's Law And, directly proportional to the strength of the argument of the said scientific equation. - Klofa's Corollary
As always, I think the right rule is "encrypt until it hurts, then back off until it stops hurting". - Perry Metzger (correspondence to cryptography mailing list)Nobody knows for sure how much is enough. What seemed good enough yesterday is not today, and might not actually have been yesterday. How much can you afford? How much would it cost you if it were broken? If you don't have linesec (see 32.1), then a common assumption is that the adversary may eavesdrop on your communication. And if the adversary can eavesdrop, they can record encrypted conversations. Then, if your cryptography turns out to be weak, or your random number generation turns out to be weak (see ), your communications are disclosed retroactively. In other words, you can't just fix your cryptography when it is found to be broken; a prudent designer will build in more cryptographic strength than he needs to prevent against future developments in cryptography.
Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police. - Eugene Spafford (http://homes.cerias.purdue.edu/~spaf/quotes.html)
Security's worst enemy is complexity. - The Complexity Trap, (http://www.schneier.com/paper-ipsec.pdf)Ferguson and Schneier's A Cryptographic Evaluation of IPSec (http://www.schneier.com/paper-ipsec.pdf)captures the main argument against IPSec, which is that it is too complex. Alas, this may well be true of any protocol involving cryptography.
The multiple human needs and desires that demand privacy among two or more people in the midst of social life must inevitably lead to cryptology wherever men thrive and wherever they write. - David KahnTheir proper use; what they guarantee, what they don't. These are your building blocks. Already covered elsewhere (esp. Ritter's crypto glossary, http://www.ciphersbyritter.com/GLOSSARY.HTM).
| HMACK=h((K |
Ä | opad)||h(K |
Ä | ipad)||m) |
Plaintext image of Tux
ECB-encrypted image of Tux
Image of Tux encrypted in other (chained) modes
Encryption:
The protocol should authenticate what is meant, not what is said. - The Horton Principle (http://www.schneier.com/paper-ssl.html)This quote suggests that you should authenticate plaintext, not ciphertext. In fact, if the plaintext has more than one encoding (see 28.5.5), you should pick one to be canonical and authenticate that. Having to convert the data to canonical form before authentication is unfortunate but one of the consequences of multiple encodings. Mutual Authentication Protocols I once took all the mutual authentication protocols in Schneier's Applied Cryptography and factored out the trusted third party to create simple two-party mutual authentication protocols (apparently those are so trivial he didn't bother to mention them). It was an interesting exercise, and I noticed that all of the results had three half-trips (1.5 RTTs). Except in the case of a mutual open, it seems like this is the minimum, and probably not coincidentally is the number of half trips needed in the TCP three-way handshake. It seems pretty intuitive to me, but I haven't seen a proof that this is indeed the minimum. Simplest MAP: A->B Ch1, B->A R1Ch2, A->B R2.
In cryptography and steganography, deniable encryption is encryption that allows its users to convincingly deny the fact that the data is encrypted or, assuming that the data is obviously encrypted, its users can convincingly deny that they are able to decrypt it. Such convincing denials may or may not be genuine, e.g., although suspicions might exist that the data is encrypted, it may be impossible to prove it without the cooperation of the users. In any case, even if the data is encrypted then the users genuinely may not have the ability to decrypt it. Deniable encryption serves to undermine an attacker's confidence either that data is encrypted, or that the person in possession of it can decrypt it and provide the associated plaintext. - Wikipedia
Three Rings for the Elven-kings under the sky, Seven for the Dwarf-lords in their halls of stone, Nine for Mortal Men doomed to die, One for the Dark Lord on his dark throne In the Land of Mordor where the Shadows lie. One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. - J.R.R. Tolkein, The Fellowship of the Ring (http://en.wikipedia.org/wiki/One_Ring)Key management is a term that encompasses a wide variety of problems and solutions:
"The generation of random numbers is too important to be left to chance." - Robert R. Coveyou of Oak Ridge National Laboratory
[W]e will be able to interpret the laws of probability and quantum physics as being the statistical results of the development of completely determined values of variables which are at present hidden from us ... The idea of chance ... comes in at each stage in the progress of our knowledge, when we are not aware that we are on the brink of a deeper level of reality which still eludes us. - De Broglie (http://www.eequalsmcsquared.auckland.ac.nz/sites/emc2/tl/philosophy/dice.cfm)Assume there is no information that is available to help anyone predict the outcome of an event prior to the event's occurence, and the event outcomes are independent and uniformly distributed. Then if there are n states, then anyone's chance of guessing the outcome prior to the event is exactly
|
1
|
|
|
|
|
There is no such thing as a random number, only a randomly-generated number.For an adversary who only has access to the output of the random number generator (RNG), one assumes that predictability takes the form of a pattern in the output. Any pattern at all means that it is somewhat predictable; for example, if it generates slightly more ones than zeroes, the "DC bias" is off and it is not entirely predictable. But how can we prove there are no patterns, when the number of patterns is infinite? We cannot do this through testing any finite number of patterns at a time. This is what lawyers mean by not being able to prove a negative, but it's easy to prove some negatives; to prove that there aren't any pennies in my hand, you can look. It's negations of claims of existence (it's not the case that there exists an x such that x is a unicorn) that are hard to prove, because they are universal claims (for all things x, x is not a unicorn). It's just as difficult to prove a simple positive universal claim, such as "bodies in motion stay in motion", or that the normal physical laws hold the same everywhere and in all situations. This quandary was summed up in a pithy way in a Dilbert comic (http://web.archive.org/web/20011027002011/http://dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif).
A monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type the complete works of William Shakespeare. - Infinite Monkeys Theorem (http://en.wikipedia.org/wiki/Infinite_monkey_theorem)Suppose the output is 01110011; is that more or less random than 00000000? Each sequence is just as likely if the source is random (1 in 256). Looking at either, can we tell whether the source is random? No, we cannot. The output alone says nothing definitive about the source. However, if we have a model of the source, and an output, we can say how likely the source would be to generate that output, but we cannot say how likely an output was to be generated by a particular model of a source, since the number of potential models is infinite. XKCD did a funny comic about this (http://xkcd.org/221/).
The secret to creativity is hiding your sources. - Albert EinsteinSo what do we do? We try to understand the source of the output. We model it, theorize about it, quantify it.
Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin. - John von NeumannSince hardware random number generators are expensive, most people do without them. There are a few ways of doing this, involving making measurements of internal state of the system that should be difficult or impossible for the adversary to guess. There is some controversy over the practice (hence my inclusion of the quote above), as the adversary may have some insight into some of these sources, and we don't know how random they really are.
The FreeBSD operating system implements a 256-bit variant of the Yarrow algorithm to provide a pseudorandom stream — this replaced a previous Linux style random device. Unlike the Linux /dev/random, the FreeBSD /dev/random never blocks. It is similar to the Linux /dev/urandom, intended to serve as a cryptographically secure pseudorandom number generator rather than based on a pool of entropy (FreeBSD links urandom to random). - Wikipedia (http://en.wikipedia.org/wiki//dev/random#FreeBSD)For more information on Yarrow, see 29.2.1. This is not a TRNG, but rather a PRNG. Entropy Gathering Daemon EGD is used on systems that don't have a convenient source of random bits. It is a user-space program that runs programs like vmstat, w, and last to gather information which may not be knowable by an adversary. It stirs the information it gathers into a pool of entropy, much like the Linux /dev/random, and allows other programs to read out of this pool. It is meant to be used with GPG, but can be used with other programs. It is written in Perl.
In a closed, deterministic machine, unpredictability never increases.Thus, my first law of unpredictability (by analogy with the second law of thermodynamics) states that in a deterministic system, unpredictability never increases. Put another way, the unpredictability of a completely deterministic system tends to decrease over time; if my pseudo-random number generator is seeded with a certain amount of unpredictability, unless it is carefully designed, it may lose unpredictability over time by mapping n states at time t to the same state at time t+1. For example, if you repeatedly hash a value, since hash functions are designed to be indistinguishable from random functions, and since random functions tend to not to be one-to-one, this system will tend degrade in unpredictability over time and eventually enter a cycle; see The Handbook of Applied Cryptography for an analysis. The analogy we may use here is that mapping n states to a smaller number in a random number generation system is a wasteful operation, analogous to friction, and should be avoided.
Any logically irreversible manipulation of information, such as the erasure of a bit or the merging of two computation paths, must be accompanied by a corresponding entropy increase in non-information bearing degrees of freedom of the information processing apparatus or its environment. - Landauer's Principle (http://en.wikipedia.org/wiki/Landauer%27s_principle)It is probably no accident that only reversible computations (http://en.wikipedia.org/wiki/Reversible_computing) maintain the unpredictability of the system, and any time we destroy unpredictability (information) by reducing the number of states of the system, we must dissipate energy (in the literal physics sense).
Unpredictability may rise in a deterministic system, but by no more than the amount added, nor may it exceed the state capacity of the deterministic system to which it is added.By extension, when we feed unbits into a deterministic system, we may increase the unbits of the output, but only up to the number of bits total. That is, if I have a sample which has x unbits and y bits total (where x £ y) then I may encrypt it using a key of k unbits, and the output may still have y bits, but the number of unbits x' may have increased by up to k unbits (that is, x £ x¢ £ x+k £ y). Thus, the second law of unpredictability is that an increase in the unpredictability of a deterministic system is less than or equal to the amount of unpredictability added. It is certainly possible to throw away unpredictability by mapping two input states onto a single output state, but if we choose our operations carefully, we may retain most of it.