The Trusted Server: Concept and reference implementation of a fully autonomous and trustworthy computational server providing an advanced level of Privacy by Design through machine-based trust.
Nikolaus von Bomhard 1*¶, Bernd Ahlborn 1, Catherine Mason 1, Ulrich Mansmann 1
1
Department of Medical Information Sciences, Biometrics, and Epidemiology
Ludwig-Maximilian’s University, Munich, Germany
* Corresponding author
[email protected] (NvB)
1/21
Abstract: Privacy by Design is a core element of the EU General Data Protection Regulation and of similar legislation in other countries. It both proposes and demands the use of appropriate methods to protect personal data and the privacy of individuals whose data is stored and processed in computing environments. These requirements are currently met through anonymization, pseudonymization and encryption. Multi-stage pseudonymization enhances privacy by assuring no single institution or person is in possession of sufficient data to identify an individual. This means privacy is not ensured by design, but rather based on workflow complexity and trust on individuals, especially that of system administrators who have unlimited access to systems and data under their governance. Secure Multiparty Computation using full data encryption is a promising method that has made substantial progress, though real-world cases are rare and highly specific. Research presented in Google Scholar reveals some examples, but the majority of publications deal with complex mathematical models and reference implementations. The Trusted Server is a completely autonomous and generic implementation of Privacy by Design. Once set up and running, it is irrevocably sealed for its whole lifecycle allowing only explicitly implemented data input, access, processing and output. Being unlimitedly validatable and verifiable, it supersedes trust built upon human individuals thus acting as trustworthy entity itself. It is strictly standard compliant, easy to set up and use, and is suitable for almost any computational service or processing task other than persistent storage. The Trusted Server allows implementation of straightforward solutions with full privacy protection for otherwise complex problems, as demonstrated in the following examples: first, a reference implementation of a fully-anonymous yet access-controlled web feedback submission server; second, a solution for Yao's Millionaires' Problem is given, which requires just a few simple scripts.
2/21
Introduction: Common practice of privacy protection As recommended in the EU General Data Protection Regulation {GDPR} [1] and other legislation [2], Privacy by Design is currently implemented by encryption together with pseudonymization or anonymization. File, network-transport and disk encryption generally help to protect data in case of accidental loss, from theft of storage media and against wiretapping. Data pseudonymization is used to permit scientific or commercial data evaluation without compromising individual privacy. The GDPRs' demand for separated storage of pseudonymization keys is usually met by two (or multiple) stage pseudonymization, ensuring that no single institution or person is able to depseudonymize data. However, even pseudonymized datasets with multiple person-related contents [3] may require additional abstraction and depersonalization, for example hashing technologies, for sufficient privacy protection.
Criticism Privacy by Design based on storage and transport encryption combined with multiple stage pseudonymization may achieve reasonable levels of protection. With increased security come the drawbacks of greater complexity, higher cost and increased inertia with every pseudonymization stage involved. Nevertheless the grade and quality of protection will never be quantifiable. Since there is no single instance which is able to depseudonymize data, abuse is less likely with every additional stage involved. However, abuse is remains possible if trusted personnel, especially rootrighted administrators, work together. Trust in humans can never be verified. Indicators of human trustworthiness rely on prior experience that is extrapolated to predict future behavior of that person. This may work well in many or most cases but can never be an absolute or validatable estimate. Additionally, any data abstraction to enhance privacy will by nature also reduce data quality in comparison to unaltered plain source information, while also increasing implementation and computation effort. In some scenarios this natural data degradation may be without consequences, though in
3/21
others it may have relevant, but hard to estimate, impacts on evaluation. For example, the impact on finding doubles in anonymized data sets coming from different sources is not quantifiable, since comparison of real-world anonymized versus plain data is prohibited by privacy laws.
Advanced Solutions Secure Multiparty Computation is an alternative that seems to overcome these design flaws by providing true Privacy by Design through exclusive usage of fully private and encrypted data. This however comes at the cost of even higher complexity, resource consumption and case-specific rather than generic computing implementations [4][5]. While very promising with regard to Privacy by Design, Secure Multiparty Computation does not overcome the general problems introduced by computation on depersonalized abstracted data, when compared to the use of original unaltered information.
The concept of a Trusted Server {TS} The basic idea to overcome the limitations of current practices is to create a fully-autonomous, manipulation-resistant, single-stage, simple-to-set-up and standard-compliant computation server that can be reviewed in any desired depth and approved as a generic method to work on sensitive data. The objectives are: 1. To replace invalidatable human-based trust with objective and verifiable machine-based trust. 2. To irrevocably seal and irreversibly encrypt the TS against any system access. 3. To have it work as a standard server suitable for a maximum variety of computational workflows. 4. To ensure no data input and output other than which is explicitly permitted is possible. 5. To grant Privacy by Design without the need for data depersonalization. To achieve this, the TS is set up without obfuscation. Full documentation of the system installation is disclosed at any desired level of detail to all parties concerned, ranging from configuration files to SHA-3 hashes to application source code to full disk image.
4/21
The readily installed system is then tested and validated to meet the intended requirements and objectives. Once approved, the system administrator activates the initialization scripts and reboots the TS. On reboot the TS automatically executes scripts locking it against all system access except for wanted data input and output, and the storage is rendered permanently inaccessible. Once the TS is running, the encryption key is destroyed so after power down or reboot the storage cannot be decrypted and data read out. After successfully sealing itself, the TS produces a snapshot of its state by calculating SHA-3 hashes of all files on disk and listing all relevant configuration files again. This information is published on the TS's own website so all parties having the previously disclosed setup documentation or disk images may validate that no secret configuration changes have been made between the setup and sealing processes. Thus easy and comprehensive validation is possible since it can be confirmed that the TS instance runs in exactly the intended configuration. Aside from the sealing process, which is executed by easily understandable linear shell scripts, the TS is a normally working Linux server that can run any compatible software just as a conventional server would. Basic installation, configuration as well as maintenance or changes are possible with standard administrative knowledge and within reasonable time-frames. Since the TS is sealed and irrevocably encrypted, usage of personal data inside the TS does not break privacy. That means, if data input is protected by encrypting transport protocols no depersonalization is required for secure data evaluation as long as the output results comply with privacy protection regulations. Since all configuration and processing applications are fully disclosed, the privacy compliance of output results can be guaranteed as well.
Reference Implementation As a real world demonstration a TS was set up to run a web-service, which is conventionally rather complex to establish. The service provides a truly anonymous web based message submission system which at the same time has full access-control, limiting usage to a distinct group of participants. All users, groups and
5/21
permissions are configured in an OpenLDAP directory running on a conventional server and are replicated to the TS during runtime. Authentication for the TS' services is completely done locally in the TS against its LDAP mirror. Thus neither authentication, access to the submission website or submitted content can be observed. To increase anonymity a submitter may access the TS from anywhere, for example an internet-cafe, so there is no relation between the submitting person and the IP address. Connecting through Tor network [6] to the TS is also possible to maximize privacy protection. Basically the solution works as follows: o
A generic TS is set up (see Methods section). On the TS an SSL-secured web submission application is installed consisting of a single text field to provide a text message and a submission button which sends the message without any additional information to a preconfigured Email address.
o
Access control is realized using the Apache2 webserver's LDAP authentication. The external LDAP directory information is supplied by a dedicated 'LDAP-syncrepl' replication to the TS, so all authentication takes place within the TS and no requests are directed to the master LDAP. Nevertheless, any changes to access permissions are immediately transferred to the TS.
o
The TS, after being initialized and sealed, runs the submission app with nobody having further system access and with irreversible encryption of the whole system. Every person with webaccess not only can submit anonymous messages, but also can review the TS's state either personally or with the help of others.
The reference implementation illustrates how easily computational processes can be implemented within one single server, that meet requirements which are considered conflicting in current information technology, such as truly anonymous LDAP authentication of named users.
The Millionaires' Problem In 1982 Andrew C. Yao introduced the Millionaires' Problem to theoretical informatics: "Two millionaires wish to know who is richer; however, they do not want to find out inadvertently any additional information about each other’s wealth. How can they carry out such a conversation?" [7].
6/21
Based on the anonymous web submission form and with a few changes the Millionaires' Problem has been solved in a very simple way: The SSL-encrypted web input form is replaced with a form containing two fields, one for the name and one for the value of assets along with a submission button. On every input the name-value pair is added to a table in human readable form, perfectly protected by the TS' privacy design. A script sorts the table by value and stores only the names to a text file which can be read immediately on the TS's website. Thus not only one of the challenges of theoretical informatics is brought down to common-level information technology but this solution is also highly generic. It will work for just two as well as for large numbers of submissions either open-to-the-public or, using LDAP replication, for a closed access-controlled user group.
Materials and methods Software The exclusive use of software with fully available source code is crucial for, at least theoretically, unlimited provability and verifiability. For our reference implementation we used Debian GNU/Linux (stable, main) as it is Free and Open Source Software (FOSS), both for sources and binaries. Depending on requirements other GNU/Linux or BSD flavors might qualify.
Structure
7/21
Fig.1: Physical structure of the Trusted Server.
The TS is a physical server with two dedicated disks. To minimize system components with proprietary firmware we choose hardware that works without proprietary drivers and firmware (i.e. running with software from Debian/main repository only). 1. Disk1 is dedicated to the physical machine and is encrypted with LUKS during Debian setup. Besides the basic Debian system QEMU-KVM virtualization is installed. 2. Disk2 is used as the dedicated system disk for a Virtual Machine {VM} and is also encrypted during Debian installation. A simple to remind low quality LUKS passphrase is acceptable for disk2. 3. After installation LUKS encryption for the VM is switched from a passphrase to a keyfile stored in /boot and automount [8]. At this stage the VM's disk boots just as a normal unencrypted disk without need to enter a passphrase. 4. An Apache2 webserver (https only) is installed on the VM to provide status information and a data input/output interface. 5. All user authentication and applications are installed on the VM and all computations are performed within the VM. For application setup the physical server is booted directly from disk2 so application administrators do not need access to the physical host system. 6. An external third USB boot disk with Debian is used to create, store and restore block-level disk images for disk1 and disk2.
8/21
7. The host-server has two dedicated network interfaces, one for the host instance and one for the guest virtual machine. The host-interface and IP is used for the backup/restore instance as well. 8. Once all user applications are installed a disk image is taken from both disks for easy restoration of the pre-sealing state.
The sealing process Irrevocably sealing the TS against any kind of access to system functions and internally stored data is the core concept of the TS. It is executed in two stages by scripts once activated running on boot.
Step 1 - Physical host: 1. Sets IPtables firewall and host access to block all network traffic except for localhost, then uninstalls SSH and removes all logon-users from /etc/passwd. 2. Removes all LUKS keys from its own encrypted disk. 3. Continues operating but after a power-down or reboot the disk is inaccessible by any means but brute force attacks since the passphrases in the keyslots are deleted [9]. However, an administrator might have a backup of the LUKS header and could restore the keyslots and be able to decrypt the disk. 4. Reencrypts disk2 with an automatically generated secret new volume key. 5. Creates SHA-3 hashes for all physical filesystems and stores the log in disk2:/boot 6. Copies all relevant configuration files (passwd, group, shadow, apache2 etc.) to disk2:/boot 7. Starts the virtual machine.
Step 2 - Virtual machine: 1. Sets IPtables firewall and host access to block all network traffic except for localhost and wanted external access (preferably https), uninstalls SSH and removes all logon-users from /etc/passwd. 2. Moves all host logs and configuration files stored in /boot to apache2's webroot 3. Removes all LUKS keys from its own disk.
9/21
4. Continues operating but on power down or reboot the disk is inaccessible without anyone knowing the volume key or having a header-backup, since volume key generation and disk reencryption was performed by the host system only after it had been sealed. 5. Creates SHA-3 hashes for all physical filesystems and stores the log to apache2's webroot 6. Copies all relevant configuration files (passwd, group, shadow etc.) to apache2's webroot 7. Starts apache2 webserver and sends an email informing that the sealing has finished, together with a link to the log directory provided by the webserver.
Initialization scripts executed on TS-Host 1. init_trusted_mode.sh (manually executed by administrator) set -x ## init trusted mode TS-Host ## -- ACTIVATE SEALING AFTER REBOOT -echo '/root/init_trusted_mode_reboot.sh > /root/0_init_trusted_mode_host.log 2>&1' >> /root/cron-reboot.sh ## -- REMOVE ONLY LOGON USER -userdel -f trust ## -- REMOVE HOST SSH ACCESS PERMISSION -rm /etc/hosts.allow ## -- UNMOUNT TS-VM BOOT PARTITION -reboot
2. cron-reboot.sh (automatically triggered from /etc/crontab: @reboot) #!/bin/bash ## cron-reboot TS-Host mount /dev/sdb1 /mnt iptables-restore
/root/iptables.v4
ip6tables-restore /root/iptables.v6 ## init trusted mode: /root/init_trusted_mode_reboot.sh > /root/0_init_trusted_mode_host.log 2>&1
10/21
3. init_trusted_mode._reboot.sh (called from cron-reboot.sh) set -x ## init trusted mode TS-Host reboot ## -- SWITCH IPTABLES OUTGOING POLICY TO DROP AND DELETE SSH PERMISSION -iptables -P OUTPUT DROP iptables -D INPUT 4 ## -- LIST IPTABLES -iptables-save iptables -L -n ip6tables-save ip6tables -L -n ## -- REMOVE SSH SERVER -apt-get -y purge openssh-server apt-get -y autoremove systemctl status sshd ## -- REMOVE ONLY LOGON USER - CREATES ERROR IF NOT REMOVED BEFORE REBOOT -userdel -f trust cat /etc/passwd cat /etc/shadow ## -- REMOVE DISK ENCRYPTION KEY -cryptsetup luksErase /dev/sda2 cryptsetup luksDump /dev/sda2 ## -- PRINT OLD VM KEY INFORMATION -cryptsetup luksDump /dev/sdb2 ## -- CREATE NEW KEY AND REENCRYPT TS-VM DISK -cryptsetup-reencrypt -v -d /mnt/keyfile -l 512 /dev/sdb2 ## -- PRINT NEW VM KEY INFORMATION -cryptsetup luksDump /dev/sdb2 ## -- CREATE ARCHIVES OF ETC AND ROOT FOR PUBLISHING -zip -r /mnt/etc-host.zip
/etc
zip -r /mnt/root-host.zip
/root
11/21
## -- LIST FILES AND SHA3 CHECKSUMS -ls -RlA / rhash -r --sha3-512 /boot rhash -r --sha3-512 /etc rhash -r --sha3-512 /home rhash -r --sha3-512 /lib rhash -r --sha3-512 /lib64 rhash -r --sha3-512 /lost+found rhash -r --sha3-512 /media rhash -r --sha3-512 /mnt rhash -r --sha3-512 /opt rhash -r --sha3-512 /root rhash -r --sha3-512 /sbin rhash -r --sha3-512 /srv rhash -r --sha3-512 /tmp ## since /usr/bin has X11 -> . recursive link: rhash
--sha3-512 /usr/bin/*
rhash -r --sha3-512 /usr/games rhash -r --sha3-512 /usr/include rhash -r --sha3-512 /usr/lib rhash -r --sha3-512 /usr/local rhash -r --sha3-512 /usr/sbin rhash -r --sha3-512 /usr/share rhash -r --sha3-512 /usr/src rhash -r --sha3-512 /var ## -- COPY LOG TO TS-VM BOOT PARTITION -cp /root/0_init_trusted_mode_host.log /mnt ## -- UNMOUNT TS-VM BOOT PARTITION -umount /mnt ## -- START TS-VM -virsh start debian9
12/21
Initialization script executed on TS-VM 1. cron-reboot.sh (automatically triggered from /etc/crontab: @reboot) #!/bin/bash # cron-reboot TS-VM iptables-restore
/home/trust/iptables.v4
ip6tables-restore /home/trust/iptables.v6 # init trusted mode: /home/trust/init_trusted_mode.sh > /var/www/log/1_init_trusted_mode.log 2>&1
2. init_trusted_mode.sh (called from cron-reboot.sh) set -x ## init trusted mode TS-VM ## -- REMOVE HOST ACCESS PERMISSION -rm /etc/hosts.allow ## -- SWITCH IPTABLES OUTGOING POLICY TO DROP AND DELETE SSH PERMISSION -iptables -P OUTPUT DROP iptables -D INPUT 5 ## -- LIST IPTABLES -iptables-save iptables -L -n ip6tables-save ip6tables -L -n ## -- REMOVE SSH SERVER -apt-get -y purge openssh-server apt-get -y autoremove systemctl status sshd ## -- REMOVE ONLY LOGON USER -userdel -f trust cat /etc/passwd cat /etc/group cat /etc/shadow
13/21
## -- REMOVE DISK ENCRYPTION KEY -cryptsetup luksErase /dev/vda2 cryptsetup luksDump /dev/vda2 ## -- MOVE HOST LOG AND ZIP TO WEBROOT -mv /boot/0_init_trusted_mode_host.log /var/www/log mv /boot/etc-host.zip /var/www/log mv /boot/root-host.zip /var/www/log chown www-data:www-data /var/www ## -- CREATE ARCHIVES OF ETC AND TRUST FOR PUBLISHING -zip -r /var/www/log/etc-vm.zip
/etc
zip -r /var/www/log/trust-vm.zip /home/trust ## -- SET PERMISSIONS TO APACHE2 -chown -R www-data:www-data /var/www ## -- LIST FILES AND SHA3 CHECKSUMS -ls -RlA / rhash -r --sha3-512 /boot rhash -r --sha3-512 /etc rhash -r --sha3-512 /home rhash -r --sha3-512 /lib rhash -r --sha3-512 /lib64 rhash -r --sha3-512 /lost+found rhash -r --sha3-512 /media rhash -r --sha3-512 /mnt rhash -r --sha3-512 /opt rhash -r --sha3-512 /root rhash -r --sha3-512 /sbin rhash -r --sha3-512 /srv rhash -r --sha3-512 /tmp ## since /usr/bin has X11 -> . recursive link: rhash
--sha3-512 /usr/bin/*
rhash -r --sha3-512 /usr/games rhash -r --sha3-512 /usr/include
14/21
rhash -r --sha3-512 /usr/lib rhash -r --sha3-512 /usr/local rhash -r --sha3-512 /usr/sbin rhash -r --sha3-512 /usr/share rhash -r --sha3-512 /usr/src rhash -r --sha3-512 /var ## -- ENABLE APACHE WEBSERVER -systemctl start apache2 ## -- SEND MAIL -echo $(date) >> /home/trust/date.txt mail -s "trusted server running @ 138.245.80.17"
[email protected] < /home/trust/date.txt
Machine-based trust The rhash-logs created after installation and the relevant configuration files are distributed to all parties concerned. In special cases when there is a limited number of participating parties, the full TS-host and VM disk images may be disclosed for validation. All configuration files and rhash-logs from the physical host and VM, which are stored in apache2's webroot, can be read by anybody permitted to access the TS website. They are provided as simple text-files that may be viewed online or downloaded for comparison with the original logs or SHA-3 hashes created from the original disk images or any other Debian system running the same software versions(fig.2).
15/21
Fig.2: Sample screenshot of the TS status log website. The modification dates show that various system log files are updated even after the sealing has finished showing the TS' actual state.
Customizing the VM for anonymous text submission For access control OpenLDAP is installed in mirror mode. The main external LDAP directory where credentials are stored pushes the LDAP directory data to the TS over a private network connection. The Apache2 webserver is configured for auth-ldap on localhost. A small web application is written in PHP which reads submitted text and forwards it to a predefined email-address without any additional information.
Customizing the VM for the Millionaires' Problem The installation is basically the same as for the anonymous text submission, but with an altered web application. The submit form provides two fields for name and asset value which are read to a table. 16/21
Afterwards the table is sorted by value and the names are output in that order to a text-file published by the webserver.
Backup/Restore procedure Since the TS is and remains inaccessible after initialization and since no intervention is possible during runtime, a complete reinstall is required after a system crash or whenever updates or changes are needed. To keep planned or unwanted downtimes as short as possible, the TS needs a reliable and fast backup and restore procedure. A basic Debian instance installed on external boot disk3 providing sufficient disk space and basic shell commands is all that is needed. Since backup disk images will never contain any sensitive information no security measures beyond usual are applied. Images are created and restored with dd so a lightweight console based installation is acceptable. The server is booted from disk3 and dd-images are created from both disk1 and disk2.
Online demo trusted server Credentials to access our demo TS' website are available on request to
[email protected]
Discussion and results Privacy by Design It can be said that any grade of privacy protection and security is relative. This of course is also valid for the TS. Its grade of protection depends on the quality and irrevocability of the VM disk2 encryption. LUKS is considered cryptographically strong [10] and without the key-slot keys it is impossible to decrypt the disk by means other than brute force - that is guessing the decryption key [11].
Verifiability
17/21
The entire TS implementation works without obfuscation - even disk encryption keys or passphrases may be disclosed since they are meaningless after initialization of the trusted mode. This is the basis on which trust is built upon. Anyone concerned in the review and validation process may be provided with fully working disk images of both host and guest VM for unlimited testing. The status report may list all relevant system files like passwd, group, shadow, startup scripts, webserver configuration and checksums from all files on disk. Linking to system log files in the webroot allows for continuously observing the server's state without compromising trust.
Tamper-resistance After testing and approval, the system administrators activate the initialization scripts. At that point they could change binaries or add scripts in the physical host or VM that could break security, for example by sending out the secret key and LUKS-header created during VM disk reencryption. Detailed review and comparison of the TS' state after installation and its state after sealing are crucial. Manipulations can be revealed by changes in SHA-3 hashes and by checking log files that are published on the TS's website.
Conceptual limitations The TS by design is not suitable for persistent data storage since on reboot or power down all data is lost. Data needed for computations may be uploaded and stored locally but have to be reloaded every time a new instance of the TS needs to be set up, prolonging restore time. Generally due to the required backup/restore/initialization procedure, downtimes caused by necessary system updates or changes will be longer compared to a conventional server. This drawback however is reduced or even inverted in multi-stage workflows when downtime is longer on multiple servers.
Technical limitations
18/21
Since at least the server BIOS and the CPU-Microcode will be closed source they might contain undocumented functions and backdoors, meaning absolute trust-to-the-last cannot be established with today's real-world computing hardware. Disk encryption using Solid-State-Disks is currently not proven to be cryptographically strong [12]. Theoretically proprietary wear levelling technology might be exploitable to obtain the secret encryption key or salt. Currently usage of SSDs in a TS is not recommended, unless break of privacy by highly skilled attackers is not a critical risk.
Operation As expected demo instances of the TS ran stable over months without any problems or dissimilarities to other Debian-based servers. Initialization scripts proved to be robust in dozens of iterations of the initialization-shutdown-restore-initialization cycle.
Security aspects It is important to understand that the concept of the TS is not primarily a security topic but an implementation of Privacy by Design. The TS is not in itself infinitely protected against security flaws, attacks or corruption. However, it does exactly and verifiably what it was set up for. Aside from enhanced privacy it shares the same strengths and weaknesses of a comparable conventional server. In our reference implementation a standard Debian GNU/Linux system is installed and secured with common onboard techniques including IPtables firewall and host access. GVFS or any auto-mounters for external storage have to be removed to prevent code injection from scripts running automatically when an external USB storage or CD/DVD is inserted. Depending on the individual scenario, additional means like hardening, creating custom kernels, using SELinux or AppArmour may and should be applied. Applications installed on the TS of course have to be carefully secured internally as well.
19/21
In cases when a full disk image is disclosed for review, it is possible that SSL transport encryption might be corrupted by a man-in-the-middle attack, since the private SSL key is disclosed. SSL encryption itself is not affected, but the identity of the TS has to be approved by additional means. The TS may be attacked physically in the same way any other server could be for example by ColdBoot or DMA attack. Therefore physically securing the server is necessary to exactly to the same extent as it would be for a conventional server with disk encryption in a given setting.
Conclusion The TS overcomes human-centric paradigms in privacy protection concepts. All current approaches are based on either trust or mistrust in single or multiple real persons. Accordingly they establish a network of trust, spreading information over multiple semi-trusted instances of human-driven institutions or in contrast using complex computation of fully encrypted data so nobody needs to trust anyone but themselves. For any given computational task, both methods require highly customized workflows compared to standard non-privacy-protected solutions. The TS provides a conventional computation environment that grants Privacy by Design independently from any individual. Since the TS behaves - despite self-sealing and irrevocable encryption - like any standard GNU/Linux based system, well established computational solutions can be run with the highest degree of privacy. Slightly prolonged downtimes for maintenance and changes are more than compensated for by quick and easy setup and minimized workflow customization.
References 1. REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016, Article 25. Official Journal of the European Union L 119/1. Available from: http://eurlex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679
20/21
2. Protecting Consumer Privacy in an Era of Rapid Change. Federal Trade Commission Report March 2012. Available from: https://www.ftc.gov/reports/protecting-consumer-privacy-erarapid-change-recommendations-businesses-policymakers 3. Article 29 Working Party Opinion 4/2007. ARTICLE 29 DATA PROTECTION WORKING PARTY. 01248/07/EN WP 136. Available from: https://www.parlementairemonitor.nl/9353000/1/j9vvij5epmj1ey0/vk48lqhqjkxn 4. Laud P, Kamm L. Applications of Secure Multiparty Computation. Chapter 12. Available from: http://ebooks.iospress.nl/volume/applications-of-secure-multiparty-computation 5. Hsiao-Ying Lin, Wen-Guey Tzeng. An Efficient Solution to The Millionaires’ Problem Based on Homomorphic Encryption. Available from: https://eprint.iacr.org/2005/043.pdf 6. Yao Andrew C. Protocols for Secure Computations. Available from: https://research.cs.wisc.edu/areas/sec/yao1982-ocr.pdf 7. About Tor. [cited 19. February 2018]. Available from: https://www.torproject.org/about/overview.html.en 8. Automatically unlock your LUKS-encrypted disk. [cited 19. February 2018]. Available from: https://dradisframework.com/pro/support/guides/customization/auto-unlock-luks-encrypteddrive.html 9. luksRemoveKey: Warning. cryptsetup (8) Linux man page. [cited 19. February 2018]. Available from: http://man7.org/linux/man-pages/man8/cryptsetup.8.html 10. Fruhwirth C. New Methods in Hard Disk Encryption, Available from: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.9522 11. Cryptsetup FAQ: 6.8 What happens if I overwrite the start of a LUKS partition or damage the LUKS header or key-slots? [cited 19. February 2018]. Available from: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects 12. Cryptsetup FAQ: 5.19 What about SSDs, Flash and Hybrid Drives? [cited 19. February 2018]. Available from: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5security-aspects
21/21
