Transcript, Ca. Senate Elections Committee Hearing - (minutes 150 - 180)

[Steve A Play]

Posted on Wednesday, April 05, 2006 - 02:39 pm:

If this transcript doesn't get you hot under the collar, read the background on it first.

To understand the context, though, of this transcript, you need to know what transpired first, outside of the hearing. Then decide for yourself what's really going on.

In this transcript, you'll read about the Black Box Voting "Hursti Hack" project, which took place in Leon County, Florida. That project revealed the existence of interpreted code, of memory card security vulnerabilities, and demonstrated the hacking of one of the most widely used U.S. election systems, one that counted 25 million votes in the 2004 general election.

Let's review exactly how the Hursti Hack came about, along what transpired immediately afterward. Compare what really happened with the testimony of the voting machine independent testing authorities.

1. A memory card in Volusia County, Florida in Nov. 2000 registered minus 16,022 votes for Al Gore. Just minutes after the minus votes appeared, every TV network in America erroneously called the 2000 presidential election for Bush. Timeline and excerpts from CBS report: http://www.blackboxvoting.org/bbv_chapter-13.pdf

According to internal Diebold memos the minus 16,022 votes in Volusia County were due to a replacement memory card.

Because the 2000 general election results in Volusia County were manipulated using a memory card, Black Box Voting went first to Volusia County after the Nov. 2004 election.

In Volusia County, we saw memory cards scattered around the central tabulator room and found voting machine results tapes in the trash. This prompted us to invest our time and money in finding out just how an election can be rigged using a memory card, and how voting machine results tape (poll tape) can be manipulated to match the GEMS tabulator.

2. We located a computer expert who was willing to have a look at the situation and tell us the truth about what he found.

It was not NASED, or the ITAs, but two ordinary citizens -- Kathleen Wynne and Bev Harris of Black Box Voting, who decided to contact Harri Hursti in Finland and bring him to the United States. It was the donations of thousands of ordinary citizens that underwrote the costs for research into how voting machines are actually corrupted, which have by now exceeded $100,000.

So two old women parked Hursti in a Holiday Inn, made a visit to the safe deposit box which holds the original seven CDs containing the Diebold files, which a regular person having nothing to do with NASED or any ITAs discovered on an unprotected Internet site. We handed Hursti the files and a laptop and told him to tell us what he sees.

It took Hursti less than 24 hours to find the interpreted code and the memory card security problem which he referred to as "the mother of all security holes." Compare this to the TEN YEARS these testing labs have had to examine multiple iterations of the Diebold optical scan firmware, which they have stated "passed" requirements over and over and over.

Together with another organization and Leon County, Florida's election supervisor Ion Sancho, who arranged for Hursti to test the voting system, Black Box Voting, we demonstrated how to hack the Diebold optical scan voting system.

A formal report was released by Black Box Voting on July 4, 2005.

3. In July and August 2005, Black Box Voting invested nearly $7,000 on postage and certified, return receipt requested mailings to make sure the formal report got into the hands of every secretary of state, NASED member and elections official in America.

4. The result: This transcript would have you believe that NASED happily accepted the information and acted on it promptly. Not so.

Ion Sancho was threatened by Diebold, and the vendor sent letters to elections officials all over the U.S. blaming Sancho for being "irresponsible." All three authorized vendors in Florida blackballed Sancho, the state of Florida pulled over $500,000 in HAVA funding from Leon County, and Diebold stated that if Sancho (and elected official) was replaced, they would honor their contract.

Diebold also continued its trashing of Black Box Voting, calling us conspiracy theorists, engaging in Internet smear campaigns through proxies. Diebold sent letters to secretaries of state and elections officials ridiculing the Hursti results, claiming in videotaped presentations that it is impossible to change votes on the memory card (Oct 2005), and lying about the need for password access. Public officials (i.e., the state of Georgia) sent bulletins to elections supervisors urging them to ignore the Hursti Report.

