August 2004 - cypherpunks-legacy

Every Vote Counts - If It's Counted
by R. A. Hettinga 08 Aug '04

08 Aug '04

<http://www.campaigndesk.org/archives/000805.asp> CJR Campaign Desk: Archives Critique and analysis of 2004 campaign coverage from Columbia Journalism Review The Longer View August 08, 2004 Every Vote Counts - If It's Counted By Susan Q. Stranahan On November 2, millions of Americans will vote on computers, many of which may be vulnerable to partisan hackers, disgruntled poll workers, or anyone else with a desire to alter the outcome of the election, writes Ronnie Dugger in the current issue of The Nation. "The result," he says, "could be the failure of an American presidential election and its collapse into suspicions, accusations and a civic fury that will make Florida 2000 seem like a family spat in the kitchen." Dugger's detailed analysis of the problems of electronic voting and the potential for fraud and error would seem to be a crucial election story of 2004, full of the stuff journalists love -- hints of skullduggery, cronyism, and conflicts of interest. But, with a few exceptions, the advent of e-voting has remained an issue hovering persistently beneath the media's radar. The stories that have appeared largely have been local, piecemeal and rarely rise much beyond the "he said/she said" level of reporting. As a result, the public -- to the extent that it's even aware of the controversy -- is left to its own devices to figure out a complex issue, with considerable ramifications. New York Times editorial page writer Adam Cohen is one of the very few who has delved into the subject, spending much of the year writing about the "mechanics" of democracy in a series entitled "Making Votes Count." Electronic voting -- and its lack of accountability -- has been a frequent topic. Cohen, a lawyer with an interest in politics and technology, opened his series last January with this warning: The morning after the 2000 election, Americans woke up to a disturbing realization: Our electoral system was too flawed to say with certainty who had won. Three years later, things may actually be worse. If this year's presidential election is at all close, there is every reason to believe that there will be another national trauma over who the rightful winner is, this time compounded by troubling new questions about the reliability of electronic voting machines. This is no way to run a democracy. Given the media's lack of interest in the subject, it can also be said: This is no way to cover one, either. Come November, can you be sure that your vote will be accurately recorded? It seems a rather fundamental question that cries out for an answer. About one-third of the expected computerized vote this fall will be tabulated by touch-screen machines that will provide no paper trail of a voter's choices, and, as a result, are vulnerable to tampering. Writes Dugger: "The United States therefore faces the likelihood that about three out of 10 of the votes in the national election this November will be unverifiable, unauditable and unrecountable." In Florida, where the outcome of the 2000 presidential election remained in limbo for 36 days due to voting irregularities, more than half the state's voters will rely on paperless touch-screen systems. Florida is a crucial swing state, with its winner garnering 27 electoral votes -- 10 percent of the total needed. Ironically, it was the chaos of the Florida returns four years ago that catapulted the nation towards electronic voting. In 2002, Congress passed the Help America Vote Act, and when President Bush signed it, he declared that "when problems arise in the administration of elections, we have a responsibility to fix them." But, as the Times' Cohen noted earlier this year, the president's budget provided only $40 million of the $800 million promised by Congress for election improvements at the state level. Wrote Cohen: "[N]either the president nor Congress is very serious about fixing the system." Some states scrambled to switch to electronic voting, and for the limited federal funds to buy new equipment. About 20 percent of the nation's 3,114 counties will have switched completely to computerized voting by November, according to Election Data Services, Inc., a Washington, D.C. research company. (Some of those machines offer a printed copy of the ballot as a backup; some do not.) But the states also discovered that there are no federal guidelines or security standards for the equipment. That will come at a later date, long after this presidential vote. (The Election Assistance Commission, appointed by President Bush to set those standards and oversee the transition, has been slow to get organized, in part because of a lack of funding.) The electronic voting market is dominated by a handful of companies, which stand to make huge profits from the shift to touch-screen computers and the software that runs them. Nearly 100 million votes will be cast on the computers operated by this tiny group, which has aggressively promoted its product and just as vigorously defended the secrecy and reliability of its technology. Diebold, Inc., of North Canton, Ohio, holds about 45 percent of the equipment market. Its track record thus far has been less than impressive, and not necessarily reassuring. As Dallas Morning News reporter Vikas Bajaj noted (registration required), Diebold has "become a lightning rod for the industry": In April, California Secretary of State Kevin Shelley, citing security concerns, banned Diebold machines in four counties. He has also required that any electronic voting machines the state buys must have verified paper trails. Ohio's legislature in May required that all electronic voting machines have paper trails by 2006. In July, the state's secretary of state, J. Kenneth Blackwell, stopped the use of Diebold machines in three counties, saying they hadn't met security requirements. Diebold's problems don't stop there. Critics cite a fund-raising letter written last year by the company's chairman and chief executive, Walden O'Dell, who said he was "committed to helping Ohio deliver its electoral votes to the president." He has since apologized. More worrisome to many experts, however, is the apparent vulnerability of the so-called source code used in the Diebold machines. "Given the gravity of the security failings the computer security community has documented, it is irresponsible to move forward without addressing them," Dr. Avi Rubin, a computer science professor and technical director of the Information Security Institute at Johns Hopkins University told a House committee last month. As Knight Ridder's Sumana Chatterjee wrote: "The main problem, according to Rubin, is that there's no way for election officials to be sure that electronic machines are free of codes designed to manipulate results. Companies are reluctant to share their 'source code,' the proprietary software that controls voting and tabulating results, so their software can be checked independently." Backers of computerized voting -- among them many state and local election officials -- dispute the critics' worries about vulnerability. Chatterjee quoted Linda Lamone, Maryland state administrator of elections, who also testified before the committee: "Although any electronic voting system is hypothetically 'hackable,' I am confident that the likelihood of this occurring is extremely remote." Hackers would need a working knowledge of the software's specific programming language and gain physical access to computer servers and voting machines, she testified. Unlikely, maybe, but the first of those two conditions has already been met. Bev Harris, a Seattle literary agent and voting rights advocate, has become something of a legend among critics of e-voting. Miami Herald columnist Jim Defede wrote about Harris last month: Concerned about the lack of security, Harris Googled Diebold, hoping to find a computer engineer or programmer who could put her fears to rest. Instead, she stumbled across a link to 40,000 files of the company's ultra-secret source codes, which she downloaded and posted on her own web site, asking experts for help in analyzing the information. Diebold obtained a court order shutting down her site. Ultimately the codes were posted on the congressional website of Democratic Rep. Dennis Kucinich. Diebold claims the code was outdated and no longer in use. In Georgia during the run-up to the 2002 Senate race, as The Times' Adam Cohen reported, Diebold machines were plagued by hardware and software problems, and the company on several occasions sent "patches" -- programming updates -- for installation. (The software was installed without the required review and approval by the Georgia Secretary of State.) When the votes were counted, Sen. Max Cleland, a Vietnam war hero and triple amputee, who held a strong lead in the polls before Election Day, suffered a decisive loss to challenger Saxby Chambliss (who also ran ads picturing Cleland with Osama bin Laden). Critics, like Bev Harris, questioned whether the patches could have converted Cleland votes into Chambliss votes. Because there was no paper trail, there was no evidence to prove or disprove the allegation. In his series, Cohen notes that the secrecy over source code may be a red herring. Source code can be produced, if authorities insist. Nevada gaming officials have instant access to source codes and all equipment at casinos in the state without compromising proprietary information. Ironically, he says, "gamblers are more protected than voters." Critics of e-voting come from two camps -- a growing number of local activist groups around the country which last month sponsored a national "The Computer Ate My Vote Day,' and computer security experts. The Nation's Dugger quotes one of the most outspoken, Dr. David Dill of Stanford University: Last fall during a public talk on "The Voting Machine War" for advanced computer-science students at Stanford, Dill asked, "Why am I always being asked to prove these systems aren't secure? The burden of proof ought to be on the vendor. You ask about the hardware. 'Secret.' The software? 'Secret.' What's the cryptography? 'Can't tell you because that'll compromise the secrecy of the machines.' ... Federal testing procedures? 'Secret'! Results of the tests? 'Secret'! Basically we are required to have blind faith." Dugger also quotes recent testimony from Johns Hopkins' Avi Rubin to the federal Election Assistance Commission: "I do not know of a single computer security expert who would testify that these machines are secure." Advocates of e-voting have portrayed criticism as coming from a handful of unhappy academics, or as being motivated by partisan politics -- claims the media have largely bought into. Among the chief proponents of the new system is Gov. Jeb Bush, who presided over the 2000 debacle from which his brother emerged with an official winning margin of 537 votes. As the Miami Herald reported last month, Gov. Bush has suggested that, as the paper put it, "people who repeatedly raise questions about the touch-screen machines were doing it to motivate their voters in the upcoming presidential election, in which Florida will be a battleground state." But that's not necessarily true elsewhere. The Republican secretaries of state in Nevada and Missouri -- both expected to be hotly contested this fall -- have expressed concerns about the reliability of the equipment. As a result, they have required that touch-screen voting machines also be equipped with a "voter-verified paper trail" in November. (This is an inexpensive add-on to the machine, which allows a voter to confirm manually his or her vote before it is cast; that confirmation is retained independently of the computer tally in the event a recount is required.) It is this type of backup that Adam Cohen and others believe will eliminate many of the potential problems with e-voting. Nevada's 2,000 electronic voting machines will all come equipped with printers this fall. Secretary of State Dean Heller told the Associated Press that paper receipts are "an intrinsic component of voter confidence." Nevada is the first state to institute such a policy statewide. Nationally, legislation requiring printed backups is pending in both the House and Senate -- but no action is expected before November. So, the question remains: Will this year's contested presidential election proceed smoothly, or will the scenario be closer to what a letter-writer to The New York Times predicted: "[T]he havoc wreaked by the butterfly ballot [in 2000] will soon be compounded by a plague of worms, the kind encoded in electronic voting machines that leave no 'voter verified paper trail.'" No one knows. But it sure sounds like a story worth pursuing by more than a few lonely souls like The Nation's Ronnie Dugger and the Times' Adam Cohen. Posted 08/08/04 at 12:01 AM -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

