Comments on the IEEE Draft Standard
IEEE P1538/D4.0a, July 2003
The IEEE Voting Equipment Standard, Project 1583 [ http://grouper.ieee.org/groups/scc38/1583/"] began work in 2001, around the time it became apparent that the Federal Election Commission Voting System Standards effort was working towards the initial release of what was to become the 2002 FEC Voting System Standard. That standard had some serious shortcomings, although it was a distinct improvement over the 1990 FEC standard. I commented extensively on those standards, see:
In large part, the IEEE draft standard takes its structure and much of its content from the earlier FEC standards, and it contains extensive appendices that clearly document the descent of clauses of the IEEE standard from these earlier standards.
The IEEE draft 4.0a of July 2002 is a significant improvement over the FEC standard in several ways! While it still contains exemptions for Commercial Off-the-Shelf (COTS) components, these are considerably narrower exemptions than were allowed under the FEC standard. Section 5 of the IEEE draft begins by citing the Common Criteria and provides a taxonomy of security threats that is a good outline of the things that should be checked in a security audit of a voting system. Overall, these sections express a fairly secure model of voting system security.
That said, the good words on security are not reflected later, where, in Section 184.108.40.206, there is still a blanket exemption from source code examination for unmodified COTS software. Section 5.1.1 would justify extending such an exemption to products that were certified under the Common Criteria, and they would justify extending such an exemption to products that were used with defense against attack from that component (for example, by encrypting data before handing it to an untrusted COTS component). The status of the exemption for COTS software is further muddied by Section 6.6.2, where limited examination is permitted (quite rightly) for the purpose of determining whether the software has been modified and is indeed the version it is supposed to be.
The coding standards in 220.127.116.11 continue to preserve shortcomings from the old FEC standards! These standards have always confused the idea of code module with the idea of a subroutine or function. The terms module and modularity were used with no clear meaning in the 1960's, but as the field of software engineering began to mature in the 1960's, workers like David Parnas and Niklaus Wirth formalized a concept of module that is very similar to what is now known as a class or an object in the Object Oriented model. Languages like Modula, Ada (with packages) explicitly incorporated this approach to modularity, but as Parnas emphatically urged, and as Ritchie and Thompson demonstrated in their development of Unix, this approach to modular programming can be applied quite well in languages with no inherent modular structure (Fortran IV and C).
In these languages, a module is generally a collection of subroutines that operte together to implement an abstraction. For example, a module may implement an instance of a stack, with push and pop operations, or a module may implement the class of stacks, with operations to create a new stack and to push or pop on instances of such stacks. However it is done, it is good practice to store the entire text of a module in one source file, with (in languages that permit this) a separate header file that gives the interface definition for the module.
I belabor this point because the first half of section 18.104.22.168, up to part d, is entirely compatable with this definition of a module, but section e begins to confuse modules with subroutines (a term I use as a generic, to refer to functions, procedures, methods and other callable units of code), and sections f and g are clearly specific to subroutines!
Section 22.214.171.124 also, in a very off-the-cuff way, imposes an odd constraint! It demands that COTS software be tested with antivirus software. There are huge bodies of COTS software that this excludes, since antivirus software is only available to test software for Windows and MacOS systems! Show me antivirus software applicable to, for example, a distribution of OS-9, a fairly successful operating system for embedded systems. In fact, this requirement does not belong in section 126.96.36.199 at all!
Section 188.8.131.52 flatly bans the use of exception handlers, one of the greatest contributions of languages like Ada and Java to clear and well documented software development! While good exception handling tools are built in features of the Ada and Java languages, they have been added to C++ as an afterthought, and there are header files for C that provide decent exception handling for that language. Even without use of such header files, disciplined use of nonlocal GOTOs can be used for exception handling -- this is the primary justification for the GOTO statement of Pascal and the setjmp() and longjmp() functions in the standard C library. However exception handlers are used, they have the semantics of a nonlocal GOTO! They remain the one appropriate use of such GOTOs, the exception to Dijkstra's classic paper, "The GOTO Considered Harmful" (CACM Vol 11, No 3, March 1968) to the general prohibitions of the use of GOTOs can be traced.
Section 184.108.40.206 paragraph d may be intended to cover appropriate and inappropriate use of exception handlers, but it is extremely difficult to figure out what exactly this section is talking about. This confusion, continues in 220.127.116.11 paragraph c, where very similar and equally incomprehensible wording is used. The prohibition against the voting application taking any alternative path in response to operator intervention is also very odd, since, depending on how this is interpreted, it could be taken as a prohibition against the voting system taking any action in response to the actions of a human -- for the duration of the voting session, the voter is operating the machine and could be interpreted as the machine operator! This interpretation is nonsense, of course, since it ends up prohibiting the use of the voting system, but it leaves me wondering what interpretation was intended!
Section 18.104.22.168 contains a bit of motherhood and apple pie, a prohibition against 1-letter identifiers. This prohibition is probably a bit too tight. It has only one exception, the permission to use letters as loop index variables. I suspect the correct exception would be to permit use of 1-letter identifiers in any context where conventional mathematical usage was obvious. This would permit i and j as loop index variables, and also n and m, but not, for example, v (which does have two valid one-letter uses, voltage and velocity, each appropriate to a different context). Similarly, in a math routine taking logs (in a voting application?), it might well be very appropriate to use e as the name for the constant 2.7182818... and in a routine that plots a point on the screen, the names x and y are perfectly reasonable. In a routine to plot lines, it makes very good sense to plot from <x1,y1> to <x2,y2>; these differ in just one character, yet they're the right names, in the sense that any use of other names would generally detract from readability.
Sectin 6.6.1 (and the glossary) both define Firmware more narrowly than the voting system vendors have been using the term. For examplem, the I-Mark/Global/Diebold DRE system is a Windows application that runs on a PC compatible voting machine with a disk drive in it. The vendor documentation for this system, from the very beginning, has described its operating software, including Windows and their voting application, as firmware. It does not run from ROM, it runs from RAM and it is loaded in RAM from the disk. We need to be careful about this!
Section 22.214.171.124 offers a great improvement over earlier standards by allowing the use of widely accepted coding conventions for a particular language instead of the conventions documented in Section 6.6.6 (except that this appears to refer to Section 6.6.4, judging by the content). I cannot, however, find an acknowledgement of this alternative in Section 6.6.4, which is still written as a mandatory standard dictating specific and in fact overly restrictive rules that, for example, end up entirely forbidding use of exception handlers.
Posted July 27, 2003 at http://www.cs.uiowa.edu/~jones/voting/ieeed4a.html