At no time did either NASED or any state official request additional testing. What triggered the testing in California was a formal request under California Elections Law Section 19002, submitted by Black Box Voting, requesting an evaluation of the memory card and the interpreted code, the AccuBasic. California law requires that this evaluation be performed expeditiously, California promised to do it, but dragged their feet. Only after numerous follow up letters, a visit to the secretary of state's office on Nov. 9, 2005, and a letter from our attorney did California conduct any testing.

5. The California testing did corroborate the Hursti results. However, the California secretary of state kept it a secret and only released it AFTER deciding to recertify Diebold.

6. The ITAs, when asked why they didn't flag the problems said they (a) weren't the ones assigned to evaluate it and (b) didn't know it was there.

Contrary to their claims, you cannot have interpreted code without AN INTERPRETER. The interpreter is a file in the firmware.

Wyle is lying.

Apparently ignoring the firmware source code for the interpreter, Wyle passed the system for several successive qualifications. You can only read this two ways: They either didn't understand what the source code module does (And to believe this, you have to explain why they never noticed a file that is NAMED as the interpreter.) Or, Wyle passed a system without having any understanding of one whole section of the source code does.

7. NASED members were sent certified copies of the Hursti Report by Black Box Voting in July 2005, but issued no directive until March 2006. This is not a "one month turnaround," as it is represented by Wyle. NASED (and the state of California) were dragged in kicking and screaming, and when the truth became undeniable after the courageous study done by David Wagner, David Jefferson et. al, which corroborated the work done by Black Box Voting's Hursti project, both California and NASED decided to make an exception to pass a system that doesn't meet the standards.

Then you have Systest saying that giving a waiver of the requirement was apparently appropriate because it didn't affect anything and was "safe."

Except that this violation of the standards is EXACTLY WHAT HURSTI USED TO HACK THE VOTING SYSTEM. It is almost certainly the exact method used to hack the memory cards in Volusia County in 2000, causing the networks to mis-call a presidential election. And this proven defect existed WITHOUT any mitigations as specified by NASED or the California report, counting 25 million votes in 30 states in Nov. 2004.

8. Now, let's look at the upcoming security report for the TSx machines in Emery County, Utah. That is going to blow a hole in the theory that the Windows CE system used in the touch-screens is "COTS." It isn't.

Just like the memory card, this unexamined program was used to penetrate the system. Just like the memory card, Wyle claims it didn't know it was supposed to evaluate it, a claim that is implausible.

And just like Ion Sancho, Emery County elections chief Bruce Funk is being punished. He came to work yesterday to find himself locked out of his own office -- without due process. Diebold has met with the county commissioners and other Utah officials to try to remove this ELECTED OFFICIAL from office.

According to this transcript, according to Wyle Laboratories, "the system works" and this has all "been dealt with."

TRANSCRIPT, CALIFORNIA SENATE ELECTIONS COMMITTEE HEARING - minutes 150-180 (of 200)

Senator Debra Bowen: No, but I think that's the reality of, again this is a jurisdiction size issue, certainly in the state senate we have an IT department but in my home operating system I'm married to my IT department, and I'm fortunate for that. A lot of people don't even have that level of IT support. So sometimes you do rely on the vendor which is just the reality of the way this works when it's this complicated.

So we're going to have a change, we're going to see different certifying, one of the things that's continued to concern me is whether there's a way to institutionalize a feedback loop that works better so that you have the benefit, maybe this is just totally a vendor responsibility and there's no role for testing with the EAC or NIST or anybody in it, but there doesn't seem to be any mechanism, any formal mechanism for a look at where problems have arisen in field conditions around the country to say, "all right, here's a pattern of things that happen with a particular system that has been certified. And here's a supplemental report. Or here are additional concerns, there's no way -- You can't do that without having the vendor ask, right?

Systest (Brian Phillips) Right, or find out about it after the fact such as a reports in the newspapers.

