I am a computer science & engg grad from IIT Kharagpur with over 30 years of experience in tech, software, embedded systems (mobile phones, STB, video streaming boxes). As a technocrat I understand that all digital systems can be vulnerable. Some of the vulnerability comes from the nature of digital and some from the nature of humans.
Recently we have all seen multiple instances of Indian EVMs mal-functioning with a common bias – press any button but the vote goes to BJP. This alerted me as the multiple common failure indicates something more than just hardware or software malfunction. It suggests a default failure path or a trojan/bug that fails in the same way given a set of input conditions.
When I started to look at the EVM details and read up on the design, hardware & software, I could see several points of vulnerabilities. I did not see any technical papers from the EC addressing those vulnerabilities. I did see some papers from experts in secure voting and global EVM tech challenging the EC’s claims that Indian EVMs were tamper-proof.
Are we being obstinate and hurting our democracy in the process? Could we not use the IT talent and experience in the country to test these EVMs thoroughly and squeeze out any scope for bugs or trojans? This made me write the following letter to the EC.
The letter has received lots of support from tech circles. One enthusiastic engineer, Lokesh Madan, has offered the following ways EVMs could be hacked/tampered/pre-biased. I am sharing the same with the hope that this will build consensus around the need to test EVMs better and/or disprove these hypothesis and therefore make our voting more secure.
Method 1 : The firmware is compromised
The firmware for the EVMs is developed by ECIL & BEL. The gold master is sent to the microcontroller chip manufacturers who burn it into the chip. The chip itself is not readable as per EC reports. This raises two questions:
a. What if the firmware was compromised at source ?
b. What if firmware was compromised at the chip manufacturer?
How do we verify this? Usually, tech cos track firmware by version, date and source control. Can we not publish the dates for firmware revision, change documentation and perhaps even source code so that the code can be compiled and the burnt firmware compared and verified? What do we stand to lose by this verification?
Method 2: Access via data connector
The Data connector compartment of EVM is never sealed and visible alongside the on off toggle switch. The data connector interface is RS232 and is used for printing of the EEPROM vote content and for diagnosis. So anyone can insert a virus! All the need is the right tool for hardware level operations.
The data connector is used for diagnosing internals, therefore when connected, the connector grants a highly trusted device with all privileges. The INTerupt is used for serial communication and if the (diagnostic capable) port changes the RAM memory / EEPROM memory with virus code and then does a JMP instruction to the virus start, the hacking is done.
All that we need is access to an EVM for few hours. Now think about the recent Pune municipal elections where the candidates and parties signed off on a list of EVM units but found out that the voting next day had different set of serial numbers etc. Clearly someone had access to the ‘strong’ rooms in Pune.
Method 3: Program the RTC with some malicious code
The RTC (Real time Clock) chip on Indian EVMs is a 8 pin chip with I2C serial port which is same port used by the EEPROM (primary) to store the vote counts. Standardised RTC chips come with SRAM and hence the RTC is vulnerable to code hiding in the SRAM. The RTC has its own battery power so that the code can wake up even when the EVM is powered down.
The trigger for RTC virus/code can be anything – 6 hours after the close of voting wake up and mess the vote count as per pre-programmed or last error state or any other trigger.
Method 4: Program the EEPROM with the virus / malicious code
The EEPROMs store the votes polled. 2 EEPROMs store 2 sets of data. However, at the time of the close of voting the EVM does NOT report a basic check-sum of the votes received for each candidate. Therefore if a malicious code changes the voting assignment, at the time of counting, this is unknown.
How can the vote assignment be changed? The EEPROMs have considerably more memory than that required to store 2 copies of results for 16 candidates. So virus can be hiding in the EEPROM perhaps not even accessible to the maintenance software (which resets the EEPROM data). The virus itself can be inserted via a maintenance tool, at the time of procurement or even via the serial connector.
Method 5: Setting selectable bias
Many folks have argued that given large number of EVMs it would take armies of people to indicate a bias. They argue that it would be impossible to keep such a secret.
Some common ways of introducing bias trigger covered in literature are:
a) Hide in plain sight : use a standard operation to overload the meaning. Operators would be following SOP but unknown to them the machine has triggered the virus. This could be in terms of an error/reset switch; long press; jammed state or any other standard operation which would not raise a suspicion.
b) Change of battery after close of voting – absolutely a standard operating procedure but can be overloaded to signal activation of virus. of course, long period between voting & counting will favor this approach.
So what kinds of testing can one do? What can a hackathon reveal?
Firstly, with the right tools – logic analyzer, interface listener, serial tools one can validate the EEPROM, RTC thru multiple techniques. Ideally the hackathon should provide the buggy systems in addition to the clean systems, so that testers can examine the difference in behavior between the two. As anyone familiar with debugging knows, it easier to find a cause and fix if the symptom of the bug is easily reproduced.
Secondly one can do some destructive testing. Operate the EVMs in unaccepted ways and see if it goes into the “biased” buggy mode. That itself should be enough to force a detailed scrutiny.
Thirdly log the traffic on the serial port, the interface bug (using a scope if possible) and validate against the specs.
Fourthly, if the maintenance tools are available, see if we can dump the RTC RAM, EEPROM and validate the entire memory dump.
There are many other ideas /approaches which involve 3rd party hardware etc. However, I will look to the wisdom of the crowd to provide some feedback, criticism, constructive ideas and even new possible ways. All the knowledge can only help make the EVMs more secure and our democracy stronger.
ps – even as I was writing this, comes the news that Hari Prasad, who in 2010 conclusively demonstrated that EVMs can be hacked has re-iterated that Indian EVMs are hackable and EC may be wrong in issuing a challenge. Read about his views here – click here..