GECEM Work Package 4 – Secure Remote Execution Report Chris I Dalton ([email protected]) Trusted Systems Lab / HP Labs October 2004 DESCRIPTION WP4 will enable an investigation into the properties necessary for secure remote execution of applications on grid type infrastructures. Specifically, WP4 will consider the security requirements of protecting both application code (algorithms) as well as application data and results from remote parties hosting the application computations. We will also consider protection from arbitrary third parties. DELIVERABLES A report describing the properties necessary for secure remote execution of applications with the specific security requirements of WP4 in mind. The report will also look at whether those properties can be achieved with current technology. If those properties cannot be achieved with current technology, the report will explore how the security requirements of WP4 might be relaxed so that the properties can be satisfied. We will look at the implications of any relaxation of security requirements proposed. 1 Introduction The GECEM (Grid-enabled computational electromagnetics) project is part of the UK e-science program aimed at exploring the use of Grid computing for advanced collaborative simulation-and- visualization in aerospace and defence design. The project collaborators are BAE Systems, the Singapore Institute of High Performance Computing (iHPC), Cardiff University, University of Wales, Swansea and Hewlett-Packard. This report focuses on the enhanced security requirements of the GECEM Grid environment, specifically the mechanisms necessary for enabling the secure remote execution of highly-proprietary applications. This is seen as an important Grid enabler, ensuring the protection of commercial organizations’ sensitive intellectual property, while still allowing them to take advantage of the Grid. We start by describing the GECEM demonstration architecture, showing how the need for secure remote execution fits into this architecture. We then give a brief overview of the current state of the Grid Security space, specifically the security framework of Globus GT2/GT3. This is the most popular Grid Middleware toolkit and is the middleware being used as a base for the GECEM architecture implementation. We move on to describe in more detail the specific requirements for secure remote execution. We map those requirements onto functionality provided by the Globus security framework and highlight the areas in which the framework is insufficient in meeting the needs of secure remote execution. The main body of the report then explores possible architectures and security mechanisms that would meet the needs of secure remote execution. We show that some of these requirements are easier to achieve than others and some are currently not possible to satisfy effectively without further research work. Finally, we take an alternative look at the issues around secure remote execution from a trust perspective. In the absence of sufficiently strong security mechanisms we discuss to what extent more pragmatic trust mechanisms may be used towards the goal of satisfying our secure remote execution needs. In particular we look at the concept of a virtual organization (VO) and possible technological contributions that can be used to strengthen that concept sufficiently to meet our needs. 2 GECEM Architecture In this section we describe the demonstration architecture of the GECEM project by way of an example workflow. We show where the requirement for secure remote execution fits into that architecture. The envisaged GECEM workflow process starts with engineers at BAE Systems generating a geometry file for the particular electromagnetic problem they are working on. A meshing service located at the University of Wales, Swansea is used to generate a mesh based on that geometry file generated by BAE Systems. A solver service is then invoked which passes both the mesh data and a solver executable application to a remote site (iHPC Singapore). The solver application is then run on a machine at Cardiff using the mesh data. Output files are then archived. Figure 1 shows the main trust boundaries and data flows based on the GECEM demonstration architecture. BAE USER Systems client Geometry Generator start(geometryURI) return solverURI Geometry Portal Data Service Service solve(meshURI) return solverURI Cardiff mesh(geometryURI) return meshURI Solver Solver Data Archive Service Service Mesher ? Service Swansea Mesher Data Simulation Service Service Singapore Swansea BAE data flows Input/Output control messages Swansea data (code) flows Figure 1 - GECEM Trust Boundaries and Data Flows The need for a secure remote execution capability relates to the step of migrating the solver application executable code from Swansea to a machine in iHPC Singapore where it is actually run. The application itself contains valuable intellectual property belonging to Swansea and it is vital that it can be afforded sufficient protection as it is transferred and executed outside of the Swansea domain of trust. 3 Globus Grid Security Overview In this section we look briefly at the Globus GT2/GT3 security framework [1] and the functionality it offers in the context of the GECEM architecture. GT2/GT3 is grid middleware toolkit used by the GECEM project. The heart of the GT2/GT3 security framework is GSI (Grid security infrastructure). The functionality provided by GSI broadly spans the security areas of authentication, authorization and confidential communication. GSI allows for security relationships to be set up that cross multiple organisational boundaries. It also allows for the delegation of security credentials so that Grid computations comprising of a number of different Grid resources can be carried out whilst only requiring a single “sign-on” by the initiating Grid user. GSI uses cryptography, notably certificate based public key cryptography to achieve its aims. In the context of the GECEM architecture shown in figure 1, GSI can be employed to solve a number of security problems. It can be used to ensure that communications between the various trust domains remain confidential. The mutual-authentication capability of GSI can be used to ensure that, for example, the geometry data from BAE Systems is actually being passed to the mesher service in Swansea and not some impostor trying to steal the sensitive BAE Systems data. The authorization and delegation features of GSI can be used to ensure, for example, that Swansea has the right (on behalf of an engineer in BAE Systems) to run their simulation code on a machine in iHPC Singapore. The GT2/GT3 security framework built around GSI is clearly a useful base for easing some of the main GECEM security concerns but as we shall see in the next section it not sufficient in itself for meeting all the needs of secure remote execution. 4 Secure Remote Execution In this section we go through an analysis of the GECEM security requirements surrounding the outsourcing of computation to remote computing infrastructures. We consider the needs of both the guest party (the owner of the computations) and the host party (the party that will run the computations on behalf of the guest). Having outlined both the guest and host party security requirements we discuss some possible architectures that go some way to addressing those issues. Using the services offered by the Globus GT2/GT3 security framework as a base, we suggest what additional components are required to provide a reasonably secure solution. We assume that the guest party and the host party infrastructures are independent and are separately owned and managed. We also assume that the host party does not provide dedicated resources to the guest party – that the guest party computations share the infrastructure used by the host party for host party’s own needs. Finally, to keep the discussion concrete we assume Linux is used as the base operating system platform by the host party1. 4.1 Security requirements for secure remote computation For analysis purposes, the security requirements of remote computation can be broken down into two areas: • The guest party requires that the remote computation be carried out in a secure manner. By that we mean that the remote hosting party should not be able to inspect application code (algorithms), the application data and also the results produced by the application whilst it is running on platforms under control of the host party. • The host party’s own computations, data manipulation, communications, etc. must be protected from the guest party when the guest party is running code on the host party’s computing infrastructure. It must be possible to contain the behaviour and resource access of the guest party within the host party infrastructure. For example, it should not be possible for the guest party to inject a virus into the host party’s infrastructure, or to access sensitive or private host party data. Some of these requirements are easier to achieve than others and some are currently not possible to satisfy effectively without further research work. 1 Although the same arguments apply to other OSes such as HP-UX, Sun Solaris, win2k, etc. Possible Architectures Any overall solution architecture to allow secure remote computation must encompass at least the following four aspects: • The remote platforms (i.e. physical computer and operating system) used to actually carry out the computations must have the right properties to satisfy the given guest and host party security requirements. • There must be some way for the guest party to verify that the host party platform(s) have the required properties. • The host party should be able to verify that the guest party is legitimate user of its resources. • The system as a whole should be protected from third party attacks. The next section looks individually at how these four main aspects of a solution architecture for secure remote execution might be realised. 4.2 Remote Platform properties The security properties of the remote platform where the computations will run are obviously a key part of any solution. The basic security properties of a platform are determined largely by the operating system that runs on the platform.