Hello world!
On Election Day 2007, I founded Glass Box Voting to build a demonstrably secure voting system. For years, the voting equipment marketplace has been occupied by companies whose lack of commitment to security and transparency has been widely criticized by security analysts, elections administrators and voting integrity activists. Also for years, I’ve been saying to myself, “this is a brilliant opportunity for an energetic team of smart, security minded folks to build a better system.” Eventually I got tired of waiting, and decided to build that team.
This being the first post, I will introduce myself.
By day, I’m a security consultant and software engineer with particular experience with:
- encryption algorithms and security protocols (choosing, using, implementing securely)
- cryptographic toolkits (developing, using, modifying, documenting)
- cryptographic hardware (design, certification, using)
- public key infrastructures (developing policies, implementing, integrating, building utilities, testing)
- government certification programs (FIPS 140-2, Common Criteria, PIV)
In the certification arena, I have worked primarily in the fields of FIPS 140-2 and Common Criteria certification wearing two different hats. In the FIPS 140-2 field, I work as a consultant to vendors, assisting with design, development. documentation, testing, and managing the evaluation process and interactions with the lab - my job is to assist them in whatever way I can to get them certified. For Common Criteria, conversely, I work for the federal government office that oversees and validates the work done by the evaluation labs - my jobs is to ensure that consistent and correct standards are applied in the course of evaluation. FIPS 140-2 and Common Criteria are very different evaluation schemes, to wit:
- FIPS 140-2
- states the rigid set of requirements that the implementation under test must conform to
- is overseen by a government group jointly controlled by the U.S. NIST and the Canada CSE
- Common Criteria
- permits developing security functional requirements to fit the capabilities of the target of evaluation
- is overseen nationally with international mutual recognition agreements
In addition to the accreditation work, I assist with development of security policies (particularly pertaining to public key infrastructure) and sometimes develop security system components by integrating available tools as needed for the requirements. I’ve been involved in technical baseline management for a corporate communications protocol, maintaining the standards, assisting the test lab in setting user acceptance requirements and developing interoperability test servers.
So I think I know a thing or two about how secure systems are developed, and how to demonstrate to others that those systems are secure. A paramount characteristic is coming up in the next post, on transparency.