contego - die post€¦ · we call the swiss online voting system, which is the platform developed...

ContegoLaboratories

Sunday, April 29, 12

Review of Electronic Voting Protocol Models and Proofs (Combined Final Report)

Author by

David Basin, Srd jan Čapkun

Recipient Post CH AG, Business Area E-Voting,

Hr. Denis Morel, Wankdorfallee 4, CH-3030 Berne

24.05.2017

24May,2017

2

ReviewofElectronicVotingProtocols,ModelsandProofs

ContegoLaboratories


Summary This report summarizes the results of our audit of models and proofs of Swiss Post/Scytl’s Electronic Voting Protocol. The audit and associated reporting was carried out over the period January – May 2017. This summary report comprises the two reports we wrote. The first report describes the results of the first audit and the five non-conformities that we identified with respect to the requirements of the Bundeskanzelei. These issues were addressed by Post/Scytl in a substantial revision to their submitted documents. Our second report was written as an addendum to the first. As explained in this report, the improvements made resolved all the previously documented non-conformities with respect to the cryptographic and symbolic proofs. In both reports, we identified additional (minor, non-blocking) issues and improvements. We summarize here our main conclusion: the proofs are conformant to requirements of the Bundeskanzlei (Chapter 5.1). This audit report was produced by the undersigned on May 24th, 2017.

24May,2017

9

AddendumtoReviewofElectronicVotingProtocols,ModelsandProofs

ContegoLaboratories


5. Conclusions

Giventheimprovementsmadetothedesign,proofdocuments,andproofscripts,weviewthesystem as conformant to the requirements of the Bundeskanzelei [BK, 5.1]. The proofsthemselvesarewelldoneandrepresentativeofstate-of-the-artverificationmethods.

Nevertheless,wehavelistedissues—bothinthisaddendumandtheoriginalreport—whichwebelieveshouldbeaddressed. Themostseriousofwhich isextending thedesigndocument tomakeallcontrolflowintheprotocolexplicitandexplicitlylinkingthemodeledprotocolstotheprotocol described in [OV], i.e., supporting the traceability of the [OV] protocol design in thecryptographicandsymbolicmodels.

Finally,wenotethatestablishinguniversalverifiabilityatsomelatertimewillbemorecomplex.Atthatpoint,ifnotbefore,therecommendationsmadehereforindividualverifiabilitywillneedtobeaddressed.

Responsibility

ThisauditreportwasproducedbytheundersignedonMay24th,2017.

__________________ ____________________ Prof.Dr.DavidBasin Prof.Dr.SrdjanCapkun

ContegoLaboratories


Addendum to Review of Electronic Voting Protocol Models and Proofs

Final Report (v1.0)

Authorby

DavidBasin,SrdjanČapkun



24.05.2017

24May,2017

2


ContegoLaboratories


TableofContents

1.ExecutiveSummary............................................................................................................3

2.ReceivedDocumentsandAuxiliaryDocuments..................................................................4

3.ObjectivesandEvaluationScope........................................................................................5

4.EvaluationandRecommendations......................................................................................6

5.Conclusions........................................................................................................................9

24May,2017

3


ContegoLaboratories


1.ExecutiveSummaryThis report is an addendum to our previous report “Review of Electronic Voting Protocols,Models and Proofs (v2.0)”, completed onApril 8th, 2017. This addendumaddresses the fivesourcesofnon-conformitysummarizedinSection6ofourpreviousreportandanalyzeswhetherthesystemisstillnon-conformanttotherequirementsoftheBundeskanzelei[BK,5.1].Wereceivedbothnewdesignandproofdocuments,whichwereviewed.Thedesigndocumentclarifiedwhich features of the systemare relevant for the review. Theproof documents andproof scripts are substantially improvedwith respect to their consistency, their explanationoftheabstractionsused,andtheproofsthemselves.Theimprovementshaveresolvedallthepreviouslydocumentednon-conformitieswithrespectto the cryptographic and symbolic proofs, as discussed in Section 4 of this report. We have,however,identifiedsomeresidualissues,whicharediscussedinthesamesection.

24May,2017

4


ContegoLaboratories


2.ReceivedDocumentsandAuxiliaryDocuments

Thedocumentsweused for the reviewwere theoriginaldocumentswe received for the firstreviewaswellasthefollowingupdateddocuments:

• [OV]OnlineVoting,ProtocolSpecifications,v4.8• [Crypto] Swiss Online Voting System, Cryptographic proofs of Individual Verifiability

Protocol(revision2.0,datedApril7th,2017)• [Symbolic] Analysis of Cast-as-Intended Verifiability and Ballot Privacy Properties for

Scytl’sSwissOn-lineVotingProtocolusingProVerif(v2,April7th,2017)• [ProVerifSources]Sourcefilescontainingthesymbolicmodel,includingtheformalization

oftheadversarycapabilitiesandsecurityproperties.Namely,thefollowing22files:o equiv_v6.7-Check.pve,equiv_v6.7-DHH.pve,equiv_v6.7-HDH.pve,equiv_v6.7-

HH.pve,equiv_v6.7-HHD.pve,spec_v4.3-Check.pve,spec_v4.3-noEq.pve,spec_v4.3.pve,spec_v8-Check.pve,spec_v8-noEq.pve,spec_v8.pve,study_v10.pve,study_v11-Check.pve,study_v11.pve,study_v12-Check.pve,study_v12.pve,study_v13-OBS_HH_k=1.pvstudy_v13-OBS_k=1-Check.pvstudy_v13-OBS_k=1.pvstudy_v13-REA-Check.pve,study_v13-REA.pve,study_v13.pve.

Wewillreferaswelltootherdocumentscitedinourpreviousreport,inparticular:• [BK]Technicalandadministrativerequirementsforelectronicvotecasting,Swiss

Bundeskanzelei,v.1.00.Whenthereisapossibleambiguityastowhichversionofadocumentisreferenced,weincludethedocument’sversionnumber.Forexample,[OV,v4.7]referstothedesigndocumentfromthepreviousreview.

24May,2017

5


ContegoLaboratories


3.ObjectivesandEvaluationScopeThis report is the result of a second evaluation whosemain objective is to evaluate the fivepreviouslyidentifiednon-conformities,withrespecttotheupdateddesignandproofs.BelowwerecallthenonconformitiesidentifiedinSection6ofourpreviousreport.NC1. Design documents should describe the complete design of the Swiss implementation.

These documents should explicitly describe all options (e.g., extended authentication,receipts,etc.)thatwillbeusedinthefinalsystem.Also,allcontrolflowshouldbemadeexplicitinthedesigndocuments,includinghowerrorsandexceptionalcasesarehandled.

NC2. Relationshipofmodelstothedesign.This should be made explicit so that the correspondence between the models and thedesign is clear. Keys, data, procedures, and protocols phases and steps should all beidenticallynamedacrossthedifferentdocuments:[OV],[Crypto],[Symbolic],and[ProverifSources].Whenmodelsomitormodifydetailsfromthedesign,thisshouldalsobestatedexplicitlyandjustified.

NC3. Providemissingdetailsinmodelsandproofs.Models and proofs should be provided for write-in votes (cryptographic and symbolic),Maurer’s Unified Proofs (cryptographic), and the use of short codes versus long codes(cryptographicandsymbolic).Theproofsshouldbeamendedtoreflectthedesignin[OV].