2 1

Is Source Code Is Like a Machine Gun?
by R. A. Hettinga 08 Aug '04

08 Aug '04

<http://samsara.law.cwru.edu/blog/archive3/Is_Source_Code_Is_Like_Mach.html> Next: August 2, 2004 Up: August 6, 2004 Previous: August 6, 2004 Contents Is Source Code Is Like a Machine Gun? Eugene Volokh has posted a message on the Cyberprof email list seeking comments on a thought experiment as to whether the same scope of first amendment protection should be accorded to a sculpture which happens also to be a working automatic weapon as to the ``source code'' of a computer program that can be used for illegal activities.1 That inspired the following response on my part: Date: Thu, 05 Aug 2004 14:19:49 EDT To: CyberProf List . . . From: "Peter D. Junger" <junger(a)samsara.law.cwru.edu> Subject: Re: Source code distribution restrictions as speech restrictions I will try to respond without quoting at length from Eugene's message since I think that the basic difference that we have has to do with our differing understandings of the nature of computer programs, including source code and that it is probably easier to address that difference directly. In the first place I cannot see how source code differs significantly from any other computer program or, for that matter, from any other data stored or transmitted as text, including as a string or stream of binary digits. Something very important seems to be missing from Eugene's thought experiment: any reference to a computer. Yet it is a computer, and not a computer program, that corresponds to Eugene's machine gun. The computer and the machine gun are both tangible objects that persist for a period of time in three dimensional space. Source code or any other data that is processable by a computer is, on the other hand, pure information--nothing more or less than a pattern or a number--and though a representation of that information can be stored in, or on, some tangible medium like a compact disk or a piece of paper, that compact disk or piece of paper is not the source code or other data. (This is, I believe, equivalent to the fact that in the law of copyright a copy of a work fixed in a tangible medium of expression is not the intangible work itself.) Come to think of it, one can merge the machine gun and the source code by etching the source code on the side of the machine gun, just as runes used to be etched on sword blades or the words ``drink me'' were affixed to the bottle that Alice came across at the bottom of the rabbit hole. Frankly I don't see how that could somehow make it unconstitutional for the state to outlaw the possession of the sword or the machine gun or the pure food and drug people to outlaw the sale and distribution of the liquid contents of Alice's bottle. But I would rather focus on the computer, rather than on the example of the compact disk, because a compact disk just sits there and doesn't do anything by itself whereas the computer --like the machine gun--actually does something and so is functional in the way that a machine gun is functional and source code, whether or not fixed in a tangible medium, isn't. There is, of course, an important distinction between the functionality of a machine gun and that of a computer. The function of a machine gun is to kill. The function of a computer, on the other hand, is to compute, and to compute is to process information. Computers, by the way, used to be people, who came equipped with ten digits. Modern computers, on the other hand, are machines that are wired (or otherwise structured) to process information represented as binary digits. Now, since the computer has to a large extent replaced printing presses and linotype machines, I find it difficult to believe that the freedom of the press protected by the first amendment would permit the outlawing of computers even though the need for a well regulated militia protected by the second amendment does not forbid the outlawing of machine guns. But Eugene's thought experiment does not deal with computers so I do not need to pursue the question of whether computers can be outlawed constitutionally. All that a computer does is process information. Data encoded in the form of binary digits--which can be called ``source code''--is fed into a computer which then processes that data in accordance with way in which it is wired and outputs other data encoded in the form of binary digits--which can, if one wishes, be called ``object code.'' Now rewiring a computer is called programming a computer, and that object code can--if it satisfies various syntactical requirements--be fed into the computer in a way that causes the computer to be reprogrammed, that is, to be rewired. But the program does not do anything and it certainly does not rewire the computer. To run the program someone must, directly or indirectly, flick a switch that causes the computer to rewire itself in accordance with the specifications (the ``instructions'' or the ``description'') contained in the program. And it is the computer that, like the machine gun, has the moving parts and thus does the functioning. Another way to put it is that all that a computer does is to manipulate text. The input is text, the program is text, and the output is text. And all that source code, or any other code, is is text. Now, of course, the protections of the first amendment are not absolute, so the writing and publication of source code, like any other text, can be forbidden if there is a strong enough justification. But, since code in no way resembles a machine gun, its resemblance to a machine gun cannot be that justification. And by the way, the fact that some text may be too ``functional'' to be copyrighted in no way suggests that it is not protected by the first amendment. If a text is useless there is, in fact, little reason to give it first amendment protection. This was written in considerable haste and undoubtedly contains large gaps in its reasoning. I have, however, some other work to do, and so I will end it here. After I posted that response to the Cyberprof list, I received the following inquiry off list: Just out of curiosity, would you liken software to the thought processes that are used to control the computer (and the machine gun)? If so, would restrictions on source code be more akin to thought control, rather then restrictions on devices? Here is my response to that question: [T]he quick answer is that I think of computers properly programmed as prosthetics that help us think (and perceive) like glasses and hearing aids and paper and pencils (and the invention of the alphabet and of mathematical notations) and so I do think that restrictions of software and also on computers amount to thought control. Consider the fact that there is hardly anyone left in the world who can calculate square roots now that it is so easy to do the calculation using a calculator. I consider doing arithmetical and logical calculations to be a (very small) part of what is involved in thought, but they definitely are thought processes. (I wouldn't say though that the thought processes are programs if one considers a program to be text. Programs are not processes, they are descriptions of or instructions for implementing a process.)2 For discussions of related issues see the entries on Expression Has Nothing to Do with It, Publishing Bombmaking Information and the First Amendment, and Copyright and the Confusion of ``Software''. Next: August 2, 2004 Up: August 6, 2004 Previous: August 6, 2004 Contents Peter D. Junger 2004-08-07 -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Bluesniper Creator Interviewed on Gizmodo (fwd from brian-slashdotnews@hyperreal.org)
by Eugen Leitl 07 Aug '04

