David M Williams
Wednesday, 21 October 2009 19:36
Opinion and Analysis
Page 2 of 3
Well-intentioned Election Defense Alliance and Open Voting Consortium member, Jim March, made the database available to all through a Wiki site dubbed “
study Sequoia.”
March recognised the data as a Microsoft SQL Server database backup but, it seems, had no access to SQL Server, or any proficiency in the product.
He first claims Sequoia “vandalized the data as valid databases by stripping the MS-SQL header data off, assuming that would stop us cold.”
Elsewhere, March explicitly says the database “
has so far proven unreadable in any database.”
Yet, this is not the case. The file is a valid SQL Server backup and I was able to restore it with ease and without problem on my laptop.
Those with access to SQL Server 2005 or 2008 can easily repeat my steps.
First,
download and unzip the database.
Next, create a new database in SQL Server through the Management Studio console. It does not matter what the database is named. When creating the database, add a second .mdf file for rows as part of the primary filegroup.
Right-click on the database and choose Tasks / Restore / Database.
In the restore dialog set the source as a device (instead of a database) and browse to the unzipped .bak file. Tick the restore box in the backup set list.
Don’t click OK yet, or the restore will fail. Click the Options page in the left-hand pane. Check the option to overwrite the existing database (that is, the blank one you created.)
Note that there are three files being restored, with two being row data. Click the “...” icon on the second set of rows data and browse to the second .mdf file you added above when creating the database.
Now you can click OK and the database will restore successfully to your live SQL Server system were you can inspect its contents.
This restore proceeds without failure, and it is clear Sequoia have not ‘vandalized’ the binary backup file in any way.
Failing to achieve the same result himself, March proceeded to use Linux tools to attempt to make the database yield its secrets.
His primary tool was the command-line strings command which picks out sequences of readable text from a binary file, omitting anything which is not printable ASCII.
What March saw was sequences of SQL code, the industry standard structured query language used by database companies worldwide for manipulating and querying databases.
March makes several claims about this.
First, he says, the SQL code “appears to control the logical flow of the election.”
Second, he claims the existence of code within a database violates the United States Federal Election Commission’s regulations which ban the use of interpreted code in voting machines.
Specifically, this regulation is part of stringent security that demands the program cannot be modified while executing, which an interpreted language is able to do more readily than a compiled one.
Nevertheless, this regulation is not a regulation and is not a law. It comes from section 5.2.2 of the Election Assistance Commission (EAC)’s voluntary voting systems guidelines which states can choose to adopt.
Being a plain old SQL Server database it’s clear there was not going to be (say) shell scripts or Python or Perl programs being run, but I did expect to find stored procedures, a database mechanism which permits a measure of program code to be stored within the database and executed by the database server. Could these be the SQL code to which March referred, the code that controls the flow of the election while it is ongoing?
Well, in a nutshell, no.
