# Secure and Privacy-Respecting Documentation for Interactive Manufacturing and Quality Assurance
## 4 Privacy-Preserving System Design
### Integrity Verification  
In the previous sections we have shown how 4 Crypt encrypts video files and implements a secret-sharing algorithm on the cryptographic keys to enforce consent of both the worker and a set of trusted representatives before videos are disclosed. This solution prevents the employer from decrypting any videos by himself in order to use them for illegitimate purposes such as the covert performance evaluation of workers. However,  
Figure 6: 4 Crypt video decryption process. since the employer operates 4 Crypt alongside the video surveillance system, he has comprehensive physical access to the 4 Crypt hardware and software. Hence, the employer could simply turn off the privacy-protection modules and bypass the encryption altogether by proactively tampering with the 4 Crypt system components directly on the machine. Since the goal of 4 Crypt is to protect the privacy interests of recorded workers against a malicious employer abusing the video documentation system, why should the workers trust the employer with setting up 4 Crypt correctly in the first place? Due to this consideration, it is necessary to give the workers the opportunity to verify the integrity of the 4 Crypt privacy-protection modules before being subjected to the video surveillance. That way the workers would be able to detect malicious tampering with the 4 Crypt system or confirm that their privacy is in fact being protected before starting a supervised work step. In 4 Crypt, we enable workers to confirm the integrity of the documentation system by adding _trusted platform modules_ (TPMs) to the system design. A TPM is a dedicated hardware chip that extends a computer with basic security related features. TPMs operate as trusted hardware security modules and are always designed according to a specification developed by the Trusted Computing Group (TCG) [24]. Each TPM holds several cryptographic keys that can be used to encrypt data, identify the computer system and attest to its current software stack. For this, the TPM contains volatile _platform configuration registers_ (PCRs) that can be used to measure the current hardware and software configuration as an unforgeable fingerprint. During a trusted boot sequence each boot stage hashes the software stack of the next stage and writes this measurement into the PCRs. By extending these measurements all the way up to the user applications and their configuration, the fingerprints accumulated in the PCRs uniquely represent the current state of the software stack that is running on the measured system. Building on this measurement process, an external third party can remotely verify that the measured system is running a certain software stack in a certain state. This process is called _remote attestation_. During a remote attestation, the external verifier requests the log of the conducted measurements along with a so-called _quote_, which contains the fingerprints collected during the measured boot sequence and serves as proof of the current system state. In order to prevent the challenged system from lying about the fingerprints stored in its PCR registers, the remote verifier checks that the provided quote is signed by the TPM with a valid _attestation identity key_ (AIK). The AIK is an asymmetric cryptographic key pair that has been created by the TPM during a prior enrollment phase. While the public part of the AIK is known to all involved participants (usually it is certified by a trusted party), the private key never leaves the TPM. Hence if the quote signature is correct, the verifier is convinced that the system under test did not lie about its fingerprints in the measurement log. Then the verifier evaluates the measurement log and confirms that the measured fingerprints of the applications running on the remote system match the expected fingerprints of a correctly configured and unmodified software stack.