07 Aug '04

----- Forwarded message from brian-slashdotnews(a)hyperreal.org -----

1 0

Simpson scores
by Major Variola (ret) 07 Aug '04

07 Aug '04

http://www.technologyreview.com/articles/04/08/wo_garfinkel080404.asp Good article re secure hashing

1 0

Propagating Security Context Across a Distributed Web Services Environment
by R. A. Hettinga 07 Aug '04

07 Aug '04

<http://www.sys-con.com/story/print.cfm?storyid=45690> SYS-CON Propagating Security Context Across a Distributed Web Services Environment Why, when, and how August 4, 2004 By Scott Morrison It's a problem as old as networked computing. Consider two applications. They negotiate a level of trust. How can that trust - or security context - be transferred to a third application, one that may exist in an entirely different security domain from the first? This problem has been solved before, but is limited by proprietary solutions that resist integration. The challenge now, which is a significant one, is to solve it again, but this time for Web services - a task complicated by the need to accommodate a broad range of established security procedures and legacy technologies. Context in Context Security context is an ambiguous term. Take, for example, the SSL protocol. Here, security context is largely cryptographic metadata - the master key, derived session keys, ciphers and hashes, etc. - which are associated by a public SSL session ID. The session ID exists precisely to allow reuse of these across independent connections and thus avoid the expensive public key-based handshakes that would be necessary to re-establish them. Authentication might not even be involved; such is the case with the Diffie-Hellman cipher suite. In this article, we will explore the more fundamental problem of transferring the security context established by an act of authentication - that is, a sufficiently substantiated claim of principle identity - between applications in a Web services environment. In doing so, we will use two important OASIS Web services standards, WS-Security (WSS) and the Security Assertions Markup Language (SAML). WSS and the Security Token Mechanism Back when I was still in high school, my parents gathered up the family and spent a summer traveling in China. During a few days in Beijing, I had a chop, or signature seal, carved with my name rendered phonetically in Chinese. In China, chops have been used as a means of signature and identity since the period of the Warring States, nearly 2500 years ago. The chop implements a security model called proof of possession. It is something physical you have, something you need to protect, and something you can use to create a security token that binds another object - a contract, a painting, etc. - to yourself. The binding consists of a stamp, most commonly rendered in red ink, of the name carved into the chop. The artistry of the carving establishes uniqueness and is a simple guard against forgery. Shortly after we returned home, thieves broke into our house. Along with the usual targets for theft - items like TVs and stereos - they took, oddly enough, my chop. I've always thought that this was a strange thing to steal: were they drawn to it because it was shiny and elegant; or was it an early example of identity theft? Perhaps there are checking accounts open in my name somewhere in Fujian. The real problem with my chop is that it really wasn't bound to my identity. It was fine for creating security tokens while I possessed it, but once lost, the thieves could create unlimited identity tokens with no real means for me to stop them. Security tokens, of course, come in many different forms and with varied purposes. A token could transport credentials; it might describe an authorization decision; it may encapsulate a key for a cryptography session. This diversity is one of the challenges faced by the technical committee developing WS Security. To this end, their specification does not attempt to mandate one form of security token over another; instead, it defines a simple encapsulation mechanism that should be able to accommodate most existing methods and technologies. Thus, in WSS, applications can make claims to identity, supported by tokens. The details of how to support a particular token mechanism is defined outside the main specification, in a separate document called a token profile. Security tokens appear as elements subordinate to the <Security> header, the block in a SOAP message under which all WS-Security related parameters appear. Most of the currently existing profiles are concerned with establishing a security context around identity. Consider, for example, username and password, probably the most familiar of all security token schemes. WSS defines a profile called - not surprisingly - the Web Services Security Username Token Profile. It defines a very simple and logical organization for usernames, passwords, and nonces; the latter enabling digest authentication schemes to provide credential validation without direct password transmission. WSS calls this type of token a proof-of-possession claim. Listing 1, taken directly from the specification, is an example. (the code is online at www.sys-con.com/websphere/sourcec.cfm) But what about transferring an existing context? You could argue against the need for this - after all, if you have a means of authentication, why not simply re-authenticate continuously with every independent transaction? HTTP basic authentication works in this way. When a browser successfully meets an authentication challenge, it will proactively insert credentials into the HTTP Authorize header for every subsequent request in the same realm. For some Web services applications, this is sufficient. For others, it can be tremendously expensive - the overhead of continuous credential validation can bring a directory to it knees. Furthermore, it may be unrealistic to believe that every server is capable of performing this operation. Often, this is because of access restrictions placed on central directories, perhaps due to topology, but often due to politics. Transferring a previously established identity context, then, is a valuable thing. But it's also difficult to carry out securely. WSS provides a means to do this within its abstract token profile mechanism. Under this use case, the tokens don't establish initial identity, but describe an existing security context. These tokens have to be authoritative, so that if a token is stolen - like my chop - it can't be used to hijack or destroy an existing application or cryptography session. This challenge is addressed by the WSS SAML profile. SAML and Context Transfer SAML is designed to pass security information between systems. The basis of SAML is a markup language for declaring assertions. Assertions are declarations of facts about a subject. You can think of a subject as the binding of an entity, such as a person or a computer, to an identity in a security domain. Assertions are generated by an issuing authority, which may front an existing identity server such as an LDAP directory. In SAML, there are three distinct kinds of assertions: * Authentication assertions: These statements describe acts of authentication that have already taken place. An authentication assertion does not describe another method to perform authentication, such as using an X509 certificate; it simply affirms that a subject S was authenticated by means M at time T. In listing 2, the authentication assertion declares that subject smorrison authenticated against the Layer 7 Technologies corporate directory using a password. * Authorization assertions: An SAML issuing authority can make an authorization decision to allow or deny access for a subject to a particular resource. * Attribute assertions: These assert that a subject is associated with a collection of attributes, represented as simple name/value pairs. For example, an SAML authority might declare that subject Scott is associated with group=developers and company=Layer 7 Technologies. By providing a generalized attribute mechanism, SAML makes an important point: that security context is more than just authentication and authorization, but also includes associated metadata that might be important in a security decision, such as a subject holding gold status in a frequent flyer system. In addition to assertions, SAML defines a request/response protocol for obtaining assertions from SAML authorities, bindings to protocols such as SOAP for transporting assertions and queries, and profiles, which take a more holistic approach to integrating SAML within an existing framework, such as SOAP messaging or conventional, HTML-oriented HTTP. While the vision behind SAML has been to produce a general-purpose language for communicating security context between distributed systems, its initial focus, growing out of a widespread and immediate need, has been on browser-based communications - in particular, single sign on (SSO) for the Web. SAML defines two additional profiles to address this, and in these, we can find a model for how SAML will ultimately support Web services (see Figures 1 and 2). Both scenarios are functionally similar. The user, authenticated on system A, clicks on a URL addressing content that resides on system B. The user should not have to re-authenticate on system B (thus establishing a separate, independent security context), but instead should transfer the existing context completely to B. To complicate matters further, B may reside in a different security domain from A, so B literally may not be able to validate the subject's credentials even if they are made available. Therefore, a trust relationship must be established between A and B, so that B relies on A's word that a subject has been necessarily and sufficiently identified. Virtually every large organization attempting to integrate their internal Web servers has encountered this problem. The difference between these profiles appears in implementation. Figure 1 depicts a pull scenario, in which a security token, called an SAML artifact, is passed to system B as a query parameter affixed to the URL. System B uses the artifact as a handle to take complete ownership of the security context from A; this is illustrated in the figure as a SOAP call from B to A, requesting control of the context and taking delivery as a collection of SAML assertions. SAML ensures that the server-side half of the context can only exist in a single place at any given instant. In contrast is the push scenario, which transports the context entirely within a message - in this instance, the assertions reside as a hidden field that's POSTed in a form. This eliminates the need for system B to retrieve the context from A, but requires that the assertions be signed to prevent tampering. This is actually closer to a typical Web services scenario, where context is a security token rendered into a SOAP message, but more on that later. In practice, this process usually involves a centralized issuing authority and clever use of HTTP redirects. But what is noteworthy here is the security model. These browser profiles rely on SSL and HTTP authentication mechanisms as a means to protect the confidentiality, integrity, and trust of assertions (or artifacts). It uses existing Web security to ensure that assertions are relayed only through the subject they describe. This eliminates the threat of replay attacks and session hijacking. It's a crucial point: an assertion, even signed by an issuing authority, needs to be bound to the subject presenting it. Otherwise, what's to stop an intruder from simply copying a signed authentication assertion and using this to stake claim to that assertion's correlated security context? Unbound from identity, an assertion is like my stolen chop. In the browser profiles, secure, authenticated channels are necessary to ensure that security tokens only pass between trusted entities. In Web services, where security is implemented on a message-by-message basis and no secure channel exists, there needs to be a different approach. WSS SAML Profile SAML, of course, fits cleanly into the WSS Security token structure. The real challenge, though, is more subtle than syntactic contracts. WSS is about providing security on a message-by-message basis. Furthermore, it is concerned with absorbing security into the message itself and decoupling it from channel strategies like SSL to be able to provide continuity in encryption, integrity, authentication, and reliability across a diverse set of transports and intermediates - from SMTP to MOM to plain text files, in as many hops as the application demands. The challenge, therefore, is binding a subject's identity to an assertion so that it is verifiable by the ultimate receiver of a SOAP message. SAML addresses this with an assertion element we have not encountered yet, <SubjectConfirmation>. An SAML issuing authority uses SubjectConfirmation to bind a particular subject's identity to an assertion. There are various strategies for this, such as including Kerberos service tickets, and these are left for specification in the relevant profile. The WSS SAML Token Profile adopts an interesting approach. Within this element, the issuing authority can insert the subject's public key. Remember, the issuing authority is making a definitive statement about an act of authentication that has already taken place, so it's likely to hold the subject's public key. If the subject authenticated using its certificate under the WSS x509 Token Profile, the key is there. Alternatively, it should be able to retrieve the key from a trusted certificate server after firmly establishing the subject's identity under a different authentication scheme, such as username/password. The key resides within the SubjectConfirmation element, inside a standard <ds:KeyInfo> block, a rich structure already described in the W3C XML Digital Signature specification. The issuing authority then signs the entire assertion, thus authoritatively binding assertion and key. In this way, it's not unlike a certificate, which uses the signature of a trusted party to bind a public key to an identity (represented as a DN). Consider also, what often makes a certificate useful is the additional information residing within it. An SSL certificate binds a DNS name to the CN, thus allowing clients to verify that the TCP socket they've opened is indeed connected to the Internet entity described in the certificate. E-mail addresses were added to support similar trust validation, and v3.0 extension fields in the x509 specification promote still richer models of trust. Listing 3 shows an authentication assertion, generated and signed by an SAML issuing authority. This signature binds the subject of the assertion to its DSA public key. It also includes its X509 certificate against which a receiver can compare a pre-existing trust relationship. So why is this useful? Precisely because now the subject can create an undeniable association between any SOAP message it authors and this assertion. Our problem up until now has been that, even though it is signed by the issuing authority, a plain assertion could be intercepted and used by anyone. In this way, it's like the thieves who stole my chop, and could forge unlimited new messages claiming to come from me. Suppose we are a SOAP receiver - say some arbitrary service downstream - and we take delivery of a SOAP message containing an assertion claiming that Scott was authenticated at noon on Tuesday. How can we be confident that the sender of the SOAP message really is subject Scott, described in the assertion? SubjectConfirmation is the key - or perhaps better, holds the key. WS-Security calls this an endorsed claim, as it's been sanctioned by a trusted third party. Figure 3 is a block diagram of a SOAP message that shows how it all comes together. It maps a typical message that a Web services consumer would compose while participating in an SSO scenario. Fundamentally, this is the same as the browser SSO model illustrated in Figure 2, with SOAP service invocations substituted for HTTP/HTML. In this use case, System A might be a centralized authentication service that consumes username and password credentials (under the WSS token profile described previously), and returns a signed SAML SSO assertion (an aggregate of an authentication assertion, time of validity, and other optional attribute fields). Bound in this assertion is the public key of the authenticated subject. To compose the message in Figure 3, the consumer copies the signed assertion into the SOAP message unchanged. To prove rightful ownership of this assertion, the subject signs the message body. Remember, only the actual can do this, as only the subject possesses the private key paired with the public key in the assertion. This establishes an irrefutable connection between the author of the SOAP message and the assertion describing an authentication event. It is the receiver's responsibility to process this message appropriately and take action on it based on its predetermined trust relationship with the SAML issuing authority. Under SAML, the ultimate receiver of the message is called the relying party - a logical piece of nomenclature, as the receiver relies on the trust it has with an issuing authority. Listing 4 shows what the SOAP message looks like, as it might be delivered to the receiver. It's becoming complex, because we now have signatures from two different parties: the SAML issuing authority (over the assertion only); and the SOAP sender (over the message body). The sender, could, of course, extend its signature across the entire envelope if that is the level of integrity that the application required. In the subject's signature block, the SecurityTokenReference element contains a reference back to the assertion, where we can retrieve the public key for signature validation. Ultimately, what we have created in a chain to a trust root, not unlike a certificate chain. It might help to refer back to the block diagram in Figure 3 to help navigate through this complexity. There's one important detail we have yet to cover. Find the <SubjectConfirmation> element in the authentication assertion in Listing 4. It has a subordinate element called <ConfirmationMethod>. In the example, ConfirmationMethod takes the value of the SAML-defined identifier urn:oasis:names:tc:SAML:1.0:cm:holder-of-key. This informs a receiver that, when processing any SOAP message containing this assertion, the attesting entity must prove their association with the assertion using a signature. An alternative processing model is called sender-vouches, indicated by the constant urn:oasis:names:tc:SAML:1.0:cm:sender-vouches. This addresses an issue found in another common Web services scenario. In sender-vouches, the attesting entity is not the subject described in the SAML assertion. However, it is acting on behalf of that subject. The receiver, therefore, must trust that this is indeed the case, that the sender has validated the true subject in some way and is working on its behalf. To make this work, the attesting entity must protect both the relevant parts of the SOAP message and the assertion itself to prove that it has made that association (after all, with nothing to conjoin these data, the aggregation could have come from anyone). Figure 4 depicts a typical scenario where this might take place. It's very similar to the classic three tier browser-based application - just substitute SOAP for HTTP/HTML, RMI or IIOP, and JDBC. System A is a Web services client. System B consumes and validates its credentials against an issuing authority. System C trusts that B validated A accurately, and processes messages from B with confidence that they are a consequence of an initial request of A. Conclusion Inside the WSS SAML token profile, we find the basic mechanism necessary to transfer one type of security context between applications using Web services. But don't lose sight of its limitations in scope and maturity. SAML - and by extension, WSS - does not deal with larger issues like cryptography or application sessions, global sign-out, or account linking. Some of these are more appropriately addressed in federation specifications like WS-Federation and Liberty. Some are addressed in other emerging standards efforts like WS-Secure Conversation and WS-Trust. Others will see light in SAML v2.0. Nevertheless, there is some very valuable work here by people who deeply understand the issues in distributed computing security, and elements of the specifications are relevant today. Which is good, because we've needed this for a long time. About the author Scott Morrison is director of Architecture at Layer 7 Technologies. Layer 7 provides technology for managing and coordinating Web services security and transaction policy across loosely coupled systems (more) Related Sites 7 Figure 1 7 Figure 2 7 Figure 3 7 Figure 4 7 Source Code -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

