New Delhi: In September, the Supreme Court refused to entertain a public interest litigation that asked for an audit of the source code of the Election Commission’s electronic voting machines (EVMs) by an independent agency. While dismissing the case, the court said “there is no material on record to indicate the Election Commission is not fulfilling its mandate.”
But the jury is still out on whether the ECI is following its mandate.
In order to better understand the actual mechanics of that mandate, The Wire has, over the past month, analysed several publicly available documents and open sources of information on the machinery behind both the election process and the actual casting of ballots, i.e. the hardware, the software and the source code of EVMs.
The entire election machinery, we found, from the manufacturing of EVMs to the software loaded on to them, to the committee appointed to evaluate the software, the so-called third-party auditing this software and much more, is controlled by the Union government and the ECI has very little say.
The same holds true for the pre-election security measures put in place for the machines, such as first-level checking before they are sealed in a warehouse with 24×7 security. Or the random allocation of the machines to constituencies. No officer of the Election Commission is present during any of these exercises. Instead, only officials of the two manufacturers are present, as is the district collector. The Election Commission does not have a say in the allocation of machines to a state, an exercise entrusted once again to the two PSUs. The ECI, however, can track the location of the machines using the EVM Tracking Software. It is only at the second “randomisation” onwards that an election observer from Nirvachan Sadan is deputed.
What is ‘source code’?
The source code is a set of instructions in human readable language written by programmers. It provides the foundation for software and programme creation or basically everything that the machine does. The source code tells the machine how to function.
The petitioner’s contention before the Supreme Court was that the source code, or the brain of the machine, can, if altered, change the outcome of an election.
Data gathered from open sources and Right to Information responses indicate that the source code of the EVMs has never been audited, let alone revealed, either by the ECI, the manufacturers or even the experts appointed to audit it, the Technical Evaluation Committees (TECs) mandated by the ECI to audit EVM software. They have never been given the source code. Manned by professors from the premier Indian Institutes of Technology, all members are appointed by the government. The ECI has no role.
So how do the TECs carry out evaluations?
They go by what engineers working for the manufacturers say.
The crucial job of designing the source code and writing the software is carried out by a group of handpicked employees of the two public sector enterprises, Bharat Electronics Limited and Electronics Corporation of India Limited which also manufacture the EVMs. Both the PSUs are not under the control of the ECI. BEL is under the Ministry of Defence and ECIL reports to the Department of Atomic Energy.
The story of EVMs
“The software of EVMs is developed in house by a selected group of engineers at BEL and ECIL independently from each other. This select software development group of few engineers design and develop the source code,” says the Status Paper on EVMs. This software is tested by another set of employees in house before the TEC vets it.
The technical advice is given by the TEC. The Status Paper on EVMs does not spell out if the source code is shared with the TEC. It simply says, “Entire software is vetted by the TEC and sealed by them. Golden copy [the original copy, which is meaningless unless one knows the code for writing the copy] remains under sealed condition only. This ensures that the software has really been written as per the requirements laid down for its intended use only.”
The ECI does not even have access to the software that is loaded onto the EVMs. That right rests solely with the manufacturer and technical experts.
Former IIT Delhi professor, Subhashis Banerjee, says, “The entire thought process is amateurish and language like “golden copy” is non-standard. The whole approach reflects a lack of understanding of computer security and threat models.”
“Source code,” clarifies Banerjee, is the computer programme that runs in a computing device. It is a high-level representation programmed by developers which gets translated to a machine form (by a process called compiling) and executes on the CPU. Source code is the original version. In general, there is no way to establish that the programme that runs in a computer indeed corresponds to a given source code. Establishing it for multiple EVMs is an impossibility.
That there is not trojan or malware cannot be determined by “code in the EVM units can be read out by an approved external unit and the code so read may be compared with corresponding reference code to show that code is same as that in the reference units. The scope of comparison is only to ensure that there is no trojan or other malware for EVMs in use.”
Up until 2010, no one from the government, be it the ECI, the TEC, the manufacturers or third party, could actually extract the source code from the chips embedded in the machines. The ECI’s Status Paper on EVMs, Edition 4, of November 2021 clearly says the “exact original source code cannot be derived” from the older versions of EVMs (M1 and M2) manufactured till 2010. This is because the chips or micro controllers were imported and came pre-loaded. Any attempt to tinker with the hardware would make these one-time programmable chips redundant.
Way back in 1990 when the first evaluation was done, the TEC had recommended that source codes be made public. The TEC report of 1990 accessed under RTI says, “As a matter of abundant precaution, the instrument’s signature may be tested by the suppliers before a poll to check that they have not been replaced.”
This was repeated by the 2006 committee as well, which did not have access to the code either.
The TEC in fact recommended again and again that the veil of secrecy surrounding source codes should be lifted. In 2013, the TEC said that a facility be provided so the “code in the EVM units can be read out by an approved external unit and the code so read may be compared with corresponding reference code to show that code is same as that in the reference units. The scope of comparision is only to ensure that there is no trojan or other malware for EVMs in use.”
This report of 2013 was the last the government shared with activist Venkatesh Nayak via RTI. No report has been made public post 2013.
Nayak says, “It is not clear if the Election Commission of India officials are present at any stage be it manufacturing or software development or testing. I don’t think they even see the machines before they reach the warehouses.”
Too much secrecy?
India’s disproportionate secrecy is in marked contrast to other countries still using electronic voting devices.
Australian EVMs use Linux, an open-source software. Venezuela audits its source code before every election. The US keeps its source codes and hashes in a public repository and Germany and several other countries have got rid of electronic voting machines. In India, votaries of those fighting for transparency say if the secrecy surrounding source codes is lifted, it will be difficult for insiders to maliciously manipulate the software.
Emails and phone calls to officials of the ECI and spokesperson elicited no response. However, government officials told The Wire, “There is no reason why the source code information should be shared. People have gone to the Supreme Court again and again on this matter and their efforts have been rebuffed. The Election Commission has answered the court each time. These are nothing but motivated questions.”
Former CEC, Ashok Lavasa, says, “There have been a number of discussions on making source code public though the ECI goes by what the TEC says. The ECI prefers to be guided by academics like those at the TEC and go with their wisdom.”
Lavasa says the system should be foolproof and the intent should be to have a robust system in place. “There have been suggestions on counting all VVPAT slips even though this will be time consuming. However, trust and not speed should be of the essence. It’s the duty of the ECI to satisfy the maximum number of doubts by introducing a modicum of credibility, dialogue and transparency,” he adds.
The petitioner Sunil Ahya has been trying to access the source code since 2018 under RTI. In response, the Central Information Commissioner nudged the competent authority (the ECI) to examine if the source code details could be made public especially since this will create “public trust in the voting system”. The ECI stand was source codes are “intellectual property rights”. It has not responded to the CIC suggestion till date.
The ECI’s default mode has been opacity, including the response given to RTIs submitted to them. In 2019, Ahya moved the Supreme Court since the ECI would not share the source code with him. When the petition came up before the Chief Justice of India Ranjan Gogoi, the ECI told the court that a TEC of the ECI audits the software and any information is available with the TEC. But the TEC told Ahya and Nayak in separate RTI replies that audit is done by the Ministry of Electronics and Information Technology’s (MEITY’s) audit cell, called the Standardisation Testing and Quality Certification (STQC).
STQC in turn said this information is with the ECI. The RTI was transferred by STQC to the ECI under Rule 6 (3) of the RTI Act, which says that if information is not available with a particular arm of the government, the appeal should be transferred to the one that has the information.
The EVM status paper explains the role of the STQC as, “STQC tests and clears the EVMs before these are shipped out from BEL/ECIL”. The ECI status paper simply calls STQC “a third party testing agency” without mentioning its parent body, MEITY.
Inside an EVM
The only time when an EVM was officially opened and its mechanics examined was under orders of the Bombay high court in May 2017.
The court was hearing a plea regarding an alleged vote mismatch in the Maharashtra 2014 assembly poll filed by Congress candidate Abhay Chhajed from Pune’s Parvathi constituency. The Central Forensic Science Laboratory, Hyderabad was asked to examine, amongst other things, if the source code has been tampered with and if the hash values of these source codes were the same or different.
Chhajed says, “It was strange that when the machine reached CFSL, Hyderabad, under Y plus security there were at least 40 people waiting for its arrival, right from the Intelligence Bureau, CID and other Intelligence agencies as well as state police and several others. There was so much paranoia.”
The CFSL gave a clean chit but not before admitting they did not have the technical expertise to examine the machine.
Seeking additional time, the lab said, “The analysis of the Exhibits pertaining to EVM appear to be complex in nature as such reference is first of its kind in this laboratory which involves interaction with the concerned technologists and to understand the nature of functioning.” The report when it came, was signed by a ballistic expert and by a scientist of physics.
The experts said the microprocessor or chip was One Time Programmable, meaning once the programme is written into it, it cannot be modified. Or in other words, another software could not be written over it and it is therefore secure. The status paper echoes that position: “EVM used by the commission is a standalone non networked, one-time programmable machine.”
The CFSL report does not give details on the make of the machine they examined. It is also unclear which make of machine was used in the 2014 Maharashtra assembly poll but post 2013, it is the M3 type that is being manufactured by ECIL and BEL. While the M1 and M2 machines manufactured up to 2010 used OTP chips, the Status Paper on EVMs is silent about the technology used for the latest M3 machine chips or micro controllers.
Software for EVMs at factory itself
The EVM Status Paper says that software for the EVMs is written at the factory itself. “The software of the EVMs is developed in house by a selected group of engineers in BEL and ECIL independently from each other. This select software development group of few engineers design and develop the source code. Technological advancements now permit the writing of the machine code into the chips at PSU premises itself.”
Questions have been sent to TEC chief D.T. Sahani and member Rajat Moona. Sahani is yet to respond to emails and phone calls. Moona told The Wire to talk to Sahani as “he is heading the TEC”. The TEC was asked about how it evaluates the software, whether the source code has been ever shared with the committee and whether international standards are followed in auditing the source code.
The software is developed in-house by BEL and ECIL and both PSUs are independent of each other, the ECI manual says.
This means that half of the EVMs countrywide have one software and the other half have another. If the software is developed in-house, it means that it is either developed by employees of the PSU or it is outsourced to a third party. In other words, the software for the EVMs is developed and written by government employees working for the two PSUs.
But what about the chip or the microcontroller on which the unknown government employees write the software? There is no clarity on specific details here. The EVM status paper says, “Due to absence of requisite facilities to produce micro-controllers in India micro controllers are procured from manufacturers abroad.”
In other words, the chip used in the EVMs are imported by the two government-controlled PSUs but both are silent about which country or company they are importing EVM chips from. Repeated RTIs requests seeking this information have been rebuffed by the government.
In an RTI response to Venkatesh Nayak, BEL admitted that the chip they are using is from US-based NXP semiconductors. In addition, the NXP website says, this is not OTP. Instead, it has three different kinds of memory – SRAM, FLASH AND EEPROM. All three types can erase and rewrite data, or retain data bits in its memory or the memory can be electronically erased and rewritten. In other words, software that can be overwritten or reprogrammed cannot have the safeguards of being one time programmed.
In a paper on EVMs in 2010, a committee including Michigan University professor Alex J. Halderman had this to say with reference to expert committee members picked for EVMs: “This time the committee members were A.K. Agarwala and D.T. Shahani, with P.V. Indiresan serving as chair. All three were affiliated with IIT Delhi, but, like the first committee, none appear to have had prior computer security expertise. Again, the committee members did not have access to EVM source code and relied on presentations, demonstrations, and site visits with the manufacturers.
“In their report, the ECI has reiterated its view that the machines were “tamper-proof”.
In fact, Professor Indiresan is reported to have once said that questioning the ECI’s integrity is like asking Sita to undergo trial by fire.