interesting post here about Diebold source code

[AnIndependentTexan]

posted at commongroundcommonsense online forum by brossignol

http://www.commongroundcommonsense.org/index.php?showtopic=2927

I thought I would nip this in the bud because I know it is making rounds over at DU already.

First the story:
http://www.dailykos.com/story/2004/11/10/1172/9052

The allegation is that there is a line in the source code that looks like this:

#defineDESKEY((des_KEY8F2654hd4

What is alleged is that Diebold used a DES (Dat Encryption Standard) key to protect its program and that the DES keys are no longer used because the encryption was cracked in 1997.

First, I will talk about DES.

It is absolutely not true that DES is no longer used. What I will do is refer to DES, as they mean it as single-DES. single-DES encryption is based on a 64-bit key, but really only uses a 56-bit length key. This encryption is still in use and is widely used in situations where absolute hack-proof encryption is not necessary. So, it is a false statement that signle-DES is no longer used.

In 1997, the encryption was first cracked in 3 days. In 1998, it was again cracked in a contest in just over 22 hours using a network of more than 100,000 computers. This is required for the 250 billion+ calculations per second that are required to crack this level of encryption.

It is HIGHLY unlikely that anyone could go to this level to crack the encryption in Diebold's software.

Now, as for the programming, I am working on getting my hands on that source code, but it is entirely possible that the defineDESKEY was actually used to refer to the creation of a triple-DES encryption object.

THAT is the current standard for encryption and is completely un-hackable.

Again, this is one of those articles that will sound great to the lay person, but to those with real knowledge of the technology, it is more speculation - at best.
---------------------------------------------------------------------
brossignol the freeper is wrong, let me point out a more certafiable study


http://www.scoop.co.nz/mason/stories/HL0307/S00064.htm

These people and computer professionals showed in great detail how "simple" the code was cracked, and scoff at anyone intermittently trying to say its secure. They have experience 30 more plus years and counting.

Additional evidence on blackboxvoting.org shows the current code is not only not secure, it may even be less secure given the tampering they succeeded with in the state races already..
---------------------------------------------------------------------
What you talk about in code and encryption is totally FALSE>

If you have the software and knowledge of reverse engineering it can be

hacked quickly. Many of my softwares use this technology and 2 kids can

hack it quickly. If it was so great there would be no FRAUD
---------------------------------------------------------------------
Sure you COULD, but it would be so obvious that a child could detect it.

Let me give you an example.

First, we will dumb it down to 100 precincts rather than the thousands there really are.

We will also dumb it down to only 2 candidates and 2 voting machines in each precinct.

In the GEMS database, the way the tabulations are stored is by candidate, by voting machine and by precinct.

That means, for example, in precinct 1, on machine 1, there are two records. One for each candidate that hold the counts for each machine.

So, let's say, in our imaginary precinct, that there are 100,000 voters and, strangely enough, they are spread across the machines exactly evenly and across precinct evenly.

That means you can have a maximum of 1,000 voters in each precinct and 500 voters on each machine.

Now, what you would get is something like one record on one machine with a count of 260 and another record for the same machine of 240.

These records, in the database table view (the one the Bev Harris showed) would be in two separate lines, like a spreadsheet. Under that would be the rest of the records. And there would be 400 total records, one for each candidate on each machine in each precinct.

Now, if you had something that looked like this:

Precinct, Machine, Candidate, Count

1, 1, A, 260
1, 1, B, 240
1, 2, A, 300
1, 2, B, 200

That would cover one precinct. Let's imagine that the percentages were pretty close to this across all of the precincts.

In order to change the total result to favor candidate B, you would have to change FAR more than 5 records! You would have to go through and pretty much flip flop all of them.

Now, 400 records is a sizable number, but could be do-able manually.

But, consider that the real number of records would actually be more than 30,000. It would require a program to do this.

Please trust me on this one. I have the GEMS software and a real election database (past election) to test my theories on. I am not just some person making speculations, I really do know what I am talking about and have absolute data to back me up.
---------------------------------------------------------------------
The GEMS runs on w2k or xp w/out all the patches updates or firewalls

installed many ports are open emulating a terminal window is nothing and

easy to be there w/out being there. changing the data is very simple if you

know the code this is not rocket science. Lebold make a fortune off every unit

and license they sell! otherwise these machines would have performed to a

undetectable level.!
---------------------------------------------------------------------
In a complex s/w system like this, it is hard to believe there is only ONE define statement that is security related. There may be differerent security protocols used for different reasons--and hence, numerous constant/macro definitions. The data flow from client/server may be protected with one type of security std, while the password database may have another, and the local vote database yet another.

There can be nothing suspicious about that definition statement unless, when considered with the other src code that it affects, something obviously wrong has occurred in the code (e.g. it creates a secret backdoor password). If you have a suspicious define statement, it should take 5 minutes to grep the rest of the src code and find any code that is truly suspicious.

Anyone saying "Oh, look! I found a define statement that MIGHT coorelate to a 56-bit DES key!" does not have my confidence they are on the right track in discovering the signs of voter fraud.

If these diebold people conspired to election fraud, then my guess is they intentionally coded a security flaw that will not be very apparent by reading the src code. Rather, they probably setup a means to allow non-administrators (people without root passwords) to rewite or read the password file, or created a subtle buffer overflow condition that allows an intruder to dynamically run a code snippet that is not even compiled in the main src code, or so forth. They could have even hardcoded the word "Bush" or "Kerry" somehow to have self-adapting algorithms to simply make math errors when dealing with certain people (though this is unlikely since it leaves evidence of fraud).

There are a million ways to provide an intruder a way to affect the vote outcome, and I doubt you'll find a piece of code like this:

#ifdef INTRUDER_LOGGED_IN
screw_kerry();
#endif
---------------------------------------------------------------------
Well, my company would be reluctant to hand out source code to a proprietary program too. And making public source code to a program that MUST NOT be hacked would be very irresponsible.

As for the backdoor theory, you do understand that, in order to use a backdoor, the computer must 1) be connected to some sort of communication system, and 2) the software with the alleged backdoor must be able to accept incoming connections, right?

Can you explain that how it would work in the absence of those 2 requirements?

[aquart]

1. Which is the meaningful comment?

[Demit]

2. do you think you could indent, or put quotes around, parts of your post?

it's really difficult to tell who's talking. It's kind of hard to follow.

[htuttle]

3. Sigh -- does he know this has been out for over a year?

And has been the subject of numerous academic papers?

In any case, DESKEY is defined on line 204 of AccuTouch/Shared/RecordFile.h (the actual voting machine), and also in AccuTouch/BallotStation/Attic/RecordFile.h, which is the tabulator software, and in AVTSCE/TSElection/RecordFile.cpp, which I don't remember what it does.

It's used anywhere that the data is encrypted before it's sent to the memory flash cards.

And it's NOT that they used DES encryption that is the big problem (or DES3, for that matter, which they don't). The problem is that they hard-coded the pass key for encryption right into the source code. That means every machine has the same pass key.

But worse, the manner in which the pass key is included in the code causes it to be stored in a static C string, even inside the executable. That means all I gotta do is have one of the the compiled voting programs handy, and run a 'strings' type tool (like this one http://www.sysinternals.com/files/strings.zip) on the executable to print out all the static strings compiled in, including the encryption password. YOU DO NOT NEED THE SOURCE CODE TO EXTRACT THE PASSWORD.

k?

[Rjnerd]

4. In the early 90's

A machine was described that could be built from standard FPGA's, that would brute force single DES in under 12 hours. Would have cost under $300k when described. Nowadays, it would be a lot cheaper and faster. Yes, it takes a lot of conventional CPU's to do brute force attacks, but thats because they are general purpose - most of the chip will be idle/unused when doing the search. If the folks at NSA haven't had one for several decades, somebody isn't worth what we are paying them.

Actually, public source is just about mandatory if you want to do a hack resistant system. It needs to be examined by lots of eyes, to catch possible holes. Security thru obscurity doesn't work. A good cryptographic system has to be unbreakable in spite of knowing exactly what is going on inside the box.

In the case of the GEMS central tabulation system, they are often connected to communication lines, many places use a modem to transfer totals. So the server is open to incoming connections. But the penetration doesn't have to happen by phone. Just include a "virus" in one of the software updates, that rigs a particular election, then cleans up after itself. No need to worry about how long it would take to change the 400 records "manually", the program could handle changing thousands of them in just a few seconds.

As to inserting the backdoor, examination of the "escaped" diebold central tabulator sources, found a "magic number" that when set, caused the program to keep two disconnected tallies. So we have clear evidence that at least one back door was inserted.

As to adding others, the vendors routinely supply patches and updates. They are supposed to be certified, but there are lots of documented cases of the vendor service techs downloading known uncertified updates to machines, shortly before elections.

Since the owner of one of the companies is on record as "doing whatever it takes to deliver Ohio to Bush", and the second major supplier is run by his brother, and given the results in Ohio, it appears that he may have kept his promise.

[ClintonTyree]

5. I'm sure..............

the NSA could crack it in a matter of hours.......if that long.

[DireStrike]

6. Didn't Diebold claim to have changed its code?

Since this code was released, I thought they claimed to have "fixed" it...

[Hephaistos]

7. brossignol is an idiot

I guess his handle refers to the cryptographer in The Confusion bei Neal Stephenson. No genius here, though:

1) If it was triple-DES, there would be THREE F***ING KEYS, NOT ONE!

2) If the Diebold morons HARD-CODE the key, even the most modern algorithm wouldn't help...
- Source code can be leaked (see this case)
- The key can probably be extracted from the executable

Once the key is known, there may as well not be any encryption.

[Hephaistos]

8. Hrmmph - htuttle beat me to all of my clever points

by half an hour.

;-)

[htuttle]

10. Actually, I had a big head start

By about a year or so. I read through a copy of it back when it escaped. ;)

[Rjnerd]

9. Triple-DES

Is normally done with only two keys. Encrypt with key 1, encrypt the result with key 2, then encrypt again with key 1.

[Hephaistos]

11. Actually, to be backward compatible, you can do triple-DES

with one key - the result is the same as with single DES.

Originally, it was designed to use 3 keys, but many systems use only two, in the manner you describe. The security is considerably better than single DES, but somewhat less than if three keys were used.

Having said that, I am not really an expert in this, so it is possible that most systems now use two keys. The point of that, though, kind of eludes me - same work, less security.

[RyomaSakamoto]

12. "It is HIGHLY unlikely that anyone could go to this level to crack the enc

"It is HIGHLY unlikely that anyone could go to this level to crack the encryption in Diebold's software."

script kiddies do it all the time by double-clicking :evilgrin:

besides... if it's an inside job virtually nothing can keep you out.

and since this is on a windoze box there all kinds of doors wide-open to get in.

all of this adds up to why it must be OPEN-SOURCE ESPECIALLY if you want it to be secure.

the most secure OS in wide use today, even partially funded by the military is OpenBSD which is completely open-source.

while the vote is taking place these things shouldn't be plugged into the network... only after the polls close and they are uploading their counts after they been certified on the spot against the paper ballot, verifiable by the voter and optical scan, only once those two numbers agree - bbv and scanner - let the machine upload the results, or better yet have someone phone them in ;->

our vote is INSECURE, what are we FIGHTING for :shrug:

peace