RE: [IP] Your people are growing increasingly worried about a 'police state.' For such an educated audience, (fwd from dave@farber.net)
by Tyler Durden 06 Aug '04

06 Aug '04

"So perhaps when Mr. Ashcroft erodes civil rights, you can make a valid claim that it introduces only a very slight risk of a police state, or is only the start of a trend. How much risk is enough? If events only presented a 1% chance of taking the path to a police state, would you want to tolerate it?" Hell, for me it doesn't even get that far. I'm not willing to take a DROP of police state risk in order to enable our State's bloodlust. If we hadn't been systematically f*cking over the Moslems for the last 50 years, this might be an academic argument worth debating. -TD >From: Eugen Leitl <eugen(a)leitl.org> >To: cypherpunks(a)al-qaeda.net >Subject: [IP] Your people are growing increasingly worried about a 'police >state.' For such an educated audience, (fwd from dave(a)farber.net) >Date: Fri, 6 Aug 2004 08:48:16 +0200 > >----- Forwarded message from David Farber <dave(a)farber.net> ----- > >From: David Farber <dave(a)farber.net> >Date: Thu, 5 Aug 2004 18:21:43 -0400 >To: Ip <ip(a)v2.listbox.com> >Subject: [IP] Your people are growing increasingly worried about a 'police >state.' For such an educated audience, >X-Mailer: Apple Mail (2.618) >Reply-To: dave(a)farber.net > > > >Begin forwarded message: > >From: Brad Templeton <btm(a)templetons.com> >Date: August 5, 2004 5:47:16 PM EDT >To: dave(a)farber.net >Cc: NMunro(a)nationaljournal.com >Subject: Re: [IP] Your people are growing increasingly worried about a >'police state.' For such an educated audience, > > >Subj: Your people are growing increasingly worried about a 'police > >state.' > >For such an educated audience, they seem to lack any sense of > >proportion, a sense of history or an > awareness of human nature. > > > >Indeed, as you cite, there are many police states and history is >littered with ones that have risen and fallen as well. > >Each time a police state rose, there were those who cried that a police >state was coming and were called paranoid. There were those who >actively assisted the police state in coming, seeking the security it >promised. There were those who assisted the police state in coming, >not wanting one, but feeling those who called out the warnings were >paranoid. There were those who said and did nothing. > >Free states are the abberation in the history of mankind. Police states >(for the level of technology of the day) the norm. > >So perhaps when Mr. Ashcroft erodes civil rights, you can make a valid >claim that it introduces only a very slight risk of a police state, or >is only the start of a trend. > >How much risk is enough? If events only presented a 1% chance of >taking the path to a police state, would you want to tolerate it? > >Would you find it acceptable to teeter on the edge of a police state, >because you were still on the free side of the line? > >Often, in the defence of free speech, we find ourselves defending people >expressing ideas we loathe. Nazis, pedophiles and other scum. We >do it not because we welcome a world full of their messages, but because >we know that if the Holocaust deniers can publish, we are _really, >really_ >sure that we can publish. It's not paranoia. > >------------------------------------- >You are subscribed as eugen(a)leitl.org >To manage your subscription, go to > http://v2.listbox.com/member/?listname=ip > >Archives at: http://www.interesting-people.org/archives/interesting-people/ > >----- End forwarded message ----- >-- >Eugen* Leitl <a href="http://leitl.org">leitl</a> >______________________________________________________________ >ICBM: 48.07078, 11.61144 http://www.leitl.org >8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE >http://moleculardevices.org http://nanomachines.net ><< attach3 >> _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx

