Distributed Domain Implementation

The collusion analysis described in Section 6.5.1 noted the potential for vulnerabilities to emerge in the mCESG scheme should the Vendor domain in particular become corrupted and co-opt one other domain in the election authority to participate in an attack. Further, the Vendor domain is particularly capable of performing an internal denial of service attack, either during initiation, vote casting or the tallying phase of the mCESG scheme. Under such circumstances the mCESG election authority reverts to the properties of the flawed, monolithic architecture proposed for the CESG scheme.

The design of the election authority in the mCESG scheme is a deliberate attempt to model the infrastructure of elections in the UK, the context for which the scheme is designed. The scheme deliberately does not attempt to incorporate a security parameter in terms of the number of corrupt election authorities required to violate secrecy or the accuracy of tally, as is the approach of a number of cryptographic schemes [9, 71, 94]. Such an approach requires the availability of sufficient independent organisations to host the domains, whilst the mCESG scheme is designed to operate in parallel with the UK’s existing public election voting system. Each domain in the mCESG scheme has a corresponding organisation able to host it and each domain is labelled to indicate the appropriate host.

However, the Vendor domain of the election authority is the anomaly to the motivation described above, since the UK infrastructure does not prevent the possibility of multiple Vendor domains being implemented within the election authority. Such an approach might have two potential advantages if only a subset of functioning Vendor domains are required

to operate, as:

• multiple Vendor domains provides a parameter for the difficulty of performing a successful internal DoS attack from the Vendor domain in terms of the proportion of Vendors that must be corrupted in order to prevent correct voting credentials reaching a voter. An election organiser is able to utilise the services of sufficient k Vendor domains to prevent the DoS attack from successfully operating.

• an attacker would need to corrupt some sub-set of the Vendor domains in order to conduct vote stuffing attacks.

The first advantage of employing multiple Vendor domains may be obtained through the use of multiple identical Vendors. The set of Vendor domains must agree on a common key set for the generation of credentials, for example using a key agreement protocol [90]. The initiating domains of the election authority, Registration and Returning Officer, pass initia- tion values to allkVendor domains. Each Vendor computes the values required of them and returns these to the delivery domains, the Registration Officer and Electoral Commission. The problem of identifying correct output values if some domains differ is then equivalent to the Byzantine Generals problem [79].

To obtain the second advantage of employing multiple Vendors to prevent vote stuffing attacks, it is necessary to divide up the responsibility of Vendors between credgen-Vendors which compute credential values and publishers-Vendors which interact with the bulletin board to publish credentials. In this scenario, gateways forward voting credentials to all k credential generators. Each credential generator produces an ridvalue for the received vote and forwards the value to the publisher-Vendors. The publisher Vendors agree, again using Byzantine general techniques, when a credential has been received from sufficient credgen-Vendors to be published. Figure 7.1 illustrates the combination of two approaches described here for distributing the role of the Vendor domain.

Potentially, employing multiple domains might also be useful to prevent violations of vote secrecy, as distribution of Vendor domains reduce the potential for intelligent vote stuffing

VENDOR publish vendor1 publish vendor2 publish vendork ... credgen vendor1 credgen vendor2 credgen vendork ... RETURNING OFFICER REGISTRATION OFFICER ELECTORAL COMMISSION vidi vidi vidi

cidi cidi cidi

2nd ½pcini1st ½ridi

1st ½pcini2nd ½ridi

(a) Credential Generation

VENDOR DOMAIN publish vendor1 publish vendor2 publish vendork ... credgen vendor1 credgen vendor2 credgen vendork ...

Gateway1 Gateway2 ... Gatewayn

vid:pcin rid

(b) Vote Collection

Figure 7.1: Distributed Vendor domain architecture. The diagrams illustrate credential generation

and the collection of votes in the revised mCESG scheme. The single Vendor domain of the mCESG scheme is distributed into kcredgen-vendors and k publisher-vendors domains. During credential

generation, the initiating domains pass input values to all vendor domains, which in turn send outputs

to the delivery domains. In the event of a discrepency, the delivery domains then adopt a policy to

decide which received credentials to employ. During vote casting the gateways which collect votes,

forward voting values to each of thekcredgen-vendor domains, which in turn passridvalues to all of

thekpublisher-vendor domains. The publisher domains then employ Byzantine General strategies to

decide when sufficient credgen-vendors have announced receipt of a particular vote before publishing

attacks, from within the Vendor domain. However, such an adaptation would require the use of more complex cryptographic techniques such that no single Vendor domain obtains the complete set of voter credentials for any one voter. This might be achieved using secure multi-party computation techniques similar to that adopted in [85], for example, although an implication of this approach is that a voter may be required to assemble a voting credential from n > 2 rather than at present 2 components and as such may be impractical.