• No results found

What are the trusted components of the target software, and for what purpose are they trusted?

4.2 Security Architecture Analysis

4.2.5 What are the trusted components of the target software, and for what purpose are they trusted?

mented?

In high assurance systems, “trusted components” are system components whose contamination or malicious takeover would place the system in an unrecoverable or untrustworthy state. While “trust” might sound like a desirable fea- ture, “trusted components” are undesirable elements of any system architecture, because they are components whose failure or compromise could cause the system to behave in unacceptable ways. Ideally, high assurance systems would incorporate sufficient redundancy and checks and balances to eliminate the need for trusted processes and compo- nents. In practice, the ideal of zero trusted components is rarely accomplished. Thus, a common practice in creating high assurance systems is to choose an architecture that minimizes and isolates trusted components within the system architecture.

We identified three trusted system components in the reviewed software.

• The Mixing Service is trusted to preserve the integrity of the election and the secrecy of voter’s ballots. It can violate all election requirements.

• The Voting Laptop is trusted to accurately record the voters’ vote and to preserve the anonymity of the voter. It can violate both integrity and secrecy requirements.

• The Key Generation Service is trusted to generate strong cryptographic keys and keep them secret.

We do not claim that these are the only trusted components, only that we identified these three as being trusted during our review. The important takeaway here is that if any of the components that we identify as trusted are compromised during election operations, the system could become vulnerable to dangerous exploits. In order to make the system safe in the face of these risks, extraordinary measures must be taken to ensure that trusted components are not compromised either before or during the election process.

The trusted nature of these components was not documented in the documentation provided to the review team. We see this omission as a significant documentation flaw that should be corrected.

4.2.5.1 Finding: The mixing service is trusted

Scytl makes the following claims regarding the security properties offered by the Pnyx.core ODBP 1.0 voting sys- tem [26,§1]:

• “Privacy of voters. . . impossible to correlate the votes to the identities of their respective voters.”

Similar claims are made in the ODBP project description [9,§11.3]. However, the mixing service can easily violate the claims above:

• The mixing service can alter ballots, violating accuracy.

• The mixing service can correlate votes with voter identities, violating privacy.

Alteration of ballots would be detectable with a manual count of voter choice records (assuming those records have not also been altered). Correlation of votes and voters, however, would not necessarily be detectable.

Therefore, the mixing service is a trusted component. Since it generates and certifies keys used by other compo- nents, the mixing service is also the root of trust for much of the system. The mixing service therefore constitutes a critical vulnerability in the security of the Pnyx.core ODBP 1.0 voting system.

Faulty software. The mixing service could violate accuracy or privacy if there is an error in its implementation. Action: The correctness of the mixing service software should be validated and certified.

Ideally, during the tallying process, the canvassing board would verify that the mixing service is running the certified software. Unfortunately, we are unaware of any reliable way to perform this verification. Nor did we validate the correctness of the mixing service software submitted for certification; that was beyond our resources.

Malicious software. Some possible threats to the mixing service include:

• insiders with authorized access to the mixing service (e.g., system administrators or operators),

• individuals (e.g., election workers) with authorized access to the physical room where the mixing service is stored or used, and

• Scytl employees, who might also belong to the other two categories.

These threats might be able to introduce malicious software on the mixing service by:

• embedding it in the mixing service source code,

• planting it during software installation, or

• inserting media into the mixing service machine (e.g., a USB dongle into an open USB slot, a CD-R into a CD drive, or a device into an open Firewire slot). The threat might have to deliberately load the malware from the media, or it might be possible to find and exploit an operating system vulnerability (e.g., in the filesystem) to automatically load the malware.

Unfortunately, we know of no practical way to reliably detect the presence of malicious software7. Consequently, the security of the mixing service depends upon procedural controls.

