# Secure and Privacy-Respecting Documentation for Interactive Manufacturing and Quality Assurance
## 5 Security Analysis
### Countermeasures  
We begin our analysis with the privacy attacker's attack vectors. In the first case, tapping a video at the time before it was encrypted, immediately after recording, cannot be prevented completely because the operating system's access control mechanisms cannot protect against a system administrator acting as a privacy attacker. With his privileged permissions, he can copy an unencrypted video to another location before it is deleted and he can also execute programs to automatize attacks. However, this kind of attack is made considerably more difficult by two circumstances. First, it cannot be carried out remotely, because even an attacking administrator does not have remote access, so the attacker would be observed by the worker. Second, the integrity verification mechanism from Section 4.1 ensures that manipulation of the smart documentation system, for example, by starting a program for automatizing an attack, can only take place after the worker has already attested the smart documentation system and started his work. Furthermore, the system would have to be restarted in time to prevent a failed attestation by the next user/worker after an attack. We therefore argue that this kind of attack can neither be automated nor scaled and becomes unattractive for the privacy attacker, who is interested in obtaining multiple videos to gain surreptitious insights into the work performance of employees. The second case is similar for the system administrator attacking on the employer's instructions. He must be on site to manually copy the video just decrypted by the authorized parties to another location. With the limitation to a single video, to which the authorized parties already allow access to anyway, this does not seem to be a particularly attractive profit for the privacy attacker. For the third attack vector, the attacking system administrator would need to replace certificates of workers in the directory service for authentication and in the key store for encryption. The first step is possible, since we do not trust the directory service, but it does not achieve the goal on its own, since it still does not enable video decryption. The second step of this attack is complicated by the fact that the key store is part of the attestation process according to Section 4.3. As in the prior cases, the attacker would have to be on site, act after the attestation has been performed by the worker and reset the system before another attestation by a worker takes place. Otherwise at least one attestation would fail. For the fourth attack vector, the attacker completely replaces the smart documentation system. However, this attack must again fail because the attacking administrator cannot generate a TPM quote for the forged system that is indistinguishable from a valid state of the real system. The modifying attacker's first attack vector, i.e., to authentically modify an encrypted video, requires a successful privacy attacker's attack which has been discussed previously, and which is even harder to conduct by a worker without a privileged user account. Hence only the second attack vector remains to be analyzed: to create a seemingly authentic video foisting an error on somebody else. We consider the case of the system administrator acting as a modifying attacker. We assume that the attacking administrator has a video sequence in plain text that is indistinguishable from an authentic video. We further assume that he can use functions of the components of the smart documentation system, so that he can easily generate partial keys and encrypt them with any public keys from the key store. However, the attacking administrator cannot perform a crucial step: he cannot forge the signature over a timestamp and the key share of the worker to whom the video is to be foisted because he cannot get hold of the worker's private key, which does not leave the trusted private smartphone.