SHARP Project
From OSDVwiki
The SHARP project is in the specification and prototyping phase of building a platform for devices that are part of a voting system, including but not limited to voting devices. Specification work is focused on providing definition and details for the prototyping efforts.
We've made available a pre-release build that's available both as source and as a live-CD demo system. It's the work-in-progress results of initial prototyping that's underway. After the initial phase of prototyping will continue in conjunction with a system-building competition, the IOTA Challenge, and is guided by the Open Toaster Architecture for integrity and assurance.
Contents |
[edit] Common Basis for Assurance
The main idea behind SHARP is that most types of electronic election equipment share a fairly simple set of requirements for the platform that they run on (and OS and common services implemented on the OS). Current SHARP efforts are oriented to proof of the concept that it is quite feasible to build a high-assurance platform that meets all of these requirements, and that is a sufficient platform for all of the components of OASES, the OSDV election system. An important goal is to show that such a platform can exist in order to "factor out" the majority of issues about system integrity, software assurance, verifiable operation, feasible software assessment, system certification, so forth -- all the common areas where many currently used systems are opaque or seemingly burdensome to assess, and as a result suffer from having no basis for trust.
Other OSDV projects, including some that can run in parallel, will test the SHARP system definition by using a SHARP prototype (one or more of the IOTA Competition entries) as the basis for a reference implementation of a component of an election system. For example, the SCAN project will combine SHARP with open source software for a paper ballot optical scanning function that is already available for public use. Each of these reference implementations should demonstrate not only that the SHARP system specification is feasible to implement, but also that SHARP-based systems are very feasible to assess for integrity, assurance, verifiability and so forth.
These system properties are essential as the basis for trust in any component of an election system composed of trustworthy devices that are high assurance and high integrity. Therefore, SHARP efforts are critical to demonstrate the feasibility of building trustworthy technology for elections.
[edit] The IOTA Challenge
Briefly stated, the challenge is to choose an open source operating system distribution, and strip it down to implement the minimal OS API needed to support the application software of an election system device. The result of the Challenge is intended to be a competitive selection of the most appropriate open-source operating system distribution to be used as the basis for SHARP - the common platform for the devices and systems that will comprise a complete set of open, next-generation election technology.
The requirements for the SHARP platform -- and hence the IOTA Challenge -- are driven by platform requirements for the various devices that comprise the OASES system, OSDV's election system. Each of these devices consists of a single application, and these applications all have essentially the same set of minimal requirements: simple file I/O, device I/O, and not much else. For simplicity in the Challenage, we assume that all of the OASES devices' application software will be written in one interpreted language (such as python or perl), so the required APIs and system services are limited to what is needed to support one interpreter running the application software.
In addition to constructing a minimal OS, the IOTA Challenge also includes implementation of some other aspects of the SHARP specification. For more information, see the announcement for the IOTA Challenge.
[edit] SHARP Specification
The first draft specification document for SHARP is in progress. Most of the important aspects of SHARP are informally described in the Open_Toaster_Architecture. The SHARP system architecture is documented as part of the OSDV_Technical_Architecture.
[edit] SHARP Prototype
The SHARP P1 prototype is now available for download.
[edit] Download
The download is in two forms. Firstly, a demonstration system is available as a a LiveCD system image that you can download as an ISO file, burn to a boot disk, and use the disk to run the demo system on your standard PC hardware. Secondly, the hardy and adventurous can download the source and build the ISO on your own. Why "adventurous?" Well, because this is a pre-release, your-on-your-own pre-Alpha, non-distribution (you get the point) that's being actively worked on (likely as you read this), until a stable release is ready. But that's no reason not to dare to some code wrangling!
[edit] Prototype and Demonstration
So just what is this prototype, and what does it demonstrate?
Well, the prototype represents large but relatively easy initial steps towards SHARP - a minimal OS along with other components (mainly a minimized python execution environment) that compriss a platform for the software of OASES, which is OSDV's voting system.
The P1 prototype consists of parts of standard Linux distribution, with other parts removed as part of "minimization" efforts. Minimization means, ideally, only include the OS code that you need in order to support a fixed set of application software. In the case of SHARP, the fixed set of application software a python environment and some python application software. In practice, complete minimization is very hard, but P1 shows some major steps forward in terms of eliminating drivers, network code, a lot of extraneous user-space software packages, and so on.
The demonstration system relies heavily on pvote as the application software. Pvote is the work of Ka-Ping Yee, who demonstrated that a substantially complete voting device could be implemented in less than 500 lines of python, running on a suitable platform of phython and Linux. (Actually, Ping demonstrated a whole lot more in his thesis work of which pvote software was only a part.)
Pvote thus comprises a great worked example of the application layer, the needs of which define how much "minimization" can be done. The P1 system is, then, pvote running on a partly minimized system
Pvote also provides a very nice demo. You pop in the boot disk containing the LiveCD image we've built, boot your PC hardware from the boot disk, and you get a voting machine that steps you through a sample ballot for you to vote.
What does this prove? A balloting device is one of the two most complex of the several components of real voting systems. So, we can demonstrate that a credible implementation of this component can be done as a small body of code (thanks to Ping) that can run on a platform that can be significantly minimized. If we can do that for a complicated component, then the other simpler ones are feasible as well.
[edit] Next Steps, and Help Wanted
Another purpose of the P1 prototype is to show what else needs to be done. Here is a short list of ongoing work, for which we're recruiting!
- Python application programming to enhance the pvote demo, especially with printer support, so that the demo supports paper ballots.
- System-build engineering, to reduce the amount of user-space code that the python interpreter needs to co-exist with.
- Python internals modification, to reduce the size of the python execution environment (libraries and the interpreter itself) and to implement Yee's specification of pthin, a simple subset of python that is sufficient for the needs of pvote.
- Kernel build engineering, to further eliminate more kernel code, while still preserving the structure of the kernel code and of the base source code distribution.
And there's more, but these are the main focuses of on-going work. There is room for many hands!