NC4. Gamehoppingproofs.These requireadditionaldetailsandminorchanges,e.g., the reduction fromGameA1 toA2,additionstoallowadaptiveattacks,andmoreinformationonhowtheNIZKproofsarehandled.

NC5. SymbolicProofs.The models should be extended to formalize the relationship between different keys.Moreover,missingcontrolflowdetails,whicharepresent inthedesign,shouldbeadded.In caseswhere such details are inadequately explained in the design documentation, forexample [OV, §4.4], then [OV] should also be extended. Additional explanation is alsorequiredonthemodelingofNIZKproofsandwhy it isadequateforthedifferentkindsofNIZKproofsactuallyusedinthedesign.

Wenotethatthefirsttwopointsconcernthedesignanditsrelationshiptothemodel,whereasthelastthreepointsaddresstheproofsthemselves.

24May,2017

6


ContegoLaboratories


4.EvaluationandRecommendationsa.EvaluationMethodologyWecarriedoutagaintheevaluationmethodologydescribed inouroriginalreport. Namely,tovalidatetheproofswecarriedouttwotypesofchecks,thefirstistherelationshipofthemodelto thedesignand the second is the correctnessof theproofs. Wealso checkedwhether thechanges introduced new non-conformities and, in particular, whether they resolve the mainissuesidentifiedinourpreviousreport.

b.EvaluationofPreviousNon-conformitiesandRecommendations Weevaluatebelowthefivenon-conformitiesinlightoftherevisionsNC1. DesigndocumentsshoulddescribethecompletedesignoftheSwissimplementation.

Status: We received a new design document that clarified the previously identifieddesignissues.Inparticular:

• The design document [OV, pg.8] clarifies that it is for a systemwherewrite-invotesarenotallowed.Thisresolvestheissuepresentin[OV,v4.7]thatwrite-invoteswerepartofthedesign,butnotreflectedinthemodel.

• Appendix C was added to [OV] describing the extended authentication optionused in the Canton Fribourg. In this extension, users must authenticatethemselves by answering a challenge question in addition to entering a votingkey.(Note:userauthenticationwasomittedfrombothmodels.)

• Additional details are provided on receipt validation, which differs betweencantons[OV,Section4.8].

Remainingissues:

• Althoughthereviseddocuments [OV]and[Crypto]nowusethesameorsimilarnotationandaremuchmore consistent than theypreviouslywere, eachof thedocumentsincludesaseparatedescriptionofthevotingprotocol.[OV]coversthewhole protocol specification, and [Crypto] provides more details on thecryptographicprimitivesbutcoversonlythesubsetofoperationsthataremainlyrelevantforthecast-as-intendedproperty.In[Crypto]Section1.1.itisstated“InthispaperwepresenttheprotocolofwhatwecalltheSwissOnlineVotingSystem,whichistheplatformdevelopedbySwissPostandScytlthat isused inseveralSwissCantons.”. [Crypto]doesnotrefertotheOnlineVotingProtocolSpecificationsV4.8[OV]documentthatis(accordingtoourunderstanding)themainprotocolspecificationdocument.We recommend create one document that merges these two descriptions toavoidanyconfusionandtoimprovereadability.

• [OV]and[Crypto]donotfullydescribethecontrolflowofdifferentsystems.WeillustratethisviaanexampleofProcessVote().Asstatedin[Crypto],thisfunction

24May,2017

7


ContegoLaboratories


first“verifies that there isnotalreadyavote inBBfor theVotingCard ID.”Thisrequiresfurtherelaboration.DoesthismeanthatProcessVote()wouldoutput0ifthesamefunctionwasalreadyinvokedinthepastforthatID?Orwoulditoutput0 only if the vote for this IDwas already confirmed by the user and sVCCwasalreadyproduced?Thisrelatestothequestionofwhetherthevotersareallowedtochangetheirvotes.Thisisapartofthefunctionalspecificationandshouldbemadeexplicitbothintheprotocoldescriptionandinthemodels.Aswenotedinouroriginalreport“allcontrolflowshouldbemadeexplicitinthedesigndocuments,includinghowerrorsandexceptionalcasesarehandled”.Westillrecommendthatthisisdone.

NC2. Relationshipofmodelstothedesign.Status:Therevisionresolvedthisnon-conformity.[Crypto,AppendixA]nowexplainstheabstractionsthataremadeinthemodelandtherelationshiptotheSwissOnlineVotingSystem, especially when it comes to entities, identities, keys and authenticationprocedures.However,therearestilltwoissuesthatwerecommendaddressing:

• Both[Crypto]and[Symbolic]shouldclearlyrefertoparticularsectionsin[OV]toclarify the correspondence to the design document. This is analogous to thetraceabilityofrequirementsinsystemdevelopment.

• Thenamingacrossdocuments ismuch improved,butmorecare is stillneeded.Herearesomerepresentativeexamples:

o CMtableinCreateRC[Symbolic]correspondstoCM_idin[Crypto]o Function AliceData in [Symbolic] corresponds to part of Register in

[Crypto]o Procedure CreateRC in [Symbolic] corresponds (roughly) to CreateCC in

[Crypto].o “Alice”in[Symbolic]correspondsto“voter”in[Crypto]o J1,...,jkforvotingchoicesin[Symbolic]versusv1,...,vtin[Crypto]o Voting server in [Symbolic] corresponds to Bulletin Board Manager in

[Crypto]o ProcessVoteCheckin[Symbolic]correspondstoProcessVotein[Crypto]

Again,consistentnamingisneededfordesigntraceability.

NC3. Providemissingdetailsinmodelsandproofs.Status:Wereceivednewproofdocuments forboth thecryptographic [Crypto]andthesymbolic[Symbolic]proofs. Asnotedbefore,write-invoteshavebeeneliminatedfromthe system design, and hence need no longer be part of themodel. Both documentswereupdatedtoexplainhowzero-knowledgeproofsaremodeled.Moreover,shortandlongchoicecodeswereaddedtobothmodelsandproofs.

24May,2017

8


ContegoLaboratories


NC4. Gamehoppingproofs.Status:GamehoopingproofsnowincludesufficientadditionaldetailsregardingtheuseofNIZKPsandproofsteps.Therevisionthereforeaddressedthenon-conformities.

NC5. SymbolicProofs.Status: The description of the symbolic models [Symbolic] and the symbolic modelsthemselves[ProVerifSources]weresubstantiallyimproved.Thisincludes:

• The model was expanded with relevant keys from [OV]. The model therebyincluded relevant voter keys, electoral board keys, Vote Cast Code keys, voterpassword,VerificationCardKeys,andBallotCastingKeys.

• BothlongVoteCastCodesandshortVoteCastCodesweremodeledaswastheirrelationship.

• The account of non-interactive zero knowledge proofs was simplified,explanationswereaddedexplainingtherelationshiptothealgorithmCreateVotein[OV],andadiscussionwasincludedoflimitationsstemmingfromthetoolused.

• Thechanges in [Symbolic]wereconsistentlymade inthenewProvVerifmodels,e.g., study_v13-REA.pve. Moreover, minor comments on the symbolic proof,madeintheoriginalreport,weretakenintoaccountintherevisedmodels.

c.SummaryofRecommendationsWesummarizebelowourmainrecommendations:

1. Werecommendacceptingthe improvementsasresolvingthepreviously identified fivenon-conformities.

