OpenTC CC@H - TEST INSTRUCTIONS =============================== Authors: William Piras and Gianluca Ramunno, Politecnico di Torino (2008), part of the Open Trusted Computing project, http://www.opentc.net. Release: 20080715 for otc-suse-ccah-1.0 LICENSE ------- This work is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License. You are free: * to Share - to copy, distribute and transmit the work * to Remix - to adapt the work Under the following conditions: * Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). * Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. To view a copy of this license, visit: http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. To view a copy of the Legal Code (the full license), visit: http://creativecommons.org/licenses/by-sa/3.0/legalcode DISCLAIMER of WARRANTY ---------------------- The following disclaimer applies to "OpenTC CC@H Proof of Concept prototype" (shortly CC@H PoC), the object of these test instructions. The following software: "OpenTC CC@H Proof of Concept prototype" is experimental and is provided "as is", and no guarantee or warranty is given by the Open_TC consortium that the software is fit for any particular purpose. The user thereof uses the software at its sole risk and liability. The Open_TC consortium shall have no obligation to maintain or support this software. THE Open_TC CONSORTIUM MAKES NO EXPRESS OR IMPLIED WARRANTY OF ANY KIND REGARDING THIS SOFTWARE. The Open_TC CONSORTIUM SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, IN CONNECTION WITH OR ARISING OUT OF THE FURNISHING, PERFORMANCE OR USE OF THIS SOFTWARE. The Open_TC Consortium consists of the following partners: Technikon Forschungs- und Planungsgesellschaft mbH Infineon Technologies AG Hewlett-Packard Ltd HP UK IAIK, Graz University of Technology Lehrstuhl f¨ur Datenverarbeitung, Technische Universit¨at M¨unchen SUSE Linux Products GmbH Royal Holloway and Bedford New College ITAS, Forschungszentrum Karlsruhe GmbH TUBITAK, National Research Institute of Electronics & Cryptology Politecnico di Torino Budapest University of Technology and Economics Commissariat `a l’Energie Atomique-LIST Horst Goertz Institute for IT Security, Ruhr-University Bochum Technische Universitaet Dresden University of Cambridge Computer Laboratory, University of Cambridge IBM Research GmbH Institute for Security and Open Methodologies Advanced Micro Devices Portakal Teknoloji Egitim Danismanlik Yazilim Turizm Taahhut INTEK Technical University of Sofia WARNINGS -------- This "test instructions" document covers the whole process from the boot of the platform to the remote attestation and the setup of a VPN. Either taking ownership of the TPM or setting the proper passwords is a required operation to perform the tests described in this document. Taking the ownership is an operation with permanent effects to be executed on a TPM that has never been used and has been enabled for the first time, or after the TPM has been cleared. Important note: clearing the TPM is an irreversible operation that causes the loss of the keys and data previously protected by the TPM; therefore this operation must be done only on platforms used for testing purposes. Experienced users might want to test this live CD on platforms in production that do not make use of the TPM. In so doing, these users act at their own risk. Please carefully read the "known problems" section in the README file available from the root of the CD file system or from the download server. No responsibility for the Open_TC consortium and the partners that contributed to this live CD for any mistaken use or damage occurred. Before starting the test procedure, the user should read the complete disclaimer of warranty provided at previous section: if the user does not agree in full about such disclaimer, he should not use the OpenTC CC@H Proof of Concept prototype live CD. Note that clearing the TPM should also result in disabling it. Therefore the user will then have to re-enable the TPM before rebooting. Clearing and re-enabling the TPM are operations to be done via the BIOS. Since the details of these operations vary from platform to platform, a detailed procedure is not provided in this document. The remote attestation process (section 8) requires a complex procedure. Should any error occur, the user must write down the problem, the output of the TC proxies and anything else that may be important. All these information should be then reported to the OpenTC Consortium. Should the remote attestation fail, the user can retry the procedure and report the problem if it occurs again. Always restart the TC proxies before trying again the procedure. Should the problem persist, the user can also perform again all steps described in section 7. Finally the prototype is far from being ready for any use in critical security corporate infrastructures, and there is no claim for this kind of readiness. The intention is to show what can be done with the Trusted Computing technology components that are available on Linux today; aspects such as deployment, certificate management, configuration management, deployment and lifecycle management are mostly disregarded. INTRODUCTION ------------ A live CD containing a proof of concept for the CC@H application scenario has been developed within the frame of the OpenTC project. The present test instructions help the user test the bootable otc-suse-ccah-1.0 live CD (and the user-generated installation for hard disk when the build scripts will be made available to the general public). The user should follow the steps in the same order they are presented and (if wanted) can report the results to the Open_TC Consortium: in this case the user should also describe the platform he is using. However any kind of feedback is welcome. Corporate Computing at Home (CC@H) is the application scenario selected for the second period. The proof of concept prototype aims to demonstrate the Trusted Computing use case of a VPN solution based on Trusted Virtual Domain (TVD) concept that serves as an attestable platform for secured corporate usage side by side with private applications. Details can be found about: - CC@H scenario and PoC in all articles from issue n. 5 of the OpenTC newsletter: http://www.opentc.net/publications/OpenTC_Newsletter_05.html NOTE: the Corporate compartment with MS Windows shown in the figures is not distributed with the prototype - TVD concept and CC@H PoC in the article "From Trusted Platforms to Trusted Virtual Domains" from issue n. 6 of the OpenTC newsletter: http://www.opentc.net/publications/OpenTC_Newsletter_06.html In the current version the CC@H scenario is implemented with Xen only; however a bootable L4-Linux system running upon Fiasco micro-kernel is also available on the live CD. Two physical platforms (client and server) are required to perform the tests described in this document. The following components run on: - client: Corporate Linux and Multimedia Player as different virtual machines; TVD and TC proxies as different processes running in dom0 - server: TVD master (implemented as web server in domS and TC proxy in dom0) and Corporate Service (implemented as another web server in domS and VPN endpoint in dom0) CONVENTIONS ----------- - {client} means that the operations must be performed only on the client platform - {server} means that the operations must be performed only on the server platform - {client and server} means that the operations must be performed on both client and server platforms, but the commands are identical, therefore they are described only once - {client-server} means that the operations must be performed on both client and server platforms, but the commands are (partially) different, therefore they are described in full for both platforms - represents the IP address client's dom0 is automatically assigned by a DHCP server or manually set by the user (see section 3) - represents the IP address server's dom0 is automatically assigned by a DHCP server or manually set by the user (see section 3) NOTE: if the execution of a shell command is required, then: - [ACTION] open a terminal window (right click on desktop -> Xterm) - [INFO] the default directory will be /root - [ACTION] type the command following the symbol "#" PREPARATION ----------- ==>> The following actions will have permanent effects, therefore they have to be performed only once. 0) Prerequisites and setup {client and server} - two platforms connected to a _wired_ network - preferably a DHCP server available on the network: the deployed IP addresses must belong to a different range than 172.31.254.1 - 172.31.254.4 NOTE: while performing the steps described in this document, at any time the following command can be used to list all PCR values # otc-pcrs 1) Boot the platform {client-server} - [ACTION] boot the client platform (select 'Xen' then 'config #1: vpnClient') - [ACTION] boot the server platform (select 'Xen' then 'config #2: vpnServer') 2) TPM setup: set Owner and SRK passwords {client and server} - [INFO] the following TPM passwords must be respectively set for TPM Owner and Storage Roor Key (SRK): ownerpwd srkpwd - [ACTION] if the TPM is not owned yet (it must be however previously enabled via BIOS), then take the ownership: # tpm_takeownership upon request, enter and re-type the requested Owner and SRK passwords. - [ACTION] if the ownership was already taken but the passwords for TPM Owner and/or SRK are different from the required ones, instead of clearing the TPM and taking the ownership again, just use either or both the following commands to respectively change the TPM Owner and/or the SRK: # tpm_changeownerauth -o # tpm_changeownerauth -s upon request, enter the Owner and/or the SRK password. - [INFO] in case of any problem with the TPM credentials (i.e. Owner password forgotten, TPM timeout due to failed authentication attempts), it is possible to clear the TPM via BIOS, then it can be owned again and the passwords set to the required ones ==>> The following actions will have: - (Hard disk) permanent effects until a fresh prototype will be created: therefore they have to be performed whenever a new prototype is created - (LiveCD) temporary effects until the next reboot; therefore they have to be performed whenever the LiveCD is booted 3) Network setup for the physical platforms {client and server} - [INFO] if a DHCP server is available on the physical network this step can be skipped and client's and server's dom0 will be respectively assigned and IP addresses; otherwise the latter must be manually set for both client and server platforms according to the following procedure: - [ACTION] rename the interface template to the actual configuration file # mv /etc/sysconfig/network/_ifcfg-eth0.nodhcp \ /etc/sysconfig/network/ifcfg-eth0 - [ACTION] edit the configuration file and set the correct IP address and network mask for the physical platform (i.e. dom0) # vi ifcfg-eth0 - [ACTION] rename the route template to the actual configuration file # mv /etc/sysconfig/network/_routes /etc/sysconfig/network/routes - [ACTION] edit 'routes' and set the IP address of the default gateway # vi /etc/sysconfig/network/routes - [ACTION] restart dom0's network interface # ifdown eth0; ifup eth0 - [ACTION] start net4vlc service (i.e. create an additional interface for the communications between the virtual machines) # service net4vlc start - [ACTION] verify if a duplicated route for 172.31.254.0 is present in the routing table # route -n - [ACTION] delete, if present, the duplicated route from the routing table # route del -net 172.31.254.0/24 eth0 - [ACTION] edit the resolver configuration file and set the IP address(es) of the name server(s) # vi /etc/resolv.conf - [ACTION] verify the connectivity between the client and server platforms; either on client's dom0: # ping or on server's dom0: # ping 4) Sealing the control icon {client} - [ACTION] seal one icon among the four provided # otc-sealicon icons/icon_0x.png where x can be between 1 and 4 5) Preparing domU: encrypting RW partition, sealing encryption key, updating TVD policy {client} - [ACTION] (LiveCD only) create empty RW partition for domU and patch domU's config file for this second virtual disk # otc-prep-domU-LiveCD - [ACTION] encrypt domU's RW partition # otc-prep-domU-disk when requested to input a password, choose one (e.g. 'otcotc') and type it: it must be used during the next step - [ACTION] seal encryption key for RW partition (SRK password must be provided) # otc-prep-domU-key srkpwd when requested, type and re-type the password previously chosen - [ACTION] update TVD policy with domU's measurement and IP address of VPN endpoint # otc-prep-domU-tvd from the previous command's output copy the value of TVD hash (last line) and replace the value in the following file # vi /etc/otc-tvd.policy.xml - replace the hash value within the following XML tag: ... - insert the IP address of the server platform, i.e. , within the following XML tag (the inner one, enclosed in the tag ... ): ... [INFO] this is the address of the VPN endpoint, which runs in server's dom0 6) copy the TVD policy to the TVD master (on server's domS) {client-server} - [INFO] the file otc-tvd.policy.xml must be copied from client's dom0 to server's domS, in the directory /srv/www/policyServer; since domS on the server platform in not directly reachable from the client via physical network, the copy must be performed in two steps - [INFO] domS virtual machine is automatically started at boot on the server platform (and within domS also the 'ssh' daemon) - [ACTION] start the 'ssh' daemon on server's dom0 # service sshd start NOTE: should the first attempt fail, just retry - [INFO] beware: the root account's password is set to null! Therefore anyone can virtually connect as root to the server platform! - [ACTION] (from client's dom0 console) copy the file otc-tvd.policy.xml from client's dom0 to server's dom0 # scp /etc/otc-tvd.policy.xml :/root NOTE: at the first time type 'yes' to accept the RSA public key of the counterpart; then just press upon password's request (because root's password is set to null) - [ACTION] (from server's dom0 console) copy the file otc-tvd.policy.xml from server's dom0 to server's domS # scp /root/otc-tvd.policy.xml 172.31.254.4:/srv/www/policyServer/ NOTE: at the first time type 'yes' to accept the RSA public key of the counterpart; then just press upon password's request (because root's password is set to null) 7) configure and start TC proxies {client-server} - [INFO] to obtain the TVD policy (otc-tvd.policy.xml) the TVD proxy must be remotely attested by TVD master. The latter is emulated via web server. The remote attestation is performed through a pair of Trusted Channel (TC) proxies running in dom0 on both client and server platforms; these proxies then establish a tunnel over SSL to let the TVD proxy download the TVD policy from the TVD master. 7a) configure and start TC proxy on the server platform {server} NOTE: all commands must be performed from server's dom0 console, if not otherwise specified - [ACTION] extract EK certificate from TPM and install it # otc-prep-tcproxy-certEK - [INFO] now the TC proxy must be configured on the server platform: an Attestation Identity Key (AIK) will be created and locally certified; moreover the IP address of the other endpoint will be set - [ACTION] generate AIK and TC proxy configuration file on the server # otc-prep-tcproxy-config local 172.31.254.4 NOTE: 172.31.254.4 is the domS network interface which the web server emulating the TVD master is listening on - [ACTION] extract server-side known good values (i.e. the digest of the current PCR values) # otc-prep-tcproxy-extract-goodvalues - [ACTION] (from the client's dom0 console) copy the server known good values to the client platform # scp :/root/CCAH-server-values \ /usr/share/tcproxy/known-good-values/CCAH-server/ NOTE: at the first time type 'yes' to accept the RSA public key of the counterpart; then just press upon password's request (because root's password is set to null) - [ACTION] start the server-side TC proxy # cd /usr/share/tcproxy; ./start_server.sh NOTE: the script 'start_server' must be executed from '/usr/share/tcproxy' set as current working directory NOTE: the TC proxy is started as foreground process, therefore the debug messages it outputs can help the reader understand what is happening "behind the scene"; to execute further console commands another terminal window must be opened; to stop the process, just press CTRL-C 7b) configure and start TC proxy on the client platform {client} - [ACTION] extract EK certificate from TPM and install it # otc-prep-tcproxy-certEK - [INFO] now the TC proxy must be configured on the client platform: an Attestation Identity Key (AIK) will be created and locally certified; moreover the IP address of the other endpoint (i.e. the server-side TC proxy) will be set - [ACTION] generate AIK and TC proxy configuration file on the client # otc-prep-tcproxy-config local - [ACTION] extract client-side known good values (i.e. the digest of the current PCR values) # otc-prep-tcproxy-extract-goodvalues - [ACTION] copy the client known good values to the server platform # scp /root/CCAH-client-values \ :/usr/share/tcproxy/known-good-values/CCAH-client/ NOTE: at the first time type 'yes' to accept the RSA public key of the counterpart; then just press upon password's request (because root's password is set to null) - [ACTION] start the client-side TC proxy # cd /usr/share/tcproxy; ./start_client.sh NOTE: the script 'start_client' must be executed from '/usr/share/tcproxy' set as current working directory NOTE: the TC proxy is started as foreground process, therefore the debug messages it outputs can help the reader understand what is happening "behind the scene"; to execute further console commands another terminal window must be opened; to stop the process, just press CTRL-C 8) configure and start the TVD proxy on the client platform {client} - [INFO] the TVD proxy, when started, tries to retrieve the TVD policy from the TVD master; this operation is performed over a Trusted Channel, established after a successful mutual remote attestation; once the policy has been downloaded, the TVD proxy enforces it: it checks that the virtual machine (like Corporate Linux) wanting to join a TVD has the correct measurements stated in the TVD policy (see section 5) - [ACTION] modify the script /usr/bin/otc-start-tvd # vi /usr/bin/otc-start-tvd and set the third parameter to the URI of the TVD policy file on the server (i.e. replace '/etc/otc-tvd.policy.xml' with): http://localhost:5001/otc-tvd.policy.xml NOTE: the TC proxy on the client-side is listening on port TCP 5001; when a connection is established to this local port from the TVD proxy, the TC proxy establishes a Trusted Channel with the server TC proxy, which in turn connects to the web server emulating the TVD master - [ACTION] start the TVD proxy # otc-start-tvd NOTE: the TVD proxy is started as foreground process, therefore the debug messages it outputs can help the reader understand what is happening "behind the scene"; to execute further console commands another terminal window must be opened; to stop the process, just press CTRL-C NOTE: in case of failure of the remote attestation, stop and restart the TVD proxy; if the failure occurs again, then read the WARNINGS section - [INFO] at the startup of the TVD proxy, the mutual remote attestation is performed; if successful, the TVD policy file otc-tvd.policy.xml is downloaded from the TVD master (i.e. domS on the server platform); whenever the TVD policy is modified in domS, the TVD proxy must be stopped and restarted to reload the policy (no need to restart the TC proxies) 9) configure and re-start the compartment manager on the client platform - [INFO] the compartment manager is started at boot with a security policy which does not provide the usage of the TVD; the policy must be updated to enable the TVD mechanisms and reloaded by restarting the compartment manager - [ACTION] to enable the usage of TVD to establish a VPN, the security policy file must be updated, i.e. the last line (tvd = OPENTC) uncommented by deleting the character '#' # vi /etc/otc-cmpmgr.policy - [ACTION] restart the compartment manager to reload the policy # otc-start-compmgr NOTE: the compartment manager is started as foreground process, therefore the debug messages it outputs can help the reader understand what is happening "behind the scene"; to execute further console commands another terminal window must be opened; to stop the process, just press CTRL-C ==>> Now everything is ready for the demo, therefore: - (Hard Disk) continue without rebooting; however it is possible to reboot the system without loosing the configuration; the only operations to be performed after a reboot before performing the actual demos are starting the server and the client TC proxies, and the TVD proxy; the compartment manager, instead, will be automatically started at boot with the updated policy - (LiveCD) continue without rebooting ACTUAL DEMOs {client} --------------------- A) Demo Corporate Linux - [ACTION] click on the "Power" button for "Corporate Linux", after a while on the trusted bar the user is requested to respectively input username and password for the VPN authentication; the user must type: opentc pass then the VPN is created with the remote endpoint and the virtual machine will be actually started and plugged into the TVD private network with the IP address 10.0.0.1; - [INFO] before the prompt for VPN credentials is displayed, the compartment manager first measures the Corporate Linux root file system, then tries to unseal the read/write virtual disk (encrypted with the operations described in section 5); then, upon checks performed by TVD proxy, the virtual machine is admitted to the TVD network and the VPN with the remote endpoint is set up - [ACTION] open the browser (right click on the desktop) and connect to: http://10.0.0.2/ if all previous steps were correct, it should be possible now to see the "CC@H: OpenTC corporate server via TVD network" home page, downloaded through the TVD private network - [ACTION] click on the "Power" button for "Corporate Linux" to stop it B) Demo Player - [ACTION] click on the "Power on" power on button for "Player" to start it - [INFO] once the gray background is displayed, after a while the VLC player will be started - [ACTION] click on "File" menu on the player, select "Quick Open File" - [ACTION] select 'A-New-Computer-med.ogg' and click on "Open" button Double click on the video window for the full screen (and once again on the video area if the gray window does not disappear), double click again for normal size - [ACTION] click on the "Power" button for "Player" to stop it NOTE: demos A) and B) can be performed any number of times and in any sequence; when both "Corporate Linux" and "Player" virtual machines are running it is possibly to alternatively display either VM screen by clicking on the title buttons. KNOWN PROBLEM: at the second play of the videoclip, the soundtrack is not played anymore until the next reboot C) Demo control icon (Hard disk only) - [INFO] show that changing a boot parameter results in the failure of the unsealing) - [ACTION] reboot the platform, when GRUB menu is displayed - [ACTION] select CC@H - Xen - [ACTION] select config #1 (vpnClient) - [ACTION] press soon ESC - [ACTION] edit the configuration press 'e' select the line with Linux kernel press 'e' type anything (e.g. 'dummy') press press 'b' - [INFO] because of the changed configuration, measured by tGRUB, the icon cannot be unsealed (three exclamation marks on a red background are instead displayed)