Grid Security Alvaro Arenas e-Science Centre, RAL, UK CoreGRID Summer School 2006

1. Grid Security Alvaro Arenas e-Science Centre, RAL, UK CoreGRID Summer School 2006

2. Overview • Introduction to Grids • Fundamentals on Security • Security Requirements, Mechanisms and Services • Key Management • Grid Security • Grid Security Requirements • OGSA Security • Grid Security Infrastructure • Security in the VO lifecycle

3. Acknowledgement • Some slides are based on presentations given by • Peter Gutmann’s tutorial on security • Carl Kesselmann at GGF Summer School 2004 • Syed Naqvi’s tutorial at CGW 2006 • TrustCoM Project

4. The Problem • Scientific domains like High Energy Physics (HEP) require a considerable amount of computing power, enormous storage space for their data and dynamic collaborations with other partners for their computations. • These requirements of scientific communities need to be effectively addressed!

5. Balloon (30 Km) An Example CD stack with 1 year LHC data! (~ 20 Km) Concorde (15 Km) Mont Blanc (4.8 Km) Courtesy of CERN • Large Hadron Collider (LHC) data correspond to about 20 million CDs each year! Where will the experiments store all of these data? • LHC data analysis requires a computing power equivalent to ~100,000 of today’s fastest PCs!  Where will the experiments find such a computing power?

6. Computing for LHC • Europe : 267 institutes – 4603 users • Elsewhere : 208 institutes – 1632 users • Computing centers, which were isolated in the past, should now be connected, uniting the global computing resources of particle physicists!  How these physicists collaborate dynamically? How these computing centers pool there resources?

7. A Solution • An advanced softwarethat ensures seamless communication between different computers and different parts of the world; • a search engine that not only finds the data the scientist needs, but also the data processing techniques and the computing power to carry them out; • distribute the computing task to wherever in the world there is spare capacity, and send the result to the scientist.

8. Why it is called GRID • GRID takes its name from analogy with electrical power Grid: • electricity on demand via wall socket • source unknown but reliable • transparency and resilience are keys to its success • The Grid vision is to allow users to tap into resources off the internet as easily as electrical power can be drawn from a wall socket. • The user is not aware (and doesn’t care) what computing resources are used to solve their problem.

9. Security • What is security? • Computer security deals with the prevention and detection of unauthorised actions by user of a computer system - D. Gollmann • Security Requirements • Authentication: Assurance of identity of person or originator of data • Access Control: Unauthorised users are kept out • Integrity: Maintaining data consistency • Availability: Legitimate users have access when they need it • Non-repudation: Originator of communications can’t deny it later • Confidentiality: Protection from disclosure to unauthorised persons

10. Security Mechanisms • Three basic building blocks are used: • Encryption is used to provide confidentiality, can also provide authentication and integrity protection • Digital signatures are used to provide authentication, integrity protection, and non-repudiation • Checksums/hash algorithms are used to provide integrity protection, can provide authentication • One or more security mechanisms are combined to provide a security service

11. Security Services • From the OSI definition: • Access control: Protects against unauthorised use • Authentication: Provides assurance of someone's identity • Confidentiality: Protects against disclosure to unauthorised identities • Integrity: Protects from unauthorised data alteration • Non-repudiation: Protects against the originator of communications later denying it

12. Services, Mechanisms, Algorithms • A typical security protocol provides one or more services • Services are built from mechanisms • Mechanisms are implemented using algorithms

13. Public-Key Encryption • Uses matches public/private key pairs • Anyone can encrypt with the public key, only one person can decrypt with the private key

14. Key Management • Key management is the hardest part of cryptography • Two classes of keys • Short-term session keys • Generated automatically and invisibly • Used for one message or session and discarded • Long-term keys • Generated explicitly by the user • Long-term keys are used for two purposes • Authentication (including access control, integrity, and non-repudiation) • Confidentiality (encryption) • Establish session keys • Protect stored data