2. In the case of the first two non-conformities,NC1 andNC2, there are four remainingissues,identifiedabove,thatwestillrecommendtobeaddressed.Theiressenceisthatasingle,unambiguous,descriptionofthee-votingprotocolsshouldbecreated,withanexplicit control flow. This description should be clearly used as the source of thecryptographicandsymbolicmodels,andtherelationshipbetweentheseartifactsshouldbe documented in a way that removes all ambiguity about how the models werederived,theabstractionsthatwereused,andthepartsofthedesignthatwereomittedfrom themodels. Given the current state of themodels and proofs,we do not viewthese as blocking issues that should delay the system’s certification. However, we dorecommendthattheyareneverthelessaddressed.

24May,2017

9


ContegoLaboratories


5. Conclusions

Giventheimprovementsmadetothedesign,proofdocuments,andproofscripts,weviewthesystem as conformant to the requirements of the Bundeskanzelei [BK, 5.1]. The proofsthemselvesarewelldoneandrepresentativeofstate-of-the-artverificationmethods.

Nevertheless,wehavelistedissues—bothinthisaddendumandtheoriginalreport—whichwebelieveshouldbeaddressed. Themostseriousofwhich isextending thedesigndocument tomakeallcontrolflowintheprotocolexplicitandexplicitlylinkingthemodeledprotocolstotheprotocol described in [OV], i.e., supporting the traceability of the [OV] protocol design in thecryptographicandsymbolicmodels.

Finally,wenotethatestablishinguniversalverifiabilityatsomelatertimewillbemorecomplex.Atthatpoint,ifnotbefore,therecommendationsmadehereforindividualverifiabilitywillneedtobeaddressed.

Responsibility

ThisauditreportwasproducedbytheundersignedonMay24th,2017.

__________________ ____________________ Prof.Dr.DavidBasin Prof.Dr.SrdjanCapkun

ContegoLaboratories


Review of Electronic Voting Protocol Models and Proofs Final Report (v2.0)

Authorby

DavidBasin,SrdjanČapkun



08.04.2017

8April,2017

2

ReviewofElectronicVotingProtocols,ModelsandProofs(v2.0)

ContegoLaboratories


TableofContents

1.ExecutiveSummary............................................................................................................3

2.ReceivedDocumentsandAuxiliaryDocuments..................................................................4

3.ObjectivesandEvaluationScope........................................................................................5

4.EvaluationoftheCryptographicModelandProofs.............................................................7

5.EvaluationoftheSymbolicModelandProofs....................................................................10

6.SummaryofMainRecommendations................................................................................15

7.Appendix...........................................................................................................................16

8.Responsibility....................................................................................................................18

8April,2017

3


ContegoLaboratories


1.ExecutiveSummaryWe reviewed the symbolic and cryptographic proofs of the Swiss Electronic Voting Protocols,focusing primarily onwhether the protocols ensure individual verifiability.We summarize ourfindingshere.Both the cryptographic and symbolic proofswere constructedusingwell-establishedmethodsand tools, widely accepted within the cryptographic and verification communities. Thecryptographicproofsusethegamehoppingapproach,buildingoncomputationalassumptions.Thesymbolicproofsfollowthesymbolicapproachtomodelingandverificationandarecheckedusing the ProVerif tool, which is a state-of-the-art model-checking tool. The proofs wereconstructedbyexpertsinthesedomains.Althoughthemodelsandproofsarewelldone,wehave identifiedsome issuesthatshouldbeaddressedbeforetheycanbefullyaccepted.First,theprotocolmodelsshouldbeamendedsothatthecorrespondencebetweenthedesign(documents[OV]and[Tools])andtheabstractionsused in themodels ismade clear. Currently, the proof documents do not refer to the designdocumentsandalsousedifferentterminologythanthose inthedesigndocuments.Second, inboththecryptographicandsymbolicmodels,somerelevantsteps(theuseofshortcodes,write-invotes,voterauthentication)havebeenomitted.Specifically,shortcodesshouldbeincludedinthemodels(andresultingproofs)sincetheyareatthecoreofcast-as-intendedverifiabilityandtherefore of individual verifiability. Third, in terms of the proofs themselves: some extensionsandadditionaldetails shouldbeadded to thecryptographicproofs.This includes refininghowNoninteractive Zero Knowledge proofs are handled, refining the hops between games,formalizingtherelationshipbetweendifferentkeys,addingmissingcontrolflowdetails,etc.Acomplicationwefacedisthatthedesigndocumentswereceiveddonotcontainthecompletedetailshowthedesignwillbecustomized forSwisselections.Forexample, it isunclearwhichparticularoptions(e.g.,extendedauthentication,receipts,etc.)willbeusedinthefinalsystem.Some of this can be inferred from public sources [PostWeb], but it is essential to have onedocument describing the design of the Swiss Online Voting System with all the options andchoicesworkedout.Finally,therearediscrepanciesinthesecuritypropertiesconsideredacrossdifferentdocuments.The cryptographic proof document proves cast-as-intended verifiability and vote privacy; thesymbolic proof document also proves tallied-as-cast verifiability. Federal requirements [BK]require theproofof individualverifiability,which fromthedefinitiongiven in the requirementincludescast-as-intendedverifiability,butnotrecorded-as-cast.However,someliterature[E2E]aswellasthePostwebsiteonelectronicvoting[PostWeb]defineindividualverifiabilityascast-as-intended and recorded-as-cast; the latter is neither covered by the cryptographic nor thesymbolicproof.Wehavetakenthenarrowinterpretationoftheproperties(justcast-as-intendedverifiability), inthisreport. Nevertheless,thesediscrepanciesshouldberesolvedtodeterminewhetherthescopeoftheproofsshouldbeextendedtoincluderecorded-as-cast.

8April,2017

4


ContegoLaboratories


2.ReceivedDocumentsandAuxiliaryDocuments

For the review,we receivedanumberofdocuments fromScytlandSwissPost. We list thembelowalongwiththeabbreviationswewillreferencethemby.Themaindesigndocumentsthatwereceivedare:

• [OV]OnlineVoting,ProtocolSpecifications,v4.7• [Tools]OnlineVoting,CryptographicToolsSpecification,v1.1

Theverificationdocumentsthatwereceivedare:

• [Crypto]SwissOnlineVotingProtocol(revision1.2,datedFeb.22nd,2017)• [Symbolic] Analysis of Cast-as-Intended Verifiability and Ballot Privacy Properties for

Scytl’sSwissOn-lineVotingProtocolusingProVerif(Noversion,datedNov.30th,2016)• [ProVerifSources]Sourcefilescontainingthesymbolicmodel,includingtheformalization

oftheadversarycapabilitiesandsecurityproperties.Namely:o spec_v4.3-noEq.pve, spec_v4.3-Check.pve, equiv_v6.7-DHH.pve, equiv_v6.7-

HH.pve, equiv_v6.7-HDD.pve, spec_v8-Check.pve, spec_v8-noEq.pve,spec_v8.pve,spec_v4.3.pve,equiv_v6.7-Check.pve

AdditionaldocumentsexplicitlyprovidedbyScytlandPostare:

• [OVW]CryptoProofsDoc,ExtendedInformation,v0.1• [Arch]OnlineVoting,ArchitectureOverview,v2.0• OnlineVotingSolution(Scytlslides,noversionnumber)• OnlineVoting:VoterPortal,SecureDataManager,andAdministratorPortal(allv6)• eVotingSecurityStateoftheArtPresentationforKPMG(Scytlslides)