1 0

Ready, Aim, HACK! (fwd from brian-slashdotnews@hyperreal.org)
by Eugen Leitl 06 Aug '04

06 Aug '04

----- Forwarded message from brian-slashdotnews(a)hyperreal.org -----

1 0

Don't smile for UK Big Brother's passport pix
by Sunder 06 Aug '04

06 Aug '04

http://www.theregister.co.uk/2004/08/06/passport_scanners/print.html Original URL: http://www.theregister.co.uk/2004/08/06/passport_scanners/ Home Office prohibits happy biometric passports By Lucy Sherriff (lucy.sherriff at theregister.co.uk) Published Friday 6th August 2004 10:08 GMT The Home Office says all new passport photographs must be of an unsmiling face with its gob firmly shut because open mouths can confuse facial recognition systems. <SNIP> ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :"Our enemies are innovative and resourceful, and so are we. /|\ \|/ :They never stop thinking about new ways to harm our country /\|/\ <--*-->:and our people, and neither do we." -G. W. Bush, 2004.08.05 \/|\/ /|\ : \|/ + v + : War is Peace, freedom is slavery, Bush is President. -------------------------------------------------------------------------

1 0

C# UAV
by Eugen Leitl 06 Aug '04

06 Aug '04

Kindly ignore absence of Hellfire periphery and (worse) the M$ marketing waffle below: http://research.microsoft.com/displayArticle.aspx?id=685 Unmanned Flight with Windows XP Embedded by Suzanne Ross Project Specs: On-board Technoland PC/104+ form factor 800MHz Crusoe computer USB to serial device provides 4 additional RS232 communication ports Microsoft Windows XP Embedded Kids who graduated from balsa wood bi-planes to radio-controlled airplanes will love what's coming around the corner. Faculty and students at Cornell University have built an unmanned airplane with its own on-board, embedded control system. The large-scale model plane flies by accessing coordinates from an off-the-shelf GPS unit. "The plane is capable of GPS guided flight, surveillance, and is very modular," said Kevin Kornegay, one of the faculty advisors for the project. Last year, the group won an Innovation Excellence Award from Microsoft Research to continue their previous work in designing an autopilot system for a large scale model aircraft. Schools around the globe received awards from the Microsoft Research University Relations program to enable them to conduct research in emerging technologies. "Our previous design represented a very early prototype for an autonomous aircraft. The autopilot system was extremely heavy, it lacked software functionality, but it was a strong version one," said Kornegay. This year the system is based on a PC/104 form factor Windows XP Embedded computer and has a variety of navigational sensors. "The software is written in C#, and is broken into four large applications. The autopilot software resides on the airplane and allows the plane to fly complete missions without any assistance from the ground. The plane also has wireless modems, which it uses to relay telemetry to the ground, and to allow for updated mission guidelines," explains Kornegay. The client software is written to display telemetry to the end user, for instance, where the plane is on a map or how fast it is traveling. The group developed two applications, one for a laptop or desktop computer, and one for a Pocket PC. Students monitored the airplane's flight from the Pocket PC application. The students entered the resulting prototype in the second annual Association for Unmanned Vehicle Systems (AUVSI) student competition. In 2003, they placed first in the contest. This year, however, they lost most of their equipment in a fire just before the competition. "We still gave our software demonstration though, allowing us to place 'best of teams that didn't fly," said Kornegay. The mission for the competition requires the plane to take off manually or autonomously, then autonomously navigate a course with five to ten GPS waypoints while using an onboard video or camera system to locate a series of man-made objects on the ground. Each team has 30 minutes of flight time to complete their mission. The planes will be judged on time, aircraft cost and weight, navigation accuracy, efficiency, safety and ability to locate the objects. Cornell Student Team Karl Schulze Andrew Abramson Brian Rogan Ron Hose Jonathon Kron Aaron Kimball Joe Sullivan Will Aber To test their flight control algorithms, the group used Microsoft Flight Simulator 2004, running the algorithms for hundreds of hours. They used a SIG Rascal aircraft with a 110" wingspan. The aircraft is 75 >" long and weighs thirteen pounds. The students modified the vehicle for unmanned flight by replacing the factory tail with a custom lifting tail, which moved the center of gravity further towards the rear of the plane. They also installed large in-wing flaps because the wings on the airframe had a heavier than designed for load. The in-wing flaps allowed a slower stall speed and improved takeoff and landings. The system runs off two 512 MB compact flash cards, which provides a storage system with no moving parts able to withstand up to 10,000 Gs. One compact flash card holds the operating system in a protected write mode, while the other stores a real-time flight log - a 'black box' that can be examined to diagnose problems, even if the vehicle crashes. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Bluetooth Security Cavities
by Sunder 06 Aug '04

