The Supreme Court (SC) verdict on Electronic Voting Machines is extremely disappointing and disheartening to see as a citizen of India who would’ve loved to see our existing election process improved to a point of common Indians’ trust.
Does the ECI have any empirical data to establish that a large number of Indians actually trust the EVMs fully?
It was reported that the court asked what was the source of data for the complainants to claim that a large number of Indians do not trust EVMs. It was also reported that the court dismissed the survey done by the very reputable Centre for the Study of Developing Societies (CSDS) as not trustworthy.
We would like to know if the court asked the Election Commission of India (ECI):
If they have any empirical data collected on the voting day, that includes number of voters who:
- Saw the correct symbol on the Voter Verifiable Paper Audit Trail (VVPAT) slip and saw the slip drop in the box,
- Saw the correct symbol on the VVPAT slip but did not see the slip drop in the box,
- Saw incorrect symbol on the VVPAT slip but saw the slip drop in the box,
- Saw neither the correct symbol on the VVPAT slip nor saw the slip drop in the box.
If ECI does not have such empirical data,
- On what basis does the ECI claim that a large number of Indians trust EVMs?
- The SC should have instead asked the ECI these questions and to prove beyond doubt that the petitioners’ claims were incorrect – after all it is in the interest of the Indian public at large that the claims be meritoriously considered and answered by the ECI and not the other way around!
The global gold standard of democratic voting is to ensure that the vote is cast as intended, recorded as cast and counted as recorded
In the context of Indian voting system,
- Ballot Unit (BU) light helps the voter to cast their vote as intended
- It is the Voter Verifiable Paper Audit Trail (VVPAT) slip and not the vote stored in the Control Unit (CU), that establishes the vote is recorded as cast.
- It is only logical that counting VVPAT slips will satisfy the “counted as recorded” criteria, counting the electronic votes in the CU does not count what was recorded and seen by the voter.
The problem with votes in CU is that the CU waits for the response from VVPAT after the slip is printed. In absence of any positive proof of / details on the programmed response from VVPAT and its interpretation and processing by the CU, there is more than reasonable doubt that the vote may be altered before it is stored by the CU. I have also explained this in detail in my chat with Karan Thapar
It is the data in the SLU, not just the alteration of program in the chip:
As per reports, the verdict talks about the Symbol Loading Unit (SLU) being sealed and preserved. However, there is no direction to reveal the data in the SLU in the process of verification to address complaints from the candidates. The data in the SLU can make the VVPAT program misbehave. Excluding the SLU and its data from the verification process and focusing only on the program in the microprocessor is the gravest of errors.
It is extremely unlikely that the program in the microprocessor will be tampered with. However, it is very possible that the data in the SLU will have extra bytes other than just the necessary images. SC seems to have completely missed / overlooked this possibility.
This data in the SLU will not be audited during verification and the proverbial elephant in the room is the data given to the already existing program; and no one has seen the elephant!
Data changes the behaviour of an already existing program. i.e. the program will take an already coded but different line of execution upon receiving different specific data input–note that the program does not need to change. Only changing the data is sufficient.
Programs are routinely written to respond to various types of data like date, speed, height, amount, text and other values.
For example, an interest calculation program in a bank reads “senior citizen” and adds half a percent extra interest while calculating interest amount. The same program calculates normal interest for other depositors. The program remains the same, its behaviour changes based on the data it receives.
In a modern car that has automatic lights, the program controlling the lights remains the same, but as soon as the light sensor feeds lower intensity value, the program switches the lights on. Until then, the same program keeps the lights off. The program does not change, the data makes the program behave differently.
The old adage “Garbage In Garbage Out” tells us what data can do a program’s output. The SC seems to have completely missed this aspect of electronic systems.
The glaring conflict of interest
The SC says the burnt memory will be verified by the engineers from the manufacturer. Isn’t there an obvious conflict of interest here?
If a patient’s death is suspected to be due to wrong medication, does the doctor who treated the patient conduct the autopsy or is it some other doctor? Since it is a standard practice to use an independent autopsy precisely to avoid conflict of interest, why is such blatant conflict of interest not being addressed in the case of EVMs?
Technically, how exactly will the engineers “examine” the burnt memory and “declare” if it is corrupt or not?
Does India face such a dearth of computer experts that an independent expert committee is so difficult to form that we must go back only to the manufacturer, disregarding the clear conflict of interest?
Checksum
One proven way of ensuring integrity of data is verifying the checksum.
For decades in Computer Science, the well-established idea of “checksum” is globally used to verify data integrity. Once a checksum is generated, a change of even a single byte changes the checksum. A checksum is an alphanumeric string calculated using a mathematical formula using every byte and its position in the data.
Checksums are widely used to ensure integrity of every important data item in every standard data repository. In the world of open-source codes, even an ordinary developer can see the checksum of the source they download. Developer then generates the checksum after downloading the data item to verify that the source and target are identical. Checksums are a public “metadata”, even for confidential data items.
Do the EVM manufacturers implement checksums? If yes, where are the checksums maintained? Is checksum for program code generated and stored in the non-erasable memory of the microprocessor? For an audit to happen, a value must be securely saved for future access. Such a previously stored value must then be cross verified with the value generated at the time of verification. If the values match, integrity will be said to be intact, if not, tampering can be proved.
Who will ensure that the two checksums actually match? Surely it cannot be the same engineers again. The SC does not seem to have directed the manufacturers to deposit the source values of checksums with a third-party constitutional body. In absence of such third-party oversight, the “certificate” about non-tampering unfortunately will be seen sceptically.
What about the code itself?
Besides, the entire focus seems to be on checking if the program has changed, without any consideration to the program code itself. The original program code itself may have execution branches that get activated upon reading certain data. This is eminently possible as we have seen in examples above, and no one will ever know about it since the data in the SLU is not asked to be revealed; nor is the source code being made open to public scrutiny.
What is the assurance that the program itself does not have undesirable, susceptible conditional code that will respond and alter values stored? Once again, we are asked to rely on the same people who design the system, write the code and manufacture the system. We are expected to overlook the conflict of interest, the possibility of collusion!
ECI fails to give a technically sound and logical reason for not making the code public
This report in The Hindu claims the SC said disclosing the source code will result in its misuse.
The ECI’s claim that the source code can be misused if made public, at this point supported by the court, is very difficult to comprehend given that the ECI itself makes the following claims:
- EVMs cannot be hacked no matter what
- EVM microprocessors are One Time Programmable (OTP) so no new program can be loaded in those
- Microprocessors of these machines have been already programmed several months ago and these machines are already in the field, under secure custody of the ECI
- The ECI is so confident about the secured custody that it has not bothered to introduce the electronic pairing process for the CU and VVPAT
If all the above are true, even if anyone wanted to, how can they “burn” a new program using the source code, even if the code was made public?
The new code can be burnt only in a new chip and then the new chip will have to be “soldered” into the “motherboard” hosting the microprocessor. Usually these chips are Surface Mounted Devices (SMD). A SMD device can be de-soldered and re-soldered using special purpose soldering machines. It is not a job done in a garage. This is a substantially non-trivial effort.
For the sake of argument, it will also have to mean that the EVMs can firstly be illegally accessed/accessed en-masse under the ECI’s nose, in order for any such potential new-code burning to be even theoretically possible. On one side ECI wants us to fully trust its security environments. That means no EVM can be stolen. So, no EVM can be re-programmed, even if source code was available.
What risk of misuse of source code are we perceiving here? We would like the court to help us understand, because in our considered opinion, the source code cannot be misused in any OTP chip once the chip is programmed, unless the chip itself is replaced. And such replacement is not possible given the impregnable ECI security.
If there is no satisfactory explanation of this perceived threat, we would like the source code to be made public, open to public scrutiny.
Making it open will also assuage all suspicions regarding the dialogue between the VVPAT and CU and bring in absolute transparency to the process – a fundamental aspect of almost a billion voters’ critical right to franchise.
When elections are getting slower, why does counting need be instantaneous?
The VVPAT slips are the only copy of the vote that has been viewed by the voter. Per the ECI guidelines Rule 56D (FAQ Q. No.2), the VVPAT slip has primacy over the electronic vote in the CU, since the VVPAT slip is seen by the voter and electronic vote is never seen by anyone.
As such, why are we wasting so much national time, effort and money in refusing to count the instrument that has primacy?
If the argument is of “speed”, our elections are getting slower every time. Now it takes 42 days. Voters from the first round locations must wait at least for 42 days for results, why can the voter of the last round not wait for 5 days? Why not think of the election as a 47 day schedule?
If the ECI were speeding up the matters and shortening the election period, the argument of speed could at least have some merit. In the current scenario, clearly their actions are inconsistent with their argument.
After all, who are the elections being conducted for, the people of India or the ECI?
Transparency is the cornerstone of trust. Healthy democracies are built of transparency, not on opacity.
Madhav Deshpande is a former CEO of Tulip Software and a former consultant to the Obama administration in the United States. He is one of India’s foremost experts on EVMs.