Additionaldocuments,inthepublicdomain,whichwereferenceinourevaluation,are:

• [BK]Technicalandadministrativerequirementsforelectronicvotecasting,SwissBundeskanzelei,v.1.00

• [PostWeb]Papersandslidespublicallyavailableonlineathttps://www.post.ch/en/business/a-z-of-subjects/industry-solutions/swiss-post-e-voting

• [E2E]End-to-EndVerifiability,Benaloh,Rivest,Ryan,Stark,Teague,Vora,OverseasVoteFoundation’sEnd-to-EndVerifiableInternetVoting:SpecificationandFeasibilityAssessmentStudy(E2EVIVProject),http://research.microsoft.com/en-us/um/people/benaloh/papers/e2e-primer.pdf

8April,2017

5


ContegoLaboratories


3.ObjectivesandEvaluationScope

To clarify the scope of this evaluation, we depict the relevant entities above as well as theirrelationships.Ourevaluationstartswiththedesign,describedprimarilybythedesigndocuments[OV]and[Tools].Outofscopeisthesystem’simplementationandwhethertheimplementationconformstothegivendesign.The main security property we evaluate is individual verifiability. To determine whether thesystem has this property, as required by [BK, §5.1], we must evaluate two proofs: acryptographic proof and a symbolic proof, which are made with respect to a cryptographicmodelandasymbolicmodelofthedesign,respectively.Ineachcase,thisevaluationrequires:

• Checkingthat themodel isanadequatecryptographic (respectivelysymbolic)modelofthe design. Namely, that the protocol modeled appropriately abstracts the votingprotocol described in the design document. For the cryptographicmodel, this is theprotocol described by the algorithms in [Crypto]. For the symbolicmodel, this is theprotocol described by the [Proverif Sources] we received, which are explained in the[Symbolic]paper.

• Checkingthatthepropertiesverifiedcryptographically(orsymbolically)aresufficienttoensureindividualverifiability.Thisalsoincludescheckingthatthetrustassumptions(i.e.,adversarymodel)correspondtothosein[BK],i.e.,thetrustassumptionsarenostrongerthanthosein[BK],orequivalentlytheadversaryisatleastasstrongastheonein[BK].

• Verifying the correctness of the proofs themselves. In the case of the cryptographicproof,thisamountstocheckingamathematicalargument.Forthesymbolicproofs,wecheckthemusingProVerif,andrelyonthesoundnessofthismodelchecker.

8April,2017

6


ContegoLaboratories


Wehavestructuredourevaluationalongthetasksjustdescribed.RemarksonIndividualVerifiabilityThemainpropertyrelevantforthisreviewisindividualverifiability.Forindividualverifiabilitytohold, [BK, §4.1] requires that the adversarial actions of changing or misappropriating a votebeforeitsregistration,orcastingavoteonbehalfofavoterwillbedetectedwithhighlikelihood.Astrongerproperty,end-to-end (alsoknownasuniversal)verifiability is typicallybrokendownintothreeparts[E2E]:1. Cast-as-intended: voters make their selections and, at the time of vote casting, can getconvincingevidencethattheirencryptedvotesaccuratelyreflecttheirchoices;2.Recorded-as-cast:votersor theirdesigneescancheck that theirencryptedvoteshavebeencorrectlyincluded,byfindingexactlytheencryptedvaluetheycastonapubliclistofencryptedcastvotes;and3. Tallied-as-recorded: any member of the public can check that all the published encryptedvotesarecorrectlyincludedinthetally,withoutknowinghowanyindividualvoted.Individualverifiabilityisoftenunderstoodas(1)and(2),whereas(3)isadditionallyrequiredforthestrongerpropertyofuniversalverifiability. Notethat individualverifiabilityasrequiredby[BK, §4.1] is entailed by (1), provided voters make appropriate checks. Note too that thedocumentProcesstosecure&verifiableonlinevoting[PostWeb]providesthesamebreakdownas[E2E]: the voting system achieves the cast-as-intended property by using return codes thatvoterscancheckagainsttheirvotingcardsanditachievesrecorded-as-castbyprovidingreceiptsthat voters can check against a public bulletin board. Note that the document describing thecryptographic proofs [Crypto] explicitly focuses on cast-as-intended only and does not coverrecorded-as-cast.Thesituation issimilar for [Symbolic],althoughadditionalpropertiesarealsoestablished,asexplainedinSection5.Hence,ourprimaryfocusisjustonthecast-as-intendedproperty.Notethatvotesecrecyisnotaformalrequirementforindividualverifiability.Itisonlyrequiredin [BK, §4.3] if one wishes to verify the complete abstract model with the intent of showinguniversalverifiability.Hencethispropertyisnotinthescopeofourevaluation.RemarkonReportStructure:MandatoryVersusRecommendedImprovementsAll improvements that we consider to be mandatory for the system to be compliant to therequirementsof[BK,5.1]arelistedinSection6,whichsummarizesourmainrecommendations.The other chapters and the appendix provide both additional information on the issuesidentifiedaswellasother issuesandrecommendationsofamoreminor (i.e.,non-mandatory)nature.

8April,2017

7


ContegoLaboratories


4.EvaluationoftheCryptographicModelandProofsa.MethodologyThe report [Crypto] describes cryptographic protocols for electronic voting, and providescryptographic proofs for the given protocols. The cryptographic proofs follow the well-establishedmethodology of proving the correctness of protocols schemes using game hopingproofs in the computationalmodel. Thismethodology is appropriate for the typeofprotocolsthatareanalyzed.Validatingtheproofsrequirestwotypesofchecks,thefirstistherelationshiptothedesignandthesecondisthecorrectnessoftheproofs.Wenowconsidereachoftheseinturn.b.EvaluationoftheModel(relationshiptothedesign)Overall, the presented model covers most relevant aspects of the voting protocol design,specifically those relevant for the cast-as-intended verifiability. We do, however, identify thefollowingissues.Mainissues:

1. Relationship to the design. The relationship between themodel (protocol description)presented in the cryptographic analysis document [Crypto] and the specificationdocument[OV]isnotexplicitlygiven.The[Crypto]documentdoesnotrefertothemaindesigndocument[OV]andthekeys,data,andproceduresinthe[Crypto]documentdonotgenerallycorrespondtothoseinthe[OV]document.Onlyacoarsecorrespondencebetween different steps in [OV] and [Crypto] has been provided in [OVW]. Mostimportantly, there is noexplanation in the [Crypto]document aboutwhich steps, keysanddataareabstractedawayandwhy.

2. The use of short codes versus long codes. In [Crypto], themodel and the proofs onlyconsider the system using long return codes (called Choice Codes in [OV]). The [OV]document,however,explainstheprocedureforthegenerationandverificationofshortchoice codes (sCC in [OV]), which substantially differs from what is described in the[Crypto]. Short string comparisonprotocols arenon-trivial and shouldbehandledwithcare.This is importantsincecast-as-intendedisguaranteedbytheuseofchoicecodes.The analysis of the use of short choice codes therefore should be included in thecryptographicproofsandnothandledinformallyasitiscurrentlydonein[Crypto,§5.2].Similar to the case of Choice Codes, the confirmation codes and finalization codes(namedBallotCastKeyandVoteCastCodein[OV])aregenerateddifferentlyin[OV]thanasdescribedin[Crypto].Theproofsshouldbeamendedtoreflectthedesignin[OV].

