Presentation on theme: "Grid Security Alvaro Arenas e-Science Centre, RAL, UK CoreGRID Summer School 2006."— Presentation transcript:
Grid Security Alvaro Arenas e-Science Centre, RAL, UK CoreGRID Summer School 2006
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
Acknowledgement Some slides are based on presentations given by –Peter Gutmanns tutorial on security –Carl Kesselmann at GGF Summer School 2004 –Syed Naqvis tutorial at CGW 2006 –TrustCoM Project
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!
An Example 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 todays fastest PCs! Where will the experiments find such a computing power? Concorde (15 Km) Balloon (30 Km) CD stack with 1 year LHC data! (~ 20 Km) Mont Blanc (4.8 Km) Courtesy of CERN
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?
A Solution An advanced software that 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.
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 doesnt care) what computing resources are used to solve their problem.
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 cant deny it later –Confidentiality: Protection from disclosure to unauthorised persons
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
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
Services, Mechanisms, Algorithms A typical security protocol provides one or more services Services are built from mechanisms Mechanisms are implemented using algorithms
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
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
Key Management Problems Key certification Distributing keys –Obtaining someone elses 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
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
Key Distribution A Certification Authority (CA) solves this problem CA signs Alices key to guarantee its authenticity to Bob –Mallet cant substitute his key since the CA wont sign it
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 CAs only allow a subset of these types
Obtaining a Certificate (1) 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 2.CA verifies Alices signature on the key and ID information 3.Optional: CA verifies Alices ID through out-of-band means – /phone callback –Business/credit bureau records, in-house records
Obtaining a Certificate (2) 4.CA signs the public key and ID with the CA key, creating a certificate –CA has certified the binding between the key and ID 5.Alice verifies the key, ID, and CAs signature –Ensures the CA didnt alter the key or ID –Protects the certificate in transit 6.Alice and/or the CA publish the certificate
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
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
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
Grid Security Dynamic formation and management of VOs –Large, dynamic, unpredictable… VO Resources and users are often located in distinct administrative domains –Cant 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
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!
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
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
GSI – Authentication, Delegation 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 SSL for Authentication And message protection PKI (CAs and Certificates) SSL/ TLS Proxies and Delegation PKI for credentials Proxies and delegation (GSI Extensions) for secure single Sign-on
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
VO Lifecycle: Identification Identification Formation OperationDissolution 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) Bringing the VO Ecosystems to Grids: The TrustCoM Way
VO Lifecycle: Formation Identification Formation OperationDissolution 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
VO Lifecycle: Operation Identification Formation OperationDissolution 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
VO Lifecycle: Dissolution Identification Formation OperationDissolution 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)