Fresh Defense

I have been thinking of a new way to express an old idea about the need to trust and verify various components of a system. Inspired by the W^X (write XOR execute, a way to prevent the execution of injected code) relation, I think I came up with a good trust pattern. The pattern is:

Trust XOR Verify. Trust or Verify, but not both, and not neither.

In security systems, it is often desirable to verify the properties of code that are relevant to its trustworthiness. In essence, users of a system traditionally face a choice: either trust the code that you execute (thus tacitly admitting that it can violate your security) or verify the security properties of the code so that you have some assurance that the code behaves as expected.

If you verify the properties that you trust, doing so introduces needless overhead. If you don’t trust a component, but you don’t verify it, then you are exposed to needless risk. So, you should either trust a component but not verify it or not trust a component and so verify it. This logic is captured exactly by the XOR relation:

Trust   Verify    Trust XOR Verify
 T         T                 F    (needless performance degradation)
 T         F                 T    (acceptable risk, no performance degradation)
 F         T                 T    (non-acceptable risk, justified degradation)
 F         F                 F    (needless risk)

Great article, linked from Slashdot:

A Mathematician’s Lament by Paul Lockhart

Many of the same observations hold for Computer Science and hacking.

EFF has a story on the seizure of personal property of a BC student (and subsequent quashing of the search warrant) suspected of computer crimes (this story has also been covered by Bruce Schneier). One strong “reason” that investigators and complaining witnesses suspected him: because his computer displayed “…a black screen with white font which he uses prompt commands on.” The specific incident arose from personal conflict, but the excuses used by the authorities to seize property were somewhat thin.

Because the student used what is arguably an expert’s tool, to the complaining witness (who was himself a computer science student) and possibly the investigating officers, that indicator of expertise must mean that the accused student was up to no good. Expertise as an indicator of malicious intent? Seriously?

I view this as a demonstration of Clarke’s Third Law: “Any sufficiently advanced technology is indistinguishable from magic.” The common citizen (and I include peace officers, barristers, and magistrates in this designation — and, sadly, a lot of CS majors) has no experience with the command line: its very presence, spare and lean, fills them with an instant dread of the unknown because it supplies a reminder of a conversation that they just cannot participate in.

No hints, clues, or cues as to what to do next surround the bare prompt (even those prompts that do convey information convey specialized information such as a directory or host name). The prompt sits there, patiently waiting for the user to speak magic incantations. In response, it either says nothing or spits back dense reams of text — no images, and little or no markup. Ordinary people find themselves completely out of their depth in this situation. Anyone capable of manipulating this environment must have some mysterious knowledge and power. And people find mysterious power easy to fear.


[me@host ~]$ man fear
No manual entry for fear
[me@host ~]$


The Working Group at CISSE that Sergey, Greg, and I ran on “The Hacker Curriculum” was fairly successful. We generated a lot of interest and arrived at a few important initiatives going forward:

1. The need to elucidate the principles of hacker curriculum. These principles are rarely written down, codified, or transformed into a formal program of study.
2. The need for a curated repository of intrusion defense, analysis, and recovery scenarios based on live-action data rather than canned network traces or traffic dumps.
3. The need to share success stories about how Hacker Curriculum Principles can be integrated into the standard CS curriculum or other creative mentoring, training, or outreach efforts like the Dartmouth CSI or the SISMAT program.

You can follow our progress (or join in the conversation) at the Hacker Curriculum Web site at:

hackercurriculum.org

which is also linked at the right side of the blog.

On my way back to Vancouver from CISSE, I ran into a border guard who asked me for proof, such as an airline itinerary, that I intended to leave Canada. Not having any such documentation (I ceased carrying printouts of my airline itineraries since I have never been asked for them), I could only assert that I had stable employment in the US and no long-term plans to remain in Canada. At this point, we were at an impasse, since he had no way to verify my intent, and I had no ready way to prove it to him.
His worry was obvious: I am one of those people who are highly mobile, with almost no fixed address or infrastructure holding me to a particular country or location.

Even if they were to pull me into secondary screening and look at the electronic copies of my itinerary, my intent could have been to simply abandon my ticket home. My point is this: beyond some in-depth interview, no paper can prove what my intent might have been.

This incident highlights just how difficult border access control can be: guards are tasked with divining the intent of visitors, travelers, and citizens. Intent is a complex, multi-layered thing with an important temporal component. Border guards must try to understand both long-term and short-term intent as well as any potential security threat or otherwise illegal status. In the course of a one minute conversation, they tend to do this fairly well (from my perspective: I have never been refused entry or even pulled into secondary screening in either direction).

In any event, the guard let me go with a strong admonition to carry such proof in the future and make their job easier. But now that the Western Hemisphere Travel Initiative is in full force (i.e., passports required for even land travelers), will border guards be forced to turn more to other secondary documentation to prove intent? How reliable is this documentation at predicting, conveying, or verifying intent?

Might their job previously have been made easier by the diverse array of identification (keeping in mind that identification has little to do with intent) material presented before WHTI? Now that everyone has a passport, that identity “feature” is more homogeneous, and thus carries less information. At the end of the day, allowing someone into a country is ultimately a trust decision.