Senator Debra Bowen: But even if you get or read a report in the newspaper, unless the vendor calls you and says "Gee, we had this problem in Texas can you take a look?" There's nothing that involves you without vendor initiation, not even the secretary of state here could call you and say "Hey, we read about all this that stuff that went on in Texas, can you make sure that's not going to happen on June 6 in California." And you'll have to say "Ask the vendor to call me"

Wyle (Jim Neu): Well, the other thing you could say is "Send us a contract." We can do independent testing for anyone.

Senator Debra Bowen: All right. But I thought you said that the vendors are your clients.

Wyle (Jim Neu): They are. Only because they're the only ones so far who have come forward and offered us a contract.

Systest (Brian Phillips): We can certainly do certification for the state of California or any state.

Senator Debra Bowen: But how would you have access to the code?

Systest (Brian Phillips) If Vendor A wants to sell a product to the state of California they'd better give the state of California the code. I mean if California says, "You want to be certified in the state of California, here are our TDP requirements," if you will. I mean Pennsylvania, for instance, does that, I know. Dr. Shamos is well known, and he does most of the certification work and is a consultant for the state of Pennsylvania. And what we've found that there's a lot of duplication in what Pennsylvania's doing with what we do. It is not 100 percent, but there's a good overlap. Pennsylvania's talked to them about whether or not they can contract with our company to at least make use of some of the results and some of the testing for their own purposes. So that can happen, absolutely.

Senator Debra Bowen: Again, well it actually leads me to just, again, without having any judgment about it, I'm wanting to understand how this works. We had a little bit of discussion earlier about the creation of the 2002 standards. And I think Mr. Neu, you mentioned that Wyle had been active in helping set the standards, there's a working group that was ITAs, vendors, I don't know who else.

Wyle (Joe Hazeltine): NASED was on that committee, well NASED was involved, so was the Federal Election Commission, I believe the effort was funded by FEC as I recall.

Senator Debra Bowen: And vendors were also part of that, so that was what we would call a stakeholder-driven process?

Wyle (Joe Hazeltine): Well I would call it consensus based, which probably a large majority of all standards are consensus based.

Senator Debra Bowen: Okay. And how – what are the, if any, constraints then for -- How do the revolving door provisions work? I know you testified, Mr. Phillips, that you have strict conflict of interest standards that say that somebody who works for a vendor can't be either an employee or as I understand it, a contractor. What happens though, one of the issues that's gotten people concerned is that you see a revolving door, and really understandably between vendors and elections officials, because let's face it, you go to job opportunities in areas you know. But that means that you get a particular person who's familiar with a particular system. And how does that work in the testing with somebody who may have been involved in standards. Or do you think the standards are so broad based that it's not something we should worry about?

Wyle (Joe Hazeltine): Well we would encourage our employees to be involved in development or standards, they get a chance to meet the industry experts, they get a chance to understand the issues in more detail, understand exactly what the, why a particular requirement is there, I mean think that's a very good thing.

Senator Debra Bowen: I think my question's a little different, it's how do you deal with people who come in to your employ from somewhere else, where they may have been participating or working on the vendor side, now they come in to do the testing.

Systest (Brian Phillips): We actually, there are situations where, we actually haven't ourselves hired anybody but we've had several folks who used to work for vendors and who wanted to come work for Systest Labs. And we seriously look at hiring them, because they understand the voting industry. They understand a particular product. It gives them a leg up on anybody new coming into that particular industry. Perhaps I'm naïve, but I don't believe that they're going to come in and try to do a rubber stamp job on the vendor they used to work for, or perhaps, more often than not, do the opposite. Who knows how they may have left from that vendor. But what we really look for is knowledge in the industry, and that's very helpful and beneficial, and are they good, obviously softwaretest engineers or hardware test engineers. But they still have to sign our confidentiality, nondisclosure, conflict of interest agreements and we manage to that just like any company would.