3. Write-invotes.The[OV]documentdescribestheprocedureforwrite-invotes.Ifwrite-invoteswillbeused,thenthe[Crypto]reportshouldbeextendedtoincludethis.Itisourunderstanding from discussions with project participants that the system should beevaluatedwithoutconsideringtheoptionofwrite-invotes,hencewedonotlistthisasasourceofnon-conformanceinSection6.

8April,2017

8


ContegoLaboratories


4. NIZKProofs.ThecryptographicproofsdescribeindividualNoninteractiveZeroKnowledge(NIZK)proofswhilethecryptographictoolspecificationdocument[Tools]usesMaurer’sUnified Proofs and the instantiations of NIZK proofs within Maurer’s scheme. Thereshouldbeastatementabouttherelationshipbetweenthetwointhe[Crypto]report.Itisclear thatMaurer’s protocol is a generalization, but the report should showhow theirproofsalsocarryovertoMaurer’sgeneralizationandinstantiationsin[Tools].

Additionalissues:

5. CryptographicKeys.Thereareanumberofkeyslistedinthe[OV]document:VotingCardSigning and Authentication keys, Verification Card ID Key, Vote Cast Code Signer Key,VoteCardSecretKey,ChoiceCodesPublicKey,etc.The[Crypto]documentlistsasmallerset of keys without providing anymapping to the [OV] document and using differentterminology and notation (voters voting keys, global audit key, etc.).Wewere able toestablishthismappingandfoundthissimplificationtobeacceptableforprovingcast-as-intended.However,thereshouldbejustificationforthissimplificationinthereport.Wenotethatthissimplificationmightnotcarryoverwhenotherpropertiesareproven.Wefurther recommend unifying the notations in the [OV] and [Crypto] documents tosupporttraceability.

6. Scope.[PostWeb]describesreceiptsthatwillbeusedbythevoterstocheckiftheirvotewas recorded-as-cast. As is, [Crypto] does not model receipts and does not proverecorded-as-cast. This is clearly stated in the [Crypto] document. It thereforedoesnotprove individual verifiability according to the definition from [E2E] and [PostWeb], butcanbeunderstoodasfulfillingtheindividualverifiabilityrequirementsgivenin[BK,§4.1],where individual verifiability is defined differently. If recorded-as-cast is required, thenthereportshouldbeextendedtoprovethis.

7. Privacy. [Crypto] provides a proof of vote privacy. However, it does not modelauthenticationaspectsasdescribedin[OV].Itinsteadaddressestheseinformallyin5.1.In[Crypto],itissimplyassumedthatsk_idisgiventotheclientbythevoter.However,in[OV] there is a more complex process through which sk_id (VCSK in [OV]) iscommunicatedtotheclient.Althoughwefindthistobesufficientforcast-as-intended,forotherproperties,includingtheprivacyproperty,whichisanalyzedinthereport,thisisnot sufficient. Ideally, theuser’sauthentication to the serverand thedeliveryof thecredentials to theclientshouldbeapartof themodelandproofs.The [OV]documentfurtherdescribesextendedauthenticationoptions. If theseare tobeused in theSwissvoting system, then this should be addressed in the report. Summarizing,we find thisacceptablefortheproofsofcast-as-intendedverifiability,butnotcomprehensiveenoughforvoteprivacy.

8. VoterBehavior.Thisissueismoreasideremark,butonethatwebelieveisimportantforthesecurityofthesysteminpractice.Commonly,thebehaviorofvotersisnotcapturedintheanalysisofcryptographicprotocols.However,thepresentedprotocolsheavilyrelyonvotersperformingappropriatechecksandfollowingtheprotocolfaithfully.Althoughitis not required by [BK], we nevertheless recommendmaking explicit what is assumedaboutvoterbehaviorandthatpossiblesocialengineeringattacks(e.g.,byacompromisedclient),couldleadtoattacks.Theproofscouldalsobeextendedtocapturetheresilience

8April,2017

9


ContegoLaboratories


ofthesystemunderfailuresof(somesubsetof)voterstoperformsomeofthechecksorsteps. Since the voting client is assumed to be under the adversary’s control, it hasextensivepossibilitiesformanipulations.

c.EvaluationoftheProofs[Crypto,§4]structurestheproofofcast-as-intendedintermsofthreegames.Inessence,thesecovertheprobabilitiesthattheadversaryobtainsreturncodes(RC)correspondingtothevoter’schoicewithoutthisvotebeingcast,andthatitobtainstheconfirmationcodes(CC)orfinalizationcodes(FC)forthevoterwhosechoiceitistryingtocompromise,assumingthatallcryptographicprimitives,includingthosefortheNIZKproofs,canbebrokenonlywithanegligibleprobability.Thefourthgameisusedtoprovevoteprivacy.Overall,theproofsarewellexecutedandtheycovertherelevantcases(withrespecttoRC,CCandFC)thatcouldimpactcast-as-intended.Assumingthatthevotersaretrustworthyandfollowthe protocol, these games, by-and-large, prove cast-as-intended verifiability for the protocolsthataredescribedin[Crypto](notethatasdiscussedintheprevioussection,theseprotocolsareanabstractionofthedesign[OV]).Herewediscussmainissuesthatshouldbeaddressed.Mainissues

9. Gamehopping.Thegamehoppingproofsomitsomerelevantdetails.Forexample, thereduction steps in Games A and B are not included in the report. In particular, thereductionfromGameA1toA2shouldbeexplainedinmoredetails.Itshouldbeclarifiedtoo how PerfectProcessBallot checks that “the NIZK proofs have been correctlygenerated”. According to our understanding of the proof, PerfectProcessBallot neverfailsincheckingtheNIZKproofs;itisunclearhowthisisimplementedandwhetherthiscanbedone inpolynomial time.Thispolynomial timerequirement is importantforthereductionsincePerfectProcessBallotiscalledbythedistinguisheralgorithminGameA2.

10. Random voter ID. For vote integrity (cast-as-intended), the adversary is assigned arandomvoterthathehastoattack.Thismodelingomitsthe(realistic)threatofadaptiveattacks in which the adversary chooses the voter to attack after having analyzed thevoters’publiccryptographicmaterial.The formalizationandproofsshouldbeextendedtocoveradaptiveadversaries.

11. NIZKproofs.Theproof(GameA)thattheattackercannotcastunintendedvoteswithoutbeingdetectedomits toomanydetailsandshouldbeexpandedtoexplain theuseandrelevanceofindividualNIZKproofsforcast-as-intendedverifiability.Thiswillalsoprovidemoreclarityintermsofwhichhardnessassumptionsarerelevantforcast-as-intended.

AdditionalIssuesaredescribedintheappendix.

8April,2017

10


ContegoLaboratories


5.EvaluationoftheSymbolicModelandProofsa.MethodologyThe verification methodology used corresponds to the state-of-the-art for cryptographicprotocolverificationusingsymbolicmethods. Westartbybriefly reviewing thismethodology.Rather thanworking in the computational cryptographic setting,whereone reasonsaboutbitstrings,probabilisticpolynomialtime,andtheadversary’sadvantage,thissettingisabstractedtoonewhere:

1. Agentsrunningaprotocolaremodeledascommunicatingprocesses.Protocolmessagesaremodeled by terms in a term algebra and cryptographic operators aremodeled byequationsorreductionrules.

