Use case scenario

For extremely sensitive situations where complete security in terms of confidentiality is required, CCA System advances features that allow for the definition of forms that force submissions to be encrypted on the collector’s device. These submissions remain encrypted even on the server after upload. What this means is that nobody, including the administrators of the server, have access to the encrypted data except the individual or individuals who possess the cryptographic key pair associated with the form.

This walkthrough demonstrates how the tools of CCA System is used to accomplish all of the above. To this end, consider a use case where a number of candidates are put up for a public vote in which the candidate with the highest votes wins the prize of a life time. For this use case, assume that the voting process mandates that every single vote is correct, is tamper proof, a voter cannot submit more than one vote, and vote counts can only be seen and analyzed by a select group of individuals. A candidate is identified by his/her email address. A vote assigned to a candidate must be between 10 and 100 and must be a multiple of 10.

The specific cryptographic mechanisms by which form submissions are encrypted and decrypted are presented here.

For this use case, it is infeasible to create a data collector user account for each and every member of the public in order to allow them vote due to the sheer number of possible voters. This is precisely the reason for the XCollect user designation. It allows any number of data collectors to share one login credential. This credential in turn is created and managed by the account administrator(s). Read more on user designations here.

Form constraints

The following constraints can be deduced from the last section:

1. All inputs are compulsory.


2. The form must provide a mechanism that validates candidates’ identities against the correct email syntax. Where this validation fails, the identity should be rejected.


3. The vote value entered by a member of the voting public must be within the allowable values defined in the last section.


4. To ensure that it is one vote to one voter, the form also collects voter’s device identity. This will allow the invalidation of votes that share similar device identities. Of course, this assumes that a voter has access to a single device which is not the case in reality. Let this assumption stand for the purpose of this example.


5. The form’s submissions once complete must be encrypted on the device and encrypted when uploaded to the server.

Walkthrough structure

The outline of this walkthrough is as follows:

• Generating cryptographic keys


• Designing the form with the constraints listed in the last section.


• Uploading the form to the server.


• Downloading the form to the device, filling the form, encrypting and submitting completed forms to the server.


• Decrypting and authenticating form submissions.

Unzip this folder to get samples of the completed forms in the .def and .json formats as well as the encryptions keys.

Click the Next button to start.