Senator Debra Bowen: So you have enough different people who are looking at something so that you feel that, first you've got the basic assumption that most people are honest and honorable, which is my working assumption about the world, and there are some people who aren't, but you've got to start somewhere, but if you were only hiring one person to look at a system you might have a different level of concern about what that person's background was than if you have a number of people.

Systest (Brian Phillips): Yeah. We have, there's always a team of people working on it. They've been with the company either seven and a half years down to two years within our organization. There's a lot of training and orientation and our own certification process for our engineers to work on this, just so that they understand the terminology, the approach, our SOPs etc. so that -- because every test effort has to be the same, essentially, we're applying the same processes to every vendor, no vendor's getting some unfair treatment, either too much testing nor too little testing. We give them the same, depending on what their product is.

Wyle (Jim Neu): I think the checklist certainly serves to standardize that, secondly in our hardware testing it's a very small part of an operation embedded in a lot of hardware testing of lots of types, and it's supervised as those individuals do their work and their reports, they're reviewed by people up the chain who have an interest that's greater than just voting machines. So I would be very surprised if someone could come in and have a bias and not have it detected very quickly.

Systest (Brian Phillips): Similarly we have what we call our peer reviews, and it's something that, you know we get some feedback from the vendors, are peer reviews absolutely necessary, and they're actually very efficiently run. But they're to make sure that we're either doing a thorough enough job or we haven't gone over the other – you know, swung the pendulum too far the other way either.

Senator Debra Bowen: Let me go back to a couple of NASED and standards questions that I skipped over. One of the big issues that has been raised is over the issue of interpreted code and my read of the 2002 FEC standards is that interpreted code is prohibited. Is that in your testing standards and checklists, is that your understanding?

Systest (Brian Phillips): It is, it's part of our source code review, we'll look for those types of things to begin with. I'm not a code reviewer type person, but it is definitely one of the criteria.

Senator Debra Bowen: And, same?

Wyle (Jim Neu): Yeah, I think the same way. We do.

Senator Debra Bowen: So then the next question, interpreted code question comes up in conjunction with Diebold, where specifically where the assertion is that memory cards use interpreted code. So the question of the review of the memory cards again comes up, if they have interpreted code, and I actually don't think anyone disagrees that they do. And the review here by the Voting Systems Advisory Board found that they do in fact they do have interpreted code. How did we get a certification of a system that uses interpreted code?

Wyle (Joe Hazeltine): Well that's the election management system software and it would have been done by others, we didn't review it, it wasn't part of our contract.

Wyle (Jim Neu): Yeah, I t hink we have seen that allegation, the answer is it was not a part of the Wyle contract.

Systest (Brian Phillips): That was, and, I mean we're not trying to be evasive, but we've not ever reviewed any Diebold's systems so we don't know and we've not seen interpreted code in other systems, that I'm aware of.

Senator Debra Bowen: It's on the memory card as I understand it.

Systest (Brian Phillips): Right, but that was actually, Ciber was under contract to produce that. So I think what we're saying is--

Wyle (Joe Hazeltine): <(whispering) It's an election management system>

Senator Debra Bowen: Right. And Ciber's not here.

Systest (Brian Phillips): We can't speak to that unfortunately.

Senator Debra Bowen: But Wyle wouldn't be in the business of certifying a system that it knew to have – or recommending certification, you don't issue the number, that you knew had interpreted code.

Wyle (Jim Neu): That is correct. To whatever extent it was our responsibility to review that code, if we found interpreted code we would clearly not pass that code.

Senator Debra Bowen: So what happens if you are reviewing a voting system and it's passed and then it is discovered, for example, that it has interpreted code. How do the ITAs handle that?

Wyle (Jim Neu): Well, I'm assuming that if it's, that if it's discovered, it's discovered by the NSAED. N-A-S-E-D. NASED.

Senator Debra Bowen: No, actually it was just discovered by some elections activists, I think, and then it's presence--

Wyle (Joe Hazeltine): --Did they inform NASED so it could be looked at?

Senator Debra Bowen: Yes.-

Wyle (Joe Hazeltine): Has it been looked at?