Action: The procedure that election officials will follow to secure the mixing service computer should be fully documented; partial documentation already exists in [9,§11.3]. We suggest that this procedure include controlling physical access to the mixing service computer. The procedure might also include physically blocking all USB, Firewire, and other ports.

Scytl informed us that they plan to configure the mixing service computer to disable autorun, which is a good step to include in this procedure.

Scytl initially informed us that they planned to install the mixing service software onto a computer, configure it as needed, and send the computer to Okaloosa County. This would introduce an additional risk that the Scytl employees 7Scytl initially suggested to us that malicious software on the computer could be detected by running a hash or checksum program on that computer. However, relying on a hash program for this purpose amounts to asking the computer to validate itself; if the computer is not trusted, then no answer from that computer can be trusted. By way of analogy, airport security could ask every traveler: “Are you a terrorist?”, but because a true terrorist would presumably answer “No,” such a question would be of limited value. In the same way, asking software “Are you malicious?” is of limited value, because malicious software could arrange to answer “No.”

who perform the task could introduce malicious software. However, the Florida Division of Elections subsequently informed us that FLDoE performed the installation and configuration themselves during their functional testing of the voting system, and they plan to deliver these pre-installed and configured systems to Okaloosa County before the election (pending certification). In addition, the FLDoE informed us that they used hashing to validate this installation step. We consider this good practice, as it eliminates one potential source of risk.

Action: For any future delivers of equipment, election officials should consider following the model established by FLDoE and install and configure the mixing service computer on their own.

Finally, we note that there exist cryptographic techniques that provide accuracy and privacy of a mix, without relying on fully trusted software. The mixing service could be redesigned to use mixes based on zero-knowledge proofs [18] or randomized partial checking [12]. Even with just a single mix server, these could help to prevent the mixing service from undetectably altering votes. Guaranteeing privacy is likely to require multiple mix servers, each using independent secrets (i.e., canvassing board private key shares) and perhaps independent software implementa- tions, which might be expensive.

4.2.5.2 Finding: The voting terminal is trusted

The Voting Client software must be trusted, for several purposes. First, we must rely upon it to accurately record the voter’s votes, in the form that the voter intended. We must rely upon it to present all contests that the voter is eligible to vote on, and to present the options accurately. Second, we must rely upon it to protect ballot secrecy. We must rely upon it to avoid leaking how the voter voted to unauthorized parties, whether by subliminal channels or direct communication or by inadvertent leakage.

It may seem obvious that the software on the voting terminal must be correct in order to ensure proper system operation, but there are high assurance techniques that can prevent and/or detect malicious manipulation in sensitive devices such as the voting terminal. In this case, we find that if malware were introduced onto the voting kiosk, it could violate the requirements for a secure election. Thus, the voting kiosk and voting client software is a trusted component and must be protected with physical security measures.

Additionally, because of the way that the voting client software is downloaded on election morning from the voting proxy, it will be difficult or impossible to confirm that the voting terminal software was, or was not, executing the proper software during the operational period. This aggravates the challenges of attaining high assurance while using trusted components.

4.2.5.3 Finding: The key generation service is trusted

As mentioned earlier in§3.3.1, the credential generation service generates the signature keys for each voter and stores them in an encrypted format. More specifically, it stores the signature key and certificate on the voting server in an encrypted format using a randomly chosen password and it stores the password in an encrypted format on the Credential Provisioning Service using the key of the polling worker.

This key generation software must be trusted. First, the security of the voting protocol relies on the generation process to use a secure random number generation process. Each voter must have a different key; if the generation process were to use a predictable random number generator to generate signature keys, then a malicious participant might be able to forge signatures on ballots and therefore modify or cast ballots at will. There is another attack which is more difficult to detect. The key generation process could use a small but random seed to generate all of the signature keys. It could do this using a secure random number generation process, thereby generating keys which appear to be correctly generated. However, an adversary who knows the small seed could also forge signatures on ballots for any of the voters. A similar attack could be carried out on the passwords used to encrypt the signature keys.