I recently received an invitation from a politician, through a third party, to present the vulnerabilities of the automated election system (AES), in particular, the precinct count optical scan (PCOS), renamed vote counting machine (VCM). I was informed that the politician received an offer of sure win from an “operator.” The politician is concerned that the AES will be rigged in the 2016 elections to favor some candidates. The invitation remains open and I have no way of verifying the information.
I have also been asked what assurance the Commission on Elections (Comelec) can give the candidates and voters that the AES will be secured from tampering. Another question raised: How can Comelec assure stakeholders that the VCM executable code is generated from the source code reviewed by interested political parties and group and by SLI Global, the international certification entity engaged by Comelec?
One has to examine the processes Comelec undergoes as it prepares for the 2016 elections to detect and identify possible vulnerabilities in the procedures. There is also a need to examine the Election Management System (EMS) and the AES network (VCM, CCS, Central Server, Website, and Transparency Server) set up to understand where possible vulnerabilities lie and what actions can be taken to ensure that the potential vulnerabilities are remedied and, if not remedied, are not exploited.
I will address the second question raised in this installment, looking at the source code review and trusted build process.
The baseline source codes of the EMS, VCM, and CCS programs are being reviewed by a group of code reviewers representing interested political parties and groups and by SLI Global, the Comelec-engaged international certification entity. As soon as the customized source codes are available, the same will be subject to review. The customized source code presumably will include Philippine election rules and procedures.
A process called hash code generation will have to be done on both copies of the customized source codes after review. A hash code generated for a piece of source code ensures that the integrity of that piece of source code is protected. If a change in the source code is made and that source code is subjected to hash code generation, a different hash code will be generated. Separate sets of hash codes should be generated for the source codes reviewed by the local group and by SLI Global. The two sets of hash codes will have to be compared. A difference will indicate that the integrity of one or both copies of a piece of source code has been compromised. If there is no difference, the source codes reviewed and certified by SLI Global will go through the trusted build process.
The trusted build process involves conversion of the source codes into executable codes, the version that the machines “understand.” Interested parties may observe the process. Soon after the trusted build process is completed, hash codes of the executable code will also be generated.
In 2013, the trusted build process was not annotated and was not closely monitored. At the end of the process, a CD supposedly containing a copy of the source codes and the corresponding executable codes, was displayed before observers. Thereafter, the Comelec officials proceeded to the Bangko Sentral ng Pilipinas to deposit the CD. Perhaps the Comelec can take steps to ensure that each stage of the trusted build process is explained to observers. The observers, specially IT professionals, should also be allowed to inspect the output and contents of the CD.
It is also suggested that generation of the hash codes of the executable codes installed in the VCM and CCS be included in the initialization process of the machines and the generated hash codes be printed for display on the precinct doors. This will allow watchers to compare the published hash codes generated after the trusted build with the hash codes of the executable codes inside the machines.
The above measures may not be enough though. A real threat is still present. A malicious code designed to manipulate election results can be inserted at any point in the process by an insider who has been compromised. To prevent this from happening, it is suggested that a random digital forensic review of the SD Cards be done after the precinct and CCS configuration and other files are recorded in respective SD cards. This process should be done under close monitoring and open to the public/stakeholders for observation.
Let’s face IT. International Information Security Studies show that at least 65 percent of information security breaches are caused by or with the assistance of insiders. TransparentElections.org, through former Commissioner Gus Lagman, is of the opinion that the AES is secured from external attacks or hacking. But the AES, in particular, the VCM, can be manipulated by “operators” with the assistance of insiders.