15. Key Management Problems • Key certification • Distributing keys • Obtaining someone else’s public key • Distributing your own public key • Establishing a shared key with another party • Confidentiality: Is it really known only to the other party? • Authentication: Is it really shared with the intended party? • Key storage • Secure storage of keys • Revocation • Revoking published keys • Determining whether a published key is still valid

16. Key Distribution • Alice retains the private key and sends the public key to Bob • Mallet intercepts the key and substitutes his own key • Mallet can decrypt all traffic and generate fake signed message

17. Key Distribution • A Certification Authority (CA) solves this problem • CA signs Alice’s key to guarantee its authenticity to Bob • Mallet can’t substitute his key since the CA won’t sign it

18. Certification Authority (CA) • A CA guarantees the connection between a key and an end entity • An end entity is • A person • A role (“Director of marketing”) • An organisation • A pseudonym • A piece of hardware or software • An account (bank or credit card) • Some CA’s only allow a subset of these types

19. Obtaining a Certificate (1) • Alice generates a key pair and signs the public key and identification information with the private key • Proves that Alice holds the private key corresponding to the public key • Protects the public key and ID information while in transit to the CA • CA verifies Alice’s signature on the key and ID information • Optional: CA verifies Alice’s ID through out-of-band means • email/phone callback • Business/credit bureau records, in-house records

20. Obtaining a Certificate (2) • CA signs the public key and ID with the CA key, creating a certificate • CA has certified the binding between the key and ID • Alice verifies the key, ID, and CA’s signature • Ensures the CA didn’t alter the key or ID • Protects the certificate in transit • Alice and/or the CA publish the certificate

21. How can we secure the Grid? • The sharing and virtualisation of computer resources, lead to challenging security requirements: • Data will move through, and be accessed from, many different countries with different security mechanisms in place at each centre • The community requiring access to the data spans multiple organisations and countries • Trust must be established and expressed between different centres, from which remote access policies must be derived • Data integrity and confidentiality can be crucial • Users may need the authority to submit jobs that require nontrivial SLAs to match the available resources with the associated access right to each of these resources in different administrative domains

22. Virtual Organisations (VOs) • A VO can be seen as a distributed organisation which has the task of managing access to resources that are accessed through computer network and located in different domains • VOs are used as a bridge to provide Grid security solution based on trust • The extent to which a participant can rely on others to behave • Root of the trust • CAs are used to root certificate-based identity mechanisms • Delegation mechanisms: one entity assigning rights to another • Reputation management to create and monitor trust relationships

23. The Grid Security Solution • Instead of setting up trust relationships at the organisational level (lots of overhead, possible legalities - expensive!) set up trust at the user/resource level • VOs for multi-user collaborations • Federate through mutually trusted services • Local policy authorities rule • Users able to set up dynamic trust domains • Personal collection of resources working together based on trust of user

24. Grid Security • Dynamic formation and management of VOs • Large, dynamic, unpredictable… • VO Resources and users are often located in distinct administrative domains • Can’t assume cross-organizational trust agreements • Different mechanisms & credentials • X.509 vs Kerberos • X.509 vs. X.509 (different domains), • X.509 attribute certs vs SAML assertions • Standardisation of interfaces to allow for discovery, negotiation and use

25. Grid Security • Interactions are not just client/server, but service-to-service on behalf of the user • Requires delegation of rights by user to service • Services may be dynamically instantiated • Implementation must be broadly available & applicable • Standard, well-tested, well-understood protocols; integrated with wide variety of tools • Policy from sites, VO, users need to be combined • Varying formats • Want to hide as much as possible from applications!

26. OGSA Security • Secure functionality should be cast as services • allowing applications to locate and use the particular functionality they need • Leverage on existing and emerging WS security standards • Authentication service; • Identity mapping service • Authorisation service; • VO Policy service; • Credential conversion service; • Audit service; etc

