CCA Cryptographic Mechanism
Introduction
For instances where a form designer wants absolute confidentiality such that data is inaccessible to anybody,
including the administrators of CCA System, the designer is able to generate and attach cryptographic keys to forms which assure that these forms submissions are encrypted on the device and on the server and can only be decrypted by the entity with the right cryptographic private key.
The CCA System tools use the trio of the Diffie–Hellman (D–H) key exchange mechanism,
the Advanced Encryption Standard (AES) and
the SHA256 hash algorithm to assure data confidentiality and authentication. Note that media files e.g., photos, captured during data collection are not encrypted.
As demonstrated in this example, during form definition
the CCA Desktop app is
used to generate a public and private key pair with the “.public” and “.private”
file extensions, respectively. The public key is attached to the form being defined.
When this form is downloaded to the device and filled, at the point of being
saved the following cryptographic functions are executed:
A new randomly secure cryptographic public-private
key pair is generated by the CCA Mobile app.
This new key pair along with the public key contained in the form are used to compute another cryptographic key which is then used to encrypt the submission.
The signature of the encrypted submission is computed using a hash algorithm.
The encrypted submission, the computed signature and the public key component of the key pair created in step 1. are stored on the device from where they are uploaded as a unit to the server.
The unencrypted version of the submission along with the key pair generated in Step 1 are discarded and never used again.
Steps 1 to 4 are repeated for every submission of the form.
The fact that each instance of a form is encrypted using a different cryptographic key assures
that the compromise of a single submission does not affect the security of other submissions.
Encrypted submissions can be downloaded and decrypted and authenticated offline using the
CCA Desktop app. Note that the public and private key pair used during the form's
definition must be present. The process of authentication and decryption are as follows:
The private and public key pair files generated for the form, along with the path of the folder where the encrypted data reside, are passed to
the Encrypted submissions can be downloaded and decrypted and authenticated using the
CCA Desktop app.
A signature is computed for each encrypted submission by the same hash function used on the android device.
The computed signature is compared to the signature contained in the encrypted submission. If both signatures do not match, the submission fails the authentication process. Failing the authentication process indicates that the data has been tampered with.
If the submission passes the authentication process, a new cryptographic key is computed
using the form’s public and private key pair as well as the public key contained within the form submission.
This new key is used to decrypt the form submission.
Steps 1 – 4 are repeated for every submission of the form.
Technical Details
CCA System employs the unkeyed SHA256 hash algorithm for data signing and authentication.
The symmetric Advanced Encryption Standard (AES)
in counter mode is used to ensure data confidentiality.
The Diffie–Hellman (D–H) key exchange mechanism is used to generate the 128-bit long symmetric keys used
to encrypt and decrypt the data. A 128-bit integer Initialization Vector (IV) which has a fixed value of 16
is used for AES encryption and decryption. Note that a fixed IV value does not in any way weaken the properties
of the cryptographic mechanism used in this work since each new submission is
encrypted with a different 128-bit key as described in the previous section.
Before proceeding to describe the math behind the security mechanism,
it is pertinent to state here that all cryptographic computations in
this work are carried out in the big-endian format.
In the first instance, a pair of public-private keys are created during the form definition.
Let X_f and Y_f denote the private
and public keys, respectively. The relationship between X_f and
Y_f is shown below:
Y_f = g^{X_f} \mod \; p \qquad (1)
Where X_f is a secure randomly generated 320-bit integer,
g is the generator with a value of 2
and p is a 1536-bit prime number. The g
and p values are specified in Section 2 of
RFC 3526.
Y_f is included as one of the parameters of the form.
When a complete form instance is to be encrypted on the android device,
the CCA Mobile app generates a private key X_m
and public key Y_m.
Y_m and X_m are related using the equation shown below:
Y_m = g^{X_m} \mod \; p \qquad (2)
Like X_f in Equation (1),
X_m is a secure randomly generated 320-bit integer.
g and p are the same parameters mentioned in Equation (1).
The CCA Mobile app
computes an encryption key, K_m, using the following equation:
K_m = Y_f^{X_m} \mod \; p \qquad (3)
Y_f is the public key computed in Equation (1) and included in the form.
The first 128-bits of K_m is extracted to get K_{m-128}.
If the unencrypted submission is denoted by D and its encrypted form denoted by
D_x,
then the relationship between D and D_x is:
D_x = E(K_{m-128},D,IV) \quad (4)
Where E is the AES encryption function in counter mode,
K_{m-128} is the 128-bit encryption key and IV is the
initial vector which is a 128-bit integer with a value of
16.
After encryption, the encrypted data signature, S_m,
is computed. Let the equation below represent the signing process:
S_m = S(D_x) \qquad (5)
Where S is the SHA256 hash algorithm.
The encrypted data, D_x, its signature, S_m,
and the public key Y_m are saved to the device
and uploaded to the server. Let these three
parameters be represented as a unit by:
\{D_x,S_m,Y_m\} \qquad (6)
When an encrypted submission is to be decrypted, the CCA Desktop
app extracts the D_x parameter in Equation (6) and computes signature,
S_f:
S_f = S(D_x) \qquad (7)
The app then extracts S_m from Equation (6) and checks if S_f = S_m.
If this equality is false all parameters of Equation (6) are discarded.
Otherwise, the app proceeds to the decryption process.
To decrypt D_x, the CCA Desktop app extracts Y_m from
Equation (6)
and computes the cryptographic key, K_f, using the Equation (8):
K_f = Y_m^{X_f} \mod \; p \qquad (8)
The parameters X_f and p are those presented in
Equation (1) .
The first 128-bits of K_f are extracted to get K_{f-128}.
Remember that D_x is the encrypted version of D.
The relationship between D and D_x during decryption is thus:
D = E^{-1} [K_{f-128},D_x,IV] \qquad (9)
Where E^{-1} is the AES decryption function in counter mode, K_{f-128}
is the 128-bit decryption key and IV is the initial vector which is
128-bit integer with a value of 16 as mentioned previously.
Final Thoughts
Equations (1) – (9) describe the encryption and decryption process.
It is possible to use these equations to verify the foundations of
the security mechanisms presented here or possibly create an alternative tool to decrypt
encrypted data collected using the CCA System.