06 Aug '04

http://www.wired.com/news/print/0,1294,64463,00.html Security Cavities Ail Bluetooth By Kim Zetter Story location: http://www.wired.com/news/privacy/0,1848,64463,00.html 02:00 AM Aug. 06, 2004 PT Serious flaws discovered in Bluetooth technology used in mobile phones can let an attacker remotely download contact information from victims' address books, read their calendar appointments or peruse text messages on their phones to conduct corporate espionage. An attacker could even plant phony text messages in a phone's memory, or turn the phone sitting in a victim's pocket or on a restaurant table top into a listening device to pick up private conversations in the phone's vicinity. Most types of attacks could be conducted without leaving a trace. Security professionals Adam Laurie and Martin Herfurt demonstrated the attacks last week at the Black Hat and DefCon security and hacker conferences in Las Vegas. Phone companies say the risk of this kind of attack is small, since the amount of time a victim would be vulnerable is minimal, and the attacker would have to be in proximity to the victim. But experiments, one using a common laptop and another using a prototype Bluetooth "rifle" that captured data from a mobile phone a mile away, have demonstrated that such attacks aren't so far-fetched. <SNIP> ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :"Our enemies are innovative and resourceful, and so are we. /|\ \|/ :They never stop thinking about new ways to harm our country /\|/\ <--*-->:and our people, and neither do we." -G. W. Bush, 2004.08.05 \/|\/ /|\ : \|/ + v + : War is Peace, freedom is slavery, Bush is President. -------------------------------------------------------------------------

1 0