27. Grid Security Infrastructure (GSI) • An OGSA-based Grid security architecture • Globus Toolkit proposed and implements the GSI • Protocols and APIs to address Grid security needs • Based on public-key encryption technology • SSL protocol for authentication, message protection • CAs allow one-way, light-weight trust relationships (not just site-to-site) • X.509 certificates • Each user as a Grid id, a private key, and a certificate signed by a CA

28. GSI – Authentication, Delegation Proxies and delegation (GSI Extensions) for secure single Sign-on Proxies and Delegation SSL for Authentication And message protection SSL/ TLS PKI (CAs and Certificates) PKI for credentials • GSI defines a credential format based on X.509 identities certificates for authentication • An X.509 certificate + private key form a unique credential • Used by a Grid entity to authenticate itself to other Grid entities • Each certified is issued by a CA • X.509 proxy certificates for delegation • Allows a process to act on behalf of a user • Allow a user to assign dynamically a new X.509 identity to an entity and the delegate some subset of their rights to that identity • Users create and sign their own proxy certificate, rather than CA

29. GSI- Authorisation • Detailed user rights assigned: • User can have certain group membership and roles • Involved parties: • Resource providers. • Keep full control on access rights. • The users Virtual Organisation • Member of a certain group should have same access rights independent of resource. • Resource provider and VO must agree on authorisation: • Resource providers evaluate authorisation granted by VO to a user and map into local credentials to access resources

30. VO Lifecycle: Identification Identification Formation Operation Dissolution Bringing the VO Ecosystems to Grids: The TrustCoM Way • VO Identification • Analyse BP template, identify roles and deduce VO security requirements • Select collection of service providers matching these requirements (incl. assessing trustworthiness) • Service Providers negotiate security requirements (incl. verifying conflict with local security policies) • Correlation of individual responses to ensure collectively fulfillment of VO requirements • Technologies • To represent business collaboration: WS-CDL, BPEL4WS • Looking at repositories for selecting partners: WSDL/UDDI • Contract management (SLA): WSLA • Global Agreement - WS-Agreement (to be investigated) • Secure communication: WS-Security • SOAP message security (XML signature, XML encryption, tokens)

31. VO Lifecycle: Formation Identification Formation Operation Dissolution • VO Formation • Dissemination of VO security policy • Mapping to local security policy and mechanisms • Dissemination of security adaptation policies • Setup security federation: disseminate necessary security tokens • Setup VO registries and security services • Technologies • To describe policies: WS-Policy, XACML • WS-Policy is a mechanism to publish and attach a policy to a web service; a policy language (“grammar”) – however no aligned with WSLA • To support federation: WS-Federation, WS-Trust • WS-Federation provides models for federated identity, authentication and authorisation; adds pseudonym and attribute services • WS-Trust is a generic protocol to request, issues, validate, exchange security tokens

32. VO Lifecycle: Operation Identification Formation Operation Dissolution • VO Operation • Enforce and monitor VO security policies (as well as local ones) • Monitor service performance (to be used as evidence when constructing the reputation of service providers) • Maintain and distribute trust and security context • Dynamically adapt roles and policies in response to e.g. violations (incl. trust re-assessment) • Technologies • Monitoring and notification mechanisms: WS-Eventing, WS-Notification • Trust assessment: out of scope of WS specs – assume there is a trust relationship • In relation to WS specs, there is little work in the area of adaptive security

33. VO Lifecycle: Dissolution Identification Formation Operation Dissolution • VO Dissolution • Resolve federation • Revoke security tokens • Invalidate VO security contexts • Remove VO security service entries • Preserve history as agreed, e.g., audit trail, provenance information, VO agreements, reputation. • Technologies • Related to the technologies mentioned in other phases • Usually revocation and invalidation have to be done manually • Lack of specifications for history information (needed for audit and reputation)

34. Thanks ! http://www.eu-trustcom.com A.E.Arenas@rl.ac.uk