2. Theadversary isalsodefinedbyaprocess(orasetofrules)thatmodeltheknowledgethat he can derive from messages he has constructed or seen, or publicly availableknowledge. Together, instancesof theprocessesdefining theprotocolagentsand theadversaryarecomposed,andthiscomprisesa(global)transitionsystem.

3. Properties such as authentication and agreement are formulated as reachabilityproperties or traceproperties of the transition system. Properties such as privacy areformulatedintermsoftheobservationalequivalenceofpairsofprocesses.

4. Oneuseseithertheoremprovingoralgorithmicmodel-checkingtechniquestoconstructproofs.Thestate-of-the-arttoolscan,inthebestcase,establishthatthegivenprotocolhasthestatedpropertiesevenwhenanunboundednumberofprotocolsessionsexecuteinparallel,thatis,whenarbitrarilymanyagents(includingcorruptedoradversarialones)arerunningtheprotocolindifferentroles(e.g.,client,server,etc.).

Forthesymbolicproofs,theProVerifsystemwasusedforallfourofthesesteps.Namely,theprotocol, adversary model, and properties (Steps 1-3), were formalized in ProVerif’s inputlanguage.TheProVerifsystemwasthenusedtoconstructcorrectnessproofs(Step4)orprovidecounterexamplesto incorrecttheorems. Whatremainsthen is toevaluateSteps(1-3)above.Thisevaluationrequirestwokindsofchecks:

1. Theabstractsymbolicprotocoldescription,givenin[Symbolic,§2-§3],mustcorrespondtoactualdesign[OV]aswellastheadversaryandpropertiesrequiredin[BK,§4.1].

2. Theformalizationofthisprotocoldescription,adversary,andpropertiesmustbesuitablyformalizedintheinputlanguageofProVerif.Notethatmodels,likecomputerprograms,are not unique: there are many ways to model a protocol, the adversary, and theproperties.Asuitablesymbolicmodelisonethatcapturestherelevantartifactspreciselyenoughthatitcapturesallrelevantattackspresentinthedesignandhencecorrectnessensuresthattheseattacksarenotpossibleonan implementationthatconformstothedesign.

Wedescribeeachoftheseinthesubsequentsubsections.

8April,2017

11


ContegoLaboratories


b.EvaluationoftheModel(relationshiptothedesign)Thesymbolicmodelisgivenbyspecificationsin[ProVerifSources]andisalsopartiallydescribedby the document [Symbolic].We received 11 source files (ending in .pve) containingmodelswritten in a language that extends the input language of ProVerif to support parameterizedspecifications.A script isprovided (calledexpand) that compiles these source files, alongwithparametervalues,toProVerifinputfiles(endingin.pv).Thesourcefilesformalize(withminordifferences)thesameprotocolandadversarymodel,butdifferinthepropertiestheyestablish.Thereare3classesofsourcefiles:

1. Verifiability properties for a fixed number of voting options: The source spec_v4.3.pvespecifies that the votingprotocol satisfies the cast-as-intendedproperty anda formofthe tallied-as-cast property. Theseproperties are parameterized andestablished for afixednumbernofvotingoptions,wherethevotermustchooseexactlykofthoseoptions(e.g.,k=2,n=3).Thisisdescribedin[Symbolic,§4].

2. Ballotprivacyproperties: These formalize thatnoone can learn informationabout thevotingoptionsofanhonestuserotherthanwhatcanbelearnedfromtheelectionresultsalone. These properties are parameterized by the number of chosen voting options k.Thisisspecifiedinthesourcefileswhosenamesbeginwithequiv_v6.7anddescribedin[Symbolic,§5].

3. Verifiability properties for an unbounded number of voting options: These specifyverifiabilityproperties like in (1),butnowforanunboundednumberofvotingoptions.Thisisachievedbyusinganappropriateencodingbasedonlistssothatthespecificationsno longer require the parameter n describing the number of voting options. Thespecificationisstillparameterizedinthenumberkofchosenvotingoptions.Themodelisgivenbythesourcefileequiv_v8.pveanddescribedin[Symbolic,§5].

Anumberofsourcefilesareincludedthatareminorvariantsofthosenamedabove,whicharenot relevant for this evaluation, or they formalize additional properties that constitute basicsanity checks on the modeled protocol. For example, the property in model spec_v4.3-Check.pvestatesthatusingtheprotocol(asmodeled)avotercanvoteandconfirmherballot.Suchchecksaresensiblesinceallsecuritypropertiesprovenaresafetypropertiesandwillholdtriviallyifthemodeldoesnotallowobligedbehaviors,e.g.,thatvoterscansuccessfullyvote.Themodels themselves are carefully constructed and comparable to state-of-the-art symbolicmodelsfoundinthesecurityandcryptographicliterature.Thesymbolicprotocolmodelcloselyfollows to the protocol description given in [Crypto] in modeling the actions taken by thedifferent parties (constructing cryptographic message, storing and communicating data, etc.).However, the symbolicmodel, as explained above, represents the cryptographic operators assymbolic abstractions given by terms rather than as mathematical functions. This againcorrespondstothestate-of-the-art.Belowwefocusontwocentralquestions.First,whetherthesymbolicabstractionusedomitssomuchdetail that themodel no longer captures realistic attacks on the actual implementationthatmaybepossiblebyexploitingpropertiesof thecryptographicoperatorswhichhavebeen

8April,2017

12


ContegoLaboratories


abstractedaway.Thisincludesthequestionofwhethertheadversary’scapabilitiescorrespondto those requiredby [BK, §4.1]. The secondquestion iswhether theproperties verified entailindividualverifiability.Adequacyoftheprotocolandadversarymodels.

• As explained in [Symbolic, p. 2], the symbolicmodels are based on the cryptographicmodel[Crypto].Consequently,thesymbolicmodelshavethesamemodelinglimitationsidentified for the cryptographic model, described in Section 4b of this report. Inparticular,therelationshiptotheactualdesigndocuments[OV]isnotgiven,substantialparts of the design (e.g., user authentication) are omitted, and different names andterminology are used (e.g., for keys and algorithms). We emphasize some additionalaspectsofthisbelowaswell.

• The entire setup, describing the generation and relationship of cryptographic keys ismissing.Theserelationshipscanbeeasilymodeledinthesymbolicsettingandshouldnotbeabstractedaway.Relationshipsbetweenkeyscanbeasourceofattacks inpractice,especially when components end up under adversary control, thereby compromisingsomeofthekeys.Symbolicmodelcheckersaregoodatfindingattacksinsuchscenarios.

• Control flow options in the design are sometimes abstracted away. These can, andshould,behandledinthesymbolicsetting.Anexampleofthisis[OV,§4.4]statingthat“the systemallows the voter to logout after sending the vote, and then log in back inorder to see the choice codes again and confirm her vote. In this case, afterauthentication, thecorrespondingvote isobtained fromtheballotboxandsteps7-8ofSendaVotearerepeated.”Wenotethat(1)thispossibilityiscompletelyomittedfromthesymbolicmodel. (2)Thecontrol flow isnot furtherdescribed in [OV,§4.1],andtothisextent[OV]itselfdoesnotprovideacompletedescriptionofthedesign.Finally(3),the details here might actually matter for the voting system’s security. For example,withoutdesigndetails, it isunclearwhether theadversary, inpossessionof theclient’scredentials,couldrepeatedlyloginandoutandchangethevoter’sselectionafterseeingreturncodes.