Senator Debra Bowen: Yes.

Wyle (Joe Hazeltine): Then it sounds like the system is working.

Senator Debra Bowen: Well it's what led to this memo that I referred to from NASED that says that the memory cards should have been tested but were not.

Wyle (Joe Hazeltine): But as I read that, in December a problem was identified, they contacted the appropriate ITAs and the vendor in -- what's the date of this memo, Januaryish, you know, resolution,

Senator Debra Bowen: This memo is March 22.

Wyle (Joe Hazeltine): All right, March 22, so in a couple of months the problem was identified, addressed and a procedure put in place to prevent reoccurrence. That's a pretty good system.

Senator Debra Bowen: Well, actually, the conclusion of NASED is not that the system should not be certified, even though you're saying it wouldn't have been if you'd known. It's saying that "Yes, it has interpreted code but it's okay to use it anyway." That's NASED's--

Wyle (Jim Neu): Ma'am I'm worried that we may be mixing stories here. To my knowledge the issue that is addressed in this NASED bulletin was related to non-COTS software, which had been characterized as COTS and therefore hadn't been tested and was subsequently discovered to be non-COTS, and therefore needed to be tested and that's what relates to this, and that the issue of interpreted code is a different instance. I may be wrong on that, but I think what we'd have to do would be do some more research before we're be able to answer this.

Senator Debra Bowen: Well, I do think there are two separate issues, one is the COTS issue, but the other is the presence of interpreted code. And the result here in the Secretary of State's review finds that there is in fact interpreted code. In the security analysis of the Diebold AccuBasic interpreter.

Wyle (Jim Neu):

Senator Debra Bowen: It's 40 pages, if it were two it would be a whole lot easier for me to find exactly what I need. It says "AccuBasic" which is what 'wasn't interpreted', is an interpreter, the "AccuBasic Interpreter," the Accubasic on the memory card IS an interpreted code.

Wyle (Joe Hazeltine): Well you're reviewing something that I don’t have. But not only that, I mean, there is a system in place, where as you were talking about feedback and checks and balances. And if problems are found in systems which are fielded that weren't anticipated when they were actually being evaluated, the word gets back to NASED or the Election Assistance Commission, and I would imagine that a resolution like this will happen. There have been three or four other instances where the standards have actually been revised to account for new information which we've learned. This process as a software process, you know, evolves.

Senator Debra Bowen: But I don't understand, I mean you – I asked you whether you would pass a system that had interpreted code, you said "No,"

I'm telling you that we had a finding that there is interpreted code and that NASED "Well yes, there is interpreted code, but we can deal with it through a series of manual workarounds," and they adopted a series of user qualifications. But they did NOT say "Well these don't meet our standards, so they shouldn't be certified and we're going to revoke the number.

Wyle (Jim Neu): Again if I recall, this is, because I've seen a couple of other letters on this, this is where, we saw the letter here from NASED, we responded, as it says here and so did Ciber, and I believe it says here that both the California and the Ciber reports arrive at the same conclusion. Which, in fact if you go back and review the other correspondence I believe it was determined that in fact, this portion of that code – and I don't frankly know exactly why it's in a memory card and it became Ciber's responsibility – but it was determined that it was Ciber's responsibility, it was not Wyle's responsibility to test. And that's why the thing here says both California and Ciber reports resulted in the same conclusion.

Senator Debra Bowen: Actually, the California report does NOT arrive at that conclusion, that's NASED's version of what the California report does.

Wyle (Jim Neu): Unfortunately I don't know what the California report – I didn't see the California report.

Senator Debra Bowen: That is what NASED says, but that is NOT what the California report says.

Wyle (Jim Neu): But I believe between NASED, Wyle and Ciber it was in fact decided that this testing was Ciber's responsibility, Ciber then responded and that's why you have the result that you see here.

