This work is only targeting the security of Remote Desktop Connections, not command line access as it is utilizing the VRDP capabilities in VirtualBox. In addition, command line access to VM’s will not be possible since the VM’s are configured to access the network using NAT not Bridged networking so their IP’s will not be published and no one will be able to access them through the command line. If specific traffic is needed to be routed to a VM directly, Port Forwarding can be configured within the VirtualBox environment to handle this requirement.
In the following three sub-sections, we present a comparison between the original TPM authentication mechanism using a third-party privacy certificate authority, the new Direct Anonymous Attestation mechanism developed for TPM version 1.2 specifications and the proposed model in the scope of this work where we use TPM EK directly. We also provide a justification of why using any of the current TPM authentication mechanisms will not be possible for the overall proposed solution. 6.1.1 Original TPM Remote Attestation Mechanism
The original remote attestation mechanism for clients using TPM is as illustrated Figure (17) where any TPM enabled client need to follow the below steps to connect to a server [47]:
TPM enabled client sends its EK and AIK to a third party Privacy Certificate Authority (PCA) so that it verifies that the generated AIK is from a genuine TPM module
The PCA replies back with a certificate issued only to the originating EK for that specific TPM client
The TPM client then uses the supplied certificate from the PCA to access the required server
The server can now verifies that the connection request is from a genuine TPM client (without knowing any information about the client itself) and accordingly grant access to any requested service
47
Figure 17 TPM Remote Attestation Model
The original TPM remote attestation mechanism has the following characteristics: TPM creates different AIK’s for every access request to a server
The TPM AIK does not have an identifier for the originating client identity, the server will allow access from any client with a certified AIK from a PCA and accordingly the originating client is not known to the server accepting the connection
This original mechanism has some known problems that the PCA must be involved in all the transactions between the client and the server and accordingly it must be always available and at the same time must be well secured which is contradicting. In addition, if there is a privacy requirement then it may be at risk if the PCA and the verifying server exchange information directly which in that case will allow the server to directly identify the TPM client [48], [49].
In addition to that, since the verifying server must be trusting the PCA and is sure that it is issuing a certificate only to a valid TPM, this entails that PCA can’t be run by end users or private organizations [50].
6.1.2 Direct Anonymous Attestation Mechanism
With the problems raised against the original TPM remote attestation mechanism, IBM, Intel and HP worked together along with TCG to develop a new direct anonymous attestation mechanism that is available now with TPM version 1.2 specifications. This new mechanism is designed by Ernie Brickell of Intel, Jan Camenisch of IBM and Liqun Chen of HP [51].
48
DAA is aiming to provide a remote attestation procedure that does not provide a certificate from a trusted authority but instead use cryptographic proof that the connecting client has one [50].
DAA mechanism as illustrated in Figure (18) below works as follows [50]:
During the JOIN initial step, the DAA issuer will verify the TPM platform and then will issue DAA signature to the platform
The Platform will then proceed to the SIGN step where it proves to the verifier that it has a DAA signature from the issuer
Figure 18 DAA Mechanism
This mechanism possess the below characteristics: The DAA issuer and verifier cannot link
The DAA signature is only needed to be issued once by the issuer which can be a manufacturer or the organization owning the platform
The mechanism provides a black listing functionality to allow the verifier to block requests from TPM’s that are suspected to be fraudulent [52]
The platform transactions with the verifier are always anonymous but the mechanism allow a level of controlled privacy using Name Based solution between the platform and the verifier to be able to link transactions from the same platform to perform platform profiling and be able to block requests from a platform generating too many transactions
DAA provides a variety of balances between security and privacy by choosing one of the below models [51]:
49
o Named base – for non privacy-sensitive cases o A combination of both models
6.1.3 Proposed TPM Machine Authentication Mechanism
The characteristics of the original remote attestation mechanism does not allow for a true identification of the client attempting to access a server since with each new request a new different AIK will be created and verified by the PCA and sent to the server without any information on the requesting client.
In addition, with DAA complete anonymity and the ability to detect fraud TPMs seem to be opposing goals. Some compromise of anonymity must be made to allow fraudulent TPM keys to be detected by verifiers and even though an additional level of flexibility in terms of anonymity is available, still the identity of the client is not shown to the verifying server.
Since the main requirement for the proposed model is to reveal the identity of the client to the server directly to provide a client identification approach that we can use in a machine authentication mechanism, this proposed model will not be dependent on either the use of PCA / TPM AIK or the use of DAA.
Figure 19 Proposed TPM Authentication Mechanism
As illustrated in Figure (19) above, the proposed mechanism works as follows:
The client will send its TPM EK - which is a unique identifier of a client - along with the client machine name to the target server receiving the connection request The server will then authenticate the client against a pre-defined ACL that already contains a copy of the TPM EK for each authorized client along with the client machine name and a list of all virtual machines that this client has permissions to access
50
This proposed mechanism will guarantee that the server is aware of the identity of the hardware client attempting to connect and is authenticating it directly and granting the required access based on a well-known ACL.
Since privacy is a problem for security, having a highly secured environment entails a low level of privacy, and vice versa, there has to be somehow a compromise to ensure a level of security exists. Especially in private cloud environments where complete anonymity is not required to strengthen the security measures, the proposed mechanism can provide a good solution to organizations aiming to controlling access to their virtual environments across several teams and at the same time ensure that it is only accessed from authenticated hardware platforms with authenticated user accounts.