• ProVerif’s input language is typed and the typing in [ProVerif Sources] associates allcryptographic keys with asymmetric key pairs. In doing so, it abstracts away thedistinction between keys used for ElGamal, RSA, and those produced, e.g., by apassword-basedkeyderivation function [Tools]. Allencryption in [ProVerifSources] ismodeledwith the same function, Enc,which returns a bitstring (representing a ciphertext),ratherthanapairasin[Crypto],containingthepublickeyoftheencryptingpartyandtheciphertext.Werecommend(non-mandatory)modelingthesefunctionsandtheirtypesmorefaithfully.

• The abstraction of modular exponentiation and zero knowledge should be betterjustified.This isadelicatepoint.Finer,moredetailedmodels (e.g., formalizingElGamalencryption in terms of a cyclic group) would more faithfully capture possiblecomputations by a (polynomial bounded) attacker, but would lead to increased proofsearch.Insomecases,byusingalternativetools(MaudeNPA,Tamarin,orevenahigher-order logic based theorem prover) it would have been possible to givemore detailedmodels, but at the possible cost of higher theorem proving effort. In particular, Non-

8April,2017

13


ContegoLaboratories


InteractiveZeroKnowledgeProofsaremodeledin[Symbolic]byaddingjustoneequation(subsequently approximated in the source files by four equations) that expresses themultiplicativepropertiesof the functionPhi that aggregates votesandhow it interactswithanabstractionofmodularexponentiation.MorejustificationisrequiredforwhythisisadequatetomodelthedifferentkindsofNIZKproofsusedintheprotocolasdescribedin[OV]andin[Tools],whereNIZKproofsbuildonMauer’sunifiedproofs.

Adequacyoftheformalizedproperties.Theformalizedpropertieshavesomelimitationsthatareeitherinherentinthestate-of-the-artortheProVeriftoolbeingused.Theseinclude:

• Specificationsandpropertiesareparameterized,sotheguaranteesprovenonlyholdfortheparameterinstancesconsidered.Moreover,duetothelargesizesofthestatespacesinvolved,theprotocolcanonlybeanalyzedforsmallparametervalues.Forexample,forthe parameterized verifiability properties (spec_v4.3.pve) it takes roughly 7 hours forProVeriftoverifythestatedpropertiesfork=2andn=3,i.e.,for3ballotoptionsofwhichvotersmustchoose2.

• The properties must be proven under additional assumptions about the behavior ofhonestvotersandthesystem[Symbolic,p.10].TheseassumptionsarisingfromtechnicalartifactsofProVerif’smodelingformalismanditsoperationalsemantics.Inparticular,asexplained in [Symbolic, p. 10], ProVerif does not support the synchronization ofconcurrentprocesses,andthisleadstoattacksthatcouldbeeliminatedinpracticewithpropersynchronization.

Although stronger guaranteeswouldbedesirable, all state-of-the-art verificationmethodswillhaveanalogouslimitations.Thepropertiesformalizedareadequateforindividualverifiability inthesenseof[BK,§4,1]butnot in the stronger sense of [E2E] or [PostWeb]. Specifically, two verifiability properties areactually checked, referred to in [Symbolic, §4] as Cast-as-Intended and Tallied-as-Cast. In[Symbolic], cast-as-intended formalizes that after an honest voter receives and validates theexpectedreturncodes,thentheballotboxstoresherballotb. Theprotocolmodel formalizeshereonehonestvoterplayingagainstanunboundednumberofotherdishonestvoters,andwithadishonest (client)computerandanhonestserver. This fulfills thetrustassumptionsof [BK,§4.1] and individual verifiability in the sense stated there. The Tallied-as-Cast property in[Symbolic] expresses additional guarantees that hold when the voter receives the finalizationcode from the server, in particular the ballot b satisfies the properties required for it to beacceptedfortallying.Thispropertycanbeseenasstrengtheningthecast-as-intendedpropertywithadditionalguarantees.However,itdoesnotformalizethenotionofRecorded-as-Castfrom[E2E] or [PostWeb] as neither themodel nor the property formalize the notion of the voterreceivingareceiptandcheckingthereceiptonabulletinboard.Moreover,itdoesnotformalizeTallied-as-recordedeitherasitdoesnotmodelthetallyingphaseandsubsequentchecks.

8April,2017

14


ContegoLaboratories


c.EvaluationoftheProofsThecorrectnessoftheresultingproofsreliesonthecorrectness(i.e.,thesoundness)ofProVerif.AsProVerifisoneofthestate-of-theartsecurityprotocolmodelcheckersandiswidelyused,itisreasonabletoassumethis.The[ProVerifSources]wereprovidedfortheevaluationalongwiththeProVeriftool(version1.94). Wereproducedtheverificationresultsbyrunningthetoolonthe source files provided, thereby having the tool construct symbolic proofs for differentparameterinstances.

8April,2017

15


ContegoLaboratories


6.SummaryofMainRecommendationsIn the following,wesummarizeourmost important recommendations fromSections4,5,andthe Appendix of this report. These changes are those thatwe consider to bemandatory forconformancetotherequirementsof[BK,5.1].

1. Design documents should describe the complete design of the Swiss implementation.These documents should explicitly describe all options (e.g., extended authentication,receipts,etc.)thatwillbeusedinthefinalsystem.Also,allcontrolflowshouldbemadeexplicitinthedesigndocuments,includinghowerrorsandexceptionalcasesarehandled.

2. Relationship of models to the design. This should be made explicit so that thecorrespondencebetweenthemodelsandthedesignisclear.Keys,data,procedures,andprotocols phases and steps should all be identically named across the differentdocuments: [OV], [Crypto], [Symbolic], and [Proverif Sources]. When models omit ormodifydetailsfromthedesign,thisshouldalsobestatedexplicitlyandjustified.

3. Providemissingdetailsinmodelsandproofs.Modelsandproofsshouldbeprovidedforwrite-invotes(cryptographicandsymbolic),Maurer’sUnifiedProofs(cryptographic),andthe use of short codes versus long codes (cryptographic and symbolic). The proofsshouldbeamendedtoreflectthedesignin[OV].

4. Game hopping proofs. These require additional details and minor changes, e.g., thereduction from Game A1 to A2, additions to allow adaptive attacks, and moreinformationonhowtheNIZKproofsarehandled.

5. SymbolicProofs.Themodelsshouldbeextendedtoformalizetherelationshipbetweendifferentkeys. Moreover,missingcontrolflowdetails,whicharepresent inthedesign,shouldbeadded. Incaseswheresuchdetailsare inadequatelyexplained inthedesigndocumentation, forexample [OV,§4.4], then[OV]shouldalsobeextended. Additionalexplanation isalso requiredonthemodelingofNIZKproofsandwhy it isadequate forthedifferentkindsofNIZKproofsactuallyusedinthedesign.

Given the above, the system as it stands does not conform to the requirements of [BK, 5.1](“Nicht-Konformität–Verbesserungobligatorisch).

8April,2017

16


ContegoLaboratories


7.Appendix

a.AdditionalCommentsontheCryptographicProofs• The definition of cast-as-intended introduced at the beginning of §4.1 is somewhat

misleading as it refers to the probability of the voter not noticing or detecting someevents.Buttheproofsdonotdiscusssuchprobabilities.Insteadtheyassumethatvotersfollowtheprotocolandneverdeviate.Thisshouldbeclarified.