Senator Debra Bowen: Right, but I think the question is really more fundamental. We have a prohibition against interpreted code. We had a system that was certified, apparently it wasn't determined – wasn't discovered that it had interpreted code, that was subsequently discovered, instead of saying "Okay, that's prohibited by the FEC regulations, NASED said, "Well, here's the workarounds." Why is that appropriate?

Systest (Brian Phillips): Well, in all situations like this, what they're looking at is "What is the impact of having this interpreted code?" So they've got this particular situation, they've looked at the impact of having this interpreted code and felt that there was no impact to the safe use and accurate use of this system. That was their -- I'm not saying that was right or wrong, I'm just saying that that was their result.

Senator Debra Bowen: What's the point of having standards that prohibit interpreted code when if you don't discover it, when you find it you say, "Oh well, nevermind"?

Wyle (Jim Neu): That's an issue you would have to ask NASED.

Systest (Brian Phillips): But I mean I can tell you that, and I'm sure that you all see this all the time, there are times when waivers of standards are requested. And I'm not saying that's what happened here, but there are times when that happens. There may not be an actual solution perhaps, even technology allows in certain instances such as that. But just to say that you have to meet, you know, the standards have to be so rigid and concrete, I think that would be wrong, to very loosely with the standards, I think that would be wrong. You have to look at them on a case by case basis. We don't have that many systems out there that you can't look at them on a case by case basis.

Senator Debra Bowen: Well, let me just read you the one paragraph on interpreter code from the secretary of state's review here, that came out on February 14.

Wyle (Jim Neu): And that is not something we have here I think, is it?

Senator Debra Bowen: Well it's public, it's on the secretary of state's Web site.

Systest (Brian Phillips): No that's okay, we were just wondering if we could review it.

Senator Debra Bowen: It says, "Interpreter bugs lead to another more dangerous family of vulnerabilities. There is another category of more serious vulnerabilities we discovered that go well beyond what Mr. Hursti demonstrated (this is the flaw that somebody could swap out a memory card and change all of the tally results, not just the results for that machine) – "and yet requires no more access to a voting system than he had" (i.e., a memory card). "These vulnerabilities are consequences of bugs, 16 in all, in the implementation of the AccuBasic interpreter for the AccuBasic operating system, AVOS. These bugs would have no effect at all in the absence of deliberate tampering and would not be discovered by any amount of functionality testing, but they could allow an attacker to completely control the behavior of the AVOS. An attacker could change vote totals, modify reports, change the names of candidates, change the races being voted on, or insert his own code in the running firmware of the machine.


Systest (Brian Phillips): Does he state how? Because they talk about that the attacker could do this and that but I didn't hear anything that says HOW the attacker could do any of that.

Wyle (Joe Hazeltine): It sounds like they've got to physically have the memory card in their hands, how are they getting the memory card to start with?

Senator Debra Bowen: Have you ever watched what it looks like when memory cards are being moved around in an election?

Wyle (Jim Neu): The NASED report here at the bottom of the first page--

Wyle (Joe Hazeltine): So one -- you're talking about one memory card, you're not talking about all of them.

Senator Debra Bowen: But it only takes one, as Harri Hursti demonstrated, to change the entire tally, not the tally for that machine, to change the whole tally in the central system.

Wyle (Joe Hazeltine): I'm uncomfortable with this whole line of discussion without Diebold being involved in it. I think it's not really fair to have us to make comments or even discuss issues that they need to be involved with.

Senator Debra Bowen: Well I've invited them, certainly. But I think the question is what happens when there's been a certification and then an error is discovered and it's determined that the system wouldn't have qualified if we had known then what we know now, which is that there's interpreter code. And now you've got NASED, basically, choosing to ignore it's own requirements.

Wyle (Jim Neu): First let me say, you had asked a question, if Wyle had discovered interpretive code would we have passed it. The answer was no.

And it's clear from this, it says "It's clear that the memory card should have been tested but it was not." So I can assure you we did not find interpreted code because the card was not tested.

