| Leakage of foreign data by personnel |
not possible and easily verifiable |
possible if the trusted third party and evaluation party work together or if the trusted third party has access to personal data |
not relevant since nobody has access to foreign plain data |
depending on implementation very unlikely if possible at all, but difficult to verify |
not relevant since nobody has access to foreign plain data |
| Security corruption by personnel |
very difficult since the sealed and frozen system state report is disclosed for in depth verification |
possible at the trusted third party |
possible by leakage or manipulation of obfuscation algorithms |
depending on implementation very unlikely, but difficult to verify |
possible at all data providers’ servers |
| Theft of disk or server |
full encrypted disk without LUKS header can only be decrypted by brute force attack against the master key |
if disks are full encrypted disk they can only be decrypted by brute force attack against the master key or passphrase |
| Hacking |
slightly higher protection than a properly secured GNU/Linux server (no user logon) |
the single servers can be protected on state-of-the-art level, but every additional computation and communication stage and especially added software is a potential security risk and may introduce new vulnerabilities |
| Man-In-The-Middle-Attacks on data transfer |
slightly higher risk since plain personal data could be accessible |
slightly lower risk since no plain but still person relatable data are transferred |
lower risk since transferred data are hardly person relatable |
low risk since only encrypted data is transferred |
low risk since only analysis commands and non-disclosing summaries are transferred |