• Thegametransitionsfailifthekeymaterialofacorruptedvoterhappenstooverlapwiththe key material of the challenge voter. The probability of this happening is notconsideredintheproofsofgamesA–C.Suchclashprobabilitiesshouldbediscussedandadded to theboundson theadvantages.As thechallengevoterand its keymaterial isgeneratedatthestart,independentoftheadversary,thisprobabilityisnegligibleasthenumberofrandomsamplesispolynomial.Overall,Theorem1shouldstillhold.

• The challenge id in the games A–C is a random value fixed at the start of the game,before the cryptographic material (keys, confirmation codes, etc.) is generated. ThesamplingisirrelevantbecausetheencodingoftheIDnevercontributestoanything.So,onemightaswellfixsomechallengevoterid0.The approach taken rules out adaptive attacks, which are relevant in practice: Theadversarycanchoosevoterswhosepublickeyslookeasytobreak.Fixingoneparticularvoter at the start deprives the adversary from this choice. The formalization shouldtherefore startwith a game inwhich the adversary can adaptively compromise votersand chose the challenge voter ID. Another transitionmay be needed to eliminate theadaptivechoices.Adaptivechoicesalsoaffectthereasoningaboutclashesamongthecryptographickeys.Withafixedchallengevoter,randomchoicesforcorruptedvotersonlyhavetoavoidthecorrespondingrandomchoiceofthechallengevoter.Withadaptivechoices,therandomchoicesmustavoidallpreviousrandomchoices.Withpolynomialboundsonthenumberofvotersandvotingoptions,theprobabilityshouldstillbenegligible,buttheanalysisofthegamesbecomesharder.

• p.10,configurationphase:“theelectionauthoritiessetupthepublicparametersoftheelection such as […] the set of valid votes (combinations of voting options) V”.Theprotocolasdescribedonlysupportsvoteswhereallvotingoptionscanbecombinedarbitrarily because the algorithm CreateRC checks in its second step that the hashedreturncodesofthechosenvotesareonthebulletinboardforthecurrentvoter,sothisisjustamembershiptest.Thepapershouldexplainhowtheprotocol(andCreateRCinparticular)mustbemodifiedsothatonlycertaincombinationsofvotingoptionsareallowed.Explicitlyenumeratingallpossible combinations as separate voting options leads to an exponential blowup andthereforebreaksallthereductionproofsbecausetheenumerationsmustbepostedonthe bulletin board as hashes of return codes and the posting is part of the reduction,which must run in polynomial time. Conversely, if the combinations are describedcompactlyintermsofthehashesofthereturncodes,thenballotprivacyisatrisk.Asthehashed return codes get postedon thebulletin board, the adversarymightmatch the

8April,2017

17


ContegoLaboratories


allowedcombinationsagainsttheencodingofthecombinationsandthereforeinferthemeaningofthehashesofthereturncodes.

• ThehashfunctionusedinthesignatureschememustbedifferentfromthehashfunctionHusedintherestoftheprotocol.Thisassumptionismissing.Otherwise,thetransitionfrom gameB to gameB.1 breaks because only some invocations of the hash function(thoseusedtocomputethesignatures)arereplacedbyarandomoracle,butnotall(e.g.,thoseusedforhashingthereturncodes).That is,theROMassumptiondoesnotapply.Clarification should be added that in Game B.1 it is only the hash function inside thesignatureschemethatisbeingreplacedbyarandomoracle,butnotthehashfunctionHusedintherestoftheprotocol.

• InGameC.2,thePRFfskaisreplacedbytwodifferentrandomfunctionsRrcandRfc.ThetwofunctionsRrcandRfcshouldbethesame.Otherwise,theadversarymaydistinguishgamesC.1 andC.2 by observing inconsistentmappings. (There is no argument that allreturn codes are different from the space of confirmation messages, so clashes arepossible.)Moreover,thereisnoneedfortwoseparatefunctionsRrcandRfcintheproof.

• p.5f,onvotingoptionsandthePRFfamily:Thereisnodiscussiononhowthenumberofvotingoptionsinfluencesthechoiceofthesecurityparameter;thisisalsomissingintheimplementation section. Moreover, [18] does not formally prove that exponentiationwith a small prime forms a PRF. The authors should cite (or provide) a cryptographicproof,statetherequiredhardnessassumptionsonthegroup,andmakesurethattheirchosengroupmeetstheseassumptions.

• ThereductioninLemma1missesseveraldetailsthatareneededtoproducegameD.4.Forexample:

o Configuration phase: GameD.4 does not publish sk_a and sk_c on the BB, butpasses them directly to the adversary. Also, it initializes the sets ID, ID_c, andID_h,whichthereductionomits.

o Registration phase: When registering a corrupt voter, game D.4 provides thevotingoptionsv_iandthereturncodesRC_i,whereasthereductionprovidesonlythe return codes RC_i. When processing Challenger_VoteLR queries, thereduction forgets to check the validity of votes and the ID of the voter withrespecttothesetsID_candID_h.

o Countingphase:GameD.4re-checksallvotesontheBBusingProcessBallot,butTally inC'doesno suchchecks. This requiresanexplanationofwhy the checkscanbeomitted.

The report should spell out the reduction in pseudo-code-like the definitions of thegames.ItwillthenbeeasiertoseewhetherthereductionreallycoverseverydetailofthegameD.4.Foreverypointthatthereductionandthegamediffer insyntactically,thereshouldbeanexplanationofwhythedifferenceisinsignificant.

Minorissues:

o p.3,RSA-PSS,lastbutoneline:Whatisσ?Shouldthisbeψ?o p.14,Challenger_Votealgorithm:The“=1” in the first lineshouldbedropped.

Thereisalreadyatestontheresultafterwards.SimilarinGamesBandC.

8April,2017

18


ContegoLaboratories


o p. 15, line 1: The challenge ID id has been fixed at the configuration phase, sothereisnopointinlettingitrangeoverallIDsinIDh.IngamesA–C,therewillonlyeverbeoneIDinIDh,namelytheonechosenintheconfigurationphase.

o Thenamesofalgorithms in thedifferentgamesA–Care re-usedalthough theirdefinitions are not the same. For example, RndRegister in game A is differentfromRndRegisteringameB.Itwouldimproveclarityifdifferentnameswereusedfordifferentalgorithmsindifferentgames,evenifthestepsareconceptuallythesame.

b. AdditionalCommentsontheSymbolicProofs

Thedescriptionin[Symbolic]differsinintendedandpresumablyunintendedwaysfrom[ProVerifSources].Thefollowingareseveralexamplesofthis:

• Enc is declared as a binary function in [Symbolic, p.2] but it is a ternary function in[ProVerifSources].

• Theattackerdeductionruleforw[Symbolic,p.4]isnotneeded:fromthemessagemtheadversary can derivemwithout themodular exponentiation. This rule is not presenteitherin[ProvVerifSources].

• The description of cut [Symbolic, p.4] and its typing are unclear. It is described asprojecting the 2nd element from a 5-tuple output by the algorithm CreateVote. In[Symbolic], CreateVote returns a tuplewith at least 5 components (dependent on thenumber of voting choices) and in [Crypto] it returns a 3 tuple. In [Proverif Sources],CreateVotereturnsa5tupleandcutitselftakesasingleargumentoftypebitstring.

8. Responsibility

This audit report was produced by the undersigned on April 8th, 2017.

__________________ ____________________ Prof. Dr. David Basin Prof. Dr. Srdjan Capkun