It subsequently determined that the card testing, for whatever reason, was apparently Ciber's responsibility. Unfortunately I do not know the details, but that is the case.

Now. separate, your question of if a subsequent failure is noted, what's the remedy, what's the feedback loop. I've certainly seen feedback loops that probably are quicker, within the military, in my time that I've spent there, but this is not a whole lot different. NASED was advised of a problem, did some research into it and they may have for whatever reason, agreed to accept something which is not in accordance with the rules kind of like Brian said, because they determined that it's okay. But in any case, they did within a fairly quick period of time develop procedures which would reduce the vulnerability. That is a feedback loop, and it appears that it has worked over a period of about a month.

Senator Debra Bowen: Well NASED didn't, all they did was take some of the work that was done here and adopt it. But they also, and let me see what you think of this statement, this is in the same paragraph where it talks about California and Ciber arriving at the same core conclusion, which is that a system using interpreted code on the memory card can be safely used -- and we'll set aside for the moment whether that's accurate.

"Physical security measures should be used to mitigate risks to the system" – I think we all agree that that's the case with every single voting system. You've got to have it, whether it's paper or plastic or mag card or whatever it is, you should have physical security systems.

"These security measures are practical procedures already in place in many elections jurisdictions." Certainly we have a long history of putting ballot security measures in place, but as somebody whogrew up in Illinois and watched elections in Cook County, I physically never saw any change in how paper ballots were handled but I suspect that there wasn't always absolute security with the paper ballots.

But this goes on to say "even without additional explicit security measures, corruption of the election results in an official election would require the active participation of the elections officials.

And that's certainly not what happened in the Hursti hack in Leon County, Florida. Ion Sancho was NOT cooperative, was NOT complicit in that, invited that, and yet here we have NASED saying that. Am I missing something?

Wyle (Joe Hazeltine): I don't have a copy of that, I'd like to review that before I comment.

Systest (Brian Phillips): That was page—

Senator Debra Bowen: It's in the NASED--

Wyle (Joe Hazeltine): --Not this, this reference to Florida.

Wyle (Jim Neu): To take that back to the reference to Florida, I don't know anything, we don't know anything about how the attack occurred in Florida, whether it was over the Internet, or whether it was a memory card that was inserted. So I don't know. It does say here, that, I'm assuming that this statement is correct, that corruption of the memory card with intent to change vote totals can only occur after the device has been set for election and before the first vote is cast.

Senator Debra Bowen: I don't think that's true either.

Wyle (Jim Neu): Then you have an issue with NASED.

Senator Debra Bowen: Yeah. I don't think that is true. That actually, and that's also been proven not to be the case in some places, where someone could set a memory card to have minus 100 votes for one candidate and plus 100 for another and it will look as though it is zero at the beginning of the day, and there's been no vote cast, but the system's already been changed.

Systest (Brian Phillips): But in testing, we look to see that memory cards are indeed at a null state. What we can't do is be there to test it the day of elections. That has to be a process that is done within the precinct. And so if somebody -- again, I think the point it that they're trying to make at the end of this second to last paragraph is that it requires someone to actually try to do something to it, it's not something that's inherent in the system, just by using it in a normal course of action, somebody's got to go and try to do this type of thing, whether it's before the votes are cast, during it or afterwards.

The answer to that, can you get them completely foolproof? I'm sure the vendors will be able to build you systems that are completely foolproof. They're not cost effective in any way, shape or form. So we've got to balance what's cost effective for the states – they only have so much money and so much budget -- to what it costs to build those things. So what we're trying to do is balance that. We're trying to make it as safe and secure as the market will allow. And unless the market is willing to put forth the money like the gaming industry does, unfortunately, I wish we did, you're going to have tradeoffs. And that's what NASED's saying here. That this particular thing is a tradeoff. They could go back and have them get rid of all that software but for now they're saying that they've evaluated it and they believe it's safe to use. That's their evaluation. There's nothing that the ITAs can do about it. We could all get together, stand up and say "This is absolutely wrong," and if they believe that they're right, they'll still, we don't have the opportunity to overrule them.

Senator Debra Bowen: I think this is a question for the ITAs for the following reason. You have a series of FEC standards that you test to. If you miss something, and we're all – it's going to happen. And then we come back and find it. You don't have any way to say "Hey. We withdraw our pass of the system because we have discovered that it does not meet the 33-page checklist that we have. Nobody's willing to stand up and say "Hey this doesn't meet the FEC standards," we can't use it. why?

Wyle (Jim Neu): There really isn't any way that that could happen, in that when we test the equipment we have it physically on site. When we finish and produce the report, the equipment goes away. So there is no mechanism by which we would then, we, Wyle would discover a subsequent shortcoming, because we're done testing. Now if we found something that was in our records that we failed to forward, we clearly would forward that, immediately, with a letter that explained that it was a result in testing and in the raw data we found this and overlooked it, or something to that effect. But the idea of us testing and producing a report and sending it forward, and the equipment going back to the manufacturer and then us subsequently discovering a defect only makes sense in the context that we perhaps misinterpreted some data and then discovered it. If we discovered that, we would notify NASED.

Senator Debra Bowen: It's not at all clear to me and I don't know how on earth we ever find this out -- why the memory card wasn't tested.

Systest (Brian Phillips): It could have been simply an oversight?

Senator Debra Bowen: It could have been, but, I guess, the question is, if there's an oversight in your test and you discover that you miss something, are you willing to just sit with that as your certification?

Systest (Brian Phillips): Oh no, they did go back to Ciber, and Ciber did--

Senator Debra Bowen: --Right, but Mr. Neu is saying he doesn't know why it went back to Ciber, and I will tell you that what got sent back to Ciber is extremely limited in its question. I was very surprised when I went back to look at the scope of the work.

Systest (Brian Phillips): But look, but I think something we need to keep in mind is that the ITAs, we don't qualify the system, we don't certify it, we don't give it numbers, so there's nothing we can take back. We issue a report of our results. And actually our reports, I believe, they don't even make a recommendation one way or the other, we do state whether they passed all of the requirements.

Senator Debra Bowen: I've never seen one of the reports, I'm at a handicap because I had assumed that there was a bottom line on the report that says "yes this system meets"--

Systest (Brian Phillips): Well we do state that it meets all of the requirements but it's not up to us to recommend certification or not, that's really up to NASED whether they want to pull back that qualification.

Senator Debra Bowen: But they're basing their action on your work. So who's responsible when we find something after a test is completed that--

Systest (Brian Phillips): Well if the testing organization should have found it yes, we're responsible, we should have found that. I mean, that's the case in all of the work that my company does, whether it's IV&V work or commercial testing or this.

# # # # #

PERMISSION TO REPRINT GRANTED. THESE TRANSCRIPTS WILL PROBABLY BECOME
A PUBLIC RECORD SOME DAY, BUT BECAUSE BLACK BOX VOTING INVESTED MANY
HOURS IN MAKING THIS TRANSCRIPT AVAILABLE, IF YOU REPRINT FROM THIS
EARLY VERSION, PLEASE ATTRIBUTE PROPERLY WITH A LINK TO
http://www.blackboxvoting.org . THANKS!

[nicknameless]

1. Where are these being posted on their site?

I haven't seen any updates to the page I was cross-posting transcript text from.
Where have they posted the 120 minutes - 180 minutes segments?

:shrug:

[nicknameless]

2. Found it.

http://www.bbvforums.org/forums/messages/1954/23133.html?1144282859

[Steve A Play]

3. Here's the links!

   0 - 120 http://www.bbvforums.org/forums/messages/1954/23075.html?1144083257
120 - 150 http://www.bbvforums.org/forums/messages/1954/23132.html?1144265704
150 - 180 http://www.bbvforums.org/forums/messages/1954/23133.html?1144282859

[kster]

4. kick.nt

[kster]

5. one more kick.nt