ESRIN Grid Workshop Tutorial

ESRIN Grid Workshop Tutorial
Introduction to Grid Computing Frascati, 3 February 2005 Security on Grid: Presented by Roberto Puccinelli Based on INFN-GRID/EGEE User Tutorial EGEE is a project funded by the European Union under contract IST

Overview Glossary Encryption Certificates Grid Security
Symmetric algorithms Asymmetric algorithms: PKI Certificates Digital Signatures X509 certificates Grid Security Basic concepts Grid Security Infrastructure Proxy certificates Command line interfaces Virtual Organisation Concept of VO and authorization VOMS, LCAS, LCMAPS Security in action LCG/EGEE User tutorial, Torino (Italy) – January

Glossary Principal Credentials Authentication Authorization
An entity: a user, a program, or a machine Credentials Some data providing a proof of identity Authentication Verify the identity of the principal Authorization Map an entity to some set of privileges Confidentiality Encrypt the message so that only the recipient can understand it Integrity Ensure that the message has not been altered in the transmission Non-repudiation Impossibility of denying the authenticity of a digital signature LCG/EGEE User tutorial, Torino (Italy) – January

Overview Glosary Encryption Certificates Grid Security

Cryptography K1 Encryption Decryption
M C M Mathematical algorithm that provides important building blocks for the implementation of a security infrastructure Symbology Plaintext: M Cyphertext: C Encryption with key K1 : E K1(M) = C Decryption with key K2 : D K2(C) = M Algorithms Symmetric: K1 = K2 Asymmetric: K1 ≠ K2 Cryptography allows to transform a clear text message into an unintelligible sequence of characters and/or numbers. Symmetric Algorithms If the algorithm operates on the plaintex one bit (or byte) at a time it is called stream cipher, if it operates on blocks of bits, it is called block cipher. LCG/EGEE User tutorial, Torino (Italy) – January

Symmetric Algoritms The same key is used for encryption and decryption
Advantages: Fast Disadvantages: how to distribute the keys? the number of keys is O(n2) Examples: DES 3DES Rijndael (AES) Blowfish Kerberos Paul John ciao 3$r 3$r ciao Paul John ciao 3$r 3$r ciao The lengths of the key vary from 56 bits (DES), now obsolete, to 256 bits. As computing power increases, the lengths of the key must be increased too, to avoid brute force attacks (i.e. trying all the possible keys until the right one is found). LCG/EGEE User tutorial, Torino (Italy) – January

Public Key Algorithms Every user has two keys: one private and one public: it is impossible to derive the private key from the public one; a message encrypted by one key can be decripted only by the other one. No exchange of secrets is necessary the sender cyphers using the public key of the receiver; the receiver decripts using his private key; the number of keys is O(n). Examples: Diffie-Helmann (1977) RSA (1978) Paul John ciao 3$r 3$r ciao Paul John ciao cy7 cy7 ciao The lengths of the keys, at the moment, varies from 512 bits (insecure) to 2048 bits. As the keys are much longer respect to those for symmetric algorithms, this kind of algorithms are much slower. For practical pourposes they are used togheter: first a temporary key for a symmetric algorithm is generated, which is used to encrypt the message, then the public key of the receiver is used to encrypt this key, which is sent (in encrypted form) together with the message. Paul keys John keys public public private private LCG/EGEE User tutorial, Torino (Italy) – January

One-Way Hash Functions
Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h) the length of h must be at least 128 bits (to avoid birthday attacks) given M, it must be easy to calculate H(M) = h given h, it must be difficult to calculate M = H-1(h) given M, it must be difficult to find M’ such that H(M) = H(M’) Examples: SNEFRU: hash of 128 or 256 bits; MD4/MD5: hash of 128 bits; SHA (Standard FIPS): hash of 160 bits. LCG/EGEE User tutorial, Torino (Italy) – January

Digital Signature Paul calculates the hash of the message
Paul encrypts the hash using his private key: the encrypted hash is the digital signature. Paul sends the signed message to John. John calculates the hash of the message and verifies it with the one received by A and decyphered with A’s public key. If hashes equal: message wasn’t modified; Paul cannot repudiate it. Paul This is some message Digital Signature This is some message Hash(A) Digital Signature John This is some message Digital Signature Hash(B) Paul keys public private = ? Hash(A) LCG/EGEE User tutorial, Torino (Italy) – January

Digital Certificates Paul’s digital signature is safe if:
Paul’s private key is not compromised John knows Paul’s public key How can John be sure that Paul’s public key is really Paul’s public key and not someone else’s? A third party guarantees the correspondence between public key and owner’s identity. Both A and B must trust this third party Two models: X.509: hierarchical organization; PGP: “web of trust”. LCG/EGEE User tutorial, Torino (Italy) – January

PGP “web of trust” D B F C E A F knows D and E, who knows A and C, who knows A and B. F is reasonably sure that the key from A is really from A. LCG/EGEE User tutorial, Torino (Italy) – January

The “third party” is called Certification Authority (CA).
X.509 The “third party” is called Certification Authority (CA). Issue Digital Certificates for users, programs and machines Check the identity and the personal data of the requestor Registration Authorities (RAs) do the actual validation CA’s periodically publish a list of compromised certificates Certificate Revocation Lists (CRL): contain all the revoked certificates yet to expire CA certificates are self-signed LCG/EGEE User tutorial, Torino (Italy) – January

X.509 Certificates An X.509 Certificate contains: owner’s public key;
identity of the owner; info on the CA; time of validity; Serial number; digital signature of the CA Structure of a X.509 certificate Public key Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba 8968 Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA Expiration date: Aug 26 08:08: GMT Serial number: 625 (0x271) Sample user certificate Certificate: Version: 3 (0x2) Serial Number: 981 (0x3d5) Signature Algorithm: md5WithRSAEncryption Issuer: C=IT, O=INFN, CN=INFN Certification Authority Issuer (CA) Validity Not Before: Oct 10 15:50: GMT Not After : Oct 10 15:50: GMT Subject: C=IT,O=INFN,CN=M User’s name Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) User’s public key Modulus (1024 bit): :bf:7e:b9:91:9f:dd:07:10:aa:0f:e6:5b:dc:b6: [...] Exponent: (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Certificate use Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 CRL Distribution Points: CRL information URI: X509v3 Certificate Policies: Policy information Policy: X509v3 Subject Key Identifier: A:57:A5:DC:C2:76:44:E1:29:B9:C4:BC:13:58:70:2A:A0:01:37:B X509v3 Authority Key Identifier: keyid:CA:11:EF:5D:1D:07:04:98:A9:A5:B5:58:1A:66:4E:0A:16:2B:E0: DirName:/C=IT/O=INFN/CN=INFN Certification Authority serial: X509v3 Subject Alternative Name: X509v3 Issuer Alternative Name: URI: Signature Algorithm: md5WithRSAEncryption Signature of the CA :f7:ee:d2:57:f4:99:fc:1a:73:90:ab:ae:c4:8f:dc:de:b5: [...] CA Digital signature LCG/EGEE User tutorial, Torino (Italy) – January

GRID Security: the players
Large and dynamic population Different accounts at different sites Personal and confidential data Heterogeneous privileges (roles) Desire Single Sign-On Users “Group” data Access Patterns Membership “Groups” Grid Sites Heterogeneous Resources Access Patterns Local policies Membership LCG/EGEE User tutorial, Torino (Italy) – January

The Risks Launch attacks to other sites
Large distributed farms of machines Illegal or inappropriate data distribution and access sensitive information Massive distributed storage capacity Disruption by exploiting security holes Complex, heterogeneous and dynamic environment Damage caused by viruses, worms etc. Highly connected and novel infrastructure LCG/EGEE User tutorial, Torino (Italy) – January

The Grid Security Infrastructure (GSI)
John Paul Based on X.509 PKI: John’s certificate every user/host/service has an X.509 certificate; certificates are signed by trusted (by the local sites) CA’s; every Grid transaction is mutually authenticated: John sends his certificate; Paul verifies signature in John’s certificate; Paul sends to John a challenge string; John encrypts the challenge string with his private key; John sends encrypted challenge to Paul Paul uses John’s public key to decrypt the challenge. Paul compares the decrypted string with the original challenge If they match, Paul verified John’s identity and John can not repudiate it. VERY IMPORTANT Private keys must be stored only: in protected places AND in encrypted form Verify CA signature Random phrase Encrypy with J.’ s private key Encrypted phrase Decrypt with J.’ s public key Compare with original phrase LCG/EGEE User tutorial, Torino (Italy) – January

Certification Authority State of Illinois Certificate Request Cert
User generates public/private key pair. CA confirms identity, signs certificate and sends back to user. Cert Request Public Key Certification Authority Cert State of Illinois ID Private Key encrypted on local disk User send public key to CA along with proof of identity. LCG/EGEE User tutorial, Torino (Italy) – January

Certificate Information
To get cert information run grid-cert-info grid-cert-info -subject /C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461 Options for printing cert information -all -startdate -subject -enddate -issuer -help LCG/EGEE User tutorial, Torino (Italy) – January

X.509 Proxy Certificate GSI extension to X.509 Identity Certificates
signed by the normal end entity cert (or by another proxy). Enables single sign-on Support some important features Delegation Mutual authentication Has a limited lifetime (minimized risk of “compromised credentials”) It is created by the grid-proxy-init command: % grid-proxy-init Enter PEM pass phrase: ****** Options for grid-proxy-init: -hours <lifetime of credential> -bits <length of key> -help LCG/EGEE User tutorial, Torino (Italy) – January

grid-proxy-init User enters pass phrase, which is used to decrypt private key. Private key is used to sign a proxy certificate with its own, new public/private key pair. User’s private key not exposed after proxy has been signed User certificate file Private Key (Encrypted) Pass Phrase User Proxy Proxy placed in /tmp the private key of the Proxy is not encrypted: stored in local file: must be readable only by the owner; proxy lifetime is short (typically 12 h) to minimize security risks. NOTE: No network traffic! LCG/EGEE User tutorial, Torino (Italy) – January

Proxy again … grid-proxy-init ≡ “login to the Grid”
To “logout” you have to destroy your proxy: grid-proxy-destroy This does NOT destroy any proxies that were delegated from this proxy. You cannot revoke a remote proxy Usually create proxies with short lifetimes To gather information about your proxy: grid-proxy-info Options for printing proxy information -subject -issuer -type -timeleft -strength -help LCG/EGEE User tutorial, Torino (Italy) – January

Delegation and limited proxy
Delegation = remote creation of a (second level) proxy credential New key pair generated remotely on server Client signs proxy cert and returns it Allows remote process to authenticate on behalf of the user Remote process “impersonates” the user The client can elect to delegate a “limited proxy” Each service decides whether it will allow authentication with a limited proxy Job manager service requires a full proxy GridFTP server allows either full or limited proxy to be used LCG/EGEE User tutorial, Torino (Italy) – January

Long term proxy Proxy has limited lifetime (default is 12 h)
Bad idea to have longer proxy However, a grid task might need to use a proxy for a much longer time Grid jobs in HEP Data Challenges on LCG last up to 2 days myproxy server: Allows to create and store a long term proxy certificate: myproxy-init -s <host_name> -s: <host_name> specifies the hostname of the myproxy server myproxy-info Get information about stored long living proxy myproxy-get-delegation Get a new proxy from the MyProxy server myproxy-destroy Chech out the myproxy-xxx - - help option A dedicated service on the RB can renew automatically the proxy contacts the myproxy server LCG/EGEE User tutorial, Torino (Italy) – January

GSI environment variables
User certificate files: Certificate: X509_USER_CERT (default: $HOME/.globus/usercert.pem) Private key: X509_USER_KEY (default: $HOME/.globus/userkey.pem) Proxy: X509_USER_PROXY (default: /tmp/x509up_u<id>) Host certificate files: Certificate: X509_USER_CERT (default: /etc/grid-security/hostcert.pem) Private key: X509_USER_KEY (default: /etc/grid-security/hostkey.pem) Trusted certification authority certificates: X509_CERT_DIR (default: /etc/grid-security/certificates) LCG/EGEE User tutorial, Torino (Italy) – January

Virtual Organizations and authorization
Grid users MUST belong to Virtual Organizations What we previously called “Groups” Sets of users belonging to a collaboration List of supported VOs: VOs maintain a list of their members The list is downloaded by Grid machines to map user certificate subjects to local “pool” accounts Sites decide which VOs to accept ... "/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461" .dteam "/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968" .cms "/C=CH/O=CERN/OU=GRID/CN=Patricia Mendez Lorenzo-ALICE" .alice /etc/grid-security/grid-mapfile LCG/EGEE User tutorial, Torino (Italy) – January

On the side: user Registration in a VO
Import your certificate in your browser If you received a .pem certificate you need to convert it to PKCS12 Use openssl command line (available in each egee/LCG UI) openssl pkcs12 –export –in usercert.pem –inkey userkey.pem –out my_cert.p12 –name ’My Name’ Sign the usage guidelines for the VO You will be registered in the VO-LDAP server (wait for notification) Gilda (and other VO): You receive already a PKCS12 certificate (can import it directly into web browser) For future use, you will need usercert.pem and userkey.pem in a directory ~/.globus on your UI Export the PKCS12 cert to a local dir on UI and use again openssl: openssl pkcs12 -nocerts -in my_cert.p12 -out userkey.pem openssl pkcs12 -clcerts -nokeys -in my_cert.p12 -out usercert.pem Netscape To import a certificate into Netscape, first start Netscape. Then select "Communicator->Tools->Security Info" from the top menus and then click on the "Certificates/yours" section. This will open a window where you will find an "Import a Certificate" button. You will be asked a new password to protect your Netscape certificates DB (keep track of it as you will need it to import other certificates). You will be able to choose your .p12 file from a standard file selection window. Internet Explorer Go to the Tools menu and select Internet Options. Choose the Content tab and click on Certificates. In the new window click on Import to get the Import wizard, then follow the instructions. Select the file for import and give the password (it should go into the "Personal" certificate store). You should also select high security otherwise IE remembers your pass phrase for you. LCG/EGEE User tutorial, Torino (Italy) – January

VOMS, LCAS, LCMAPS Virtual Organization Membership Service
Extends the proxy info with VO membership, group, role and capabilities Local Centre Authorization Service (LCAS) Checks if the user is authorized (currently using the grid-mapfile) Checks if the user is banned at the site Checks if at that time the site accepts jobs Local Credential Mapping Service (LCMAPS) Maps grid credentials to local credentials (eg. UNIX uid/gid, AFS tokens, etc.) Currently uses the grid-mapfile (based only on certificate subject) In the near future will map also VOMS group and roles Voms basato su DATAbase (no LDAP server) … definizione di ruoli "/VO=cms/GROUP=/cms" cms "/VO=cms/GROUP=/cms/prod" cmsprod "/VO=cms/GROUP=/cms/prod/ROLE=manager" .cmsprodman LCG/EGEE User tutorial, Torino (Italy) – January

Authentication Overview
VO user service The authentication steps shown in the following slides are: user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs generating a gridmap file from the LDAP database for authorization and mapping user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) LCG/EGEE User tutorial, Torino (Italy) – January

Certificate Request once in every year CA grid-cert-request service
VO user service cert-request grid-cert-request once in every year user requests a certificate A certificate is a set of information (e.g. user’s name) + identification key (public key) + signature from the CA. In a certificate request there is the set of informaiton + identification key. Real life example: A passport is a set of information (e.g. traveller’s name) + identification key (picture) + unique identifiers of the authority (passport material, stamps, etc.). In a passport request (filled form) there is a set of information + picture. LCG/EGEE User tutorial, Torino (Italy) – January

Certificate Signing CA VO user service certificate cert signing
cert-request grid-cert-request user requests a certificate user sends the requests to the CA, which sends back the signed certificate The CA calculates the hash of the certificate request and encodes it with its private key = signature. The CA identifies the user by a registration authority (RA). Real life example: The authority identifies the traveller and if there is no problem, then issues a passport. LCG/EGEE User tutorial, Torino (Italy) – January

Preparation for Registration
CA VO user service certificate cert signing cert-request grid-cert-request cert.pkcs12 convert user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format LCG/EGEE User tutorial, Torino (Italy) – January

Registration CA VO user service certificate cert signing cert-request grid-cert-request cert.pkcs12 convert Account Registration registration user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO Real life example: Before travelling to a foreign country you may need to apply for a visa. For this you need to fill out some forms and send them to the destination country’s appropriate authority. If everything is OK with you the authority will give you a visa, which you can show up at the border. In the current EDG setup this visa is not sent to you, but the list of „good” users is „sent” to the sites, so they would know your status. once for the lifetime of the VO (only the DN not the keys, so they may change) Usage guidelines LCG/EGEE User tutorial, Torino (Italy) – January

Starting a Session every 12/24 hours CA VO user service certificate
cert signing cert-request grid-cert-request cert.pkcs12 convert proxy-cert grid-proxy-init registration user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generates a proxy certificate (24 hours lifetime) every 12/24 hours LCG/EGEE User tutorial, Torino (Italy) – January

Certificate Request for a Host
VO user service certificate cert signing host-request grid-cert-request cert-request grid-cert-request cert.pkcs12 convert proxy-cert grid-proxy-init registration user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generats a proxy certificate (24 hours lifetime) host/service requests a certificate once in every year LCG/EGEE User tutorial, Torino (Italy) – January

Signing the Certificate
VO user service certificate cert signing host-cert cert signing host-request grid-cert-request cert-request grid-cert-request cert.pkcs12 convert proxy-cert grid-proxy-init registration user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate LCG/EGEE User tutorial, Torino (Italy) – January

Configuration on the Server
CA VO-LDAP user service certificate cert signing host-cert cert signing ca-certificate crl cert/crl update host-request grid-cert-request cert-request grid-cert-request cert.pkcs12 convert proxy-cert grid-proxy-init registration user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs Real life example: The officers at the border has to know all the valid passport types, which would be shown to him. He learns it by looking at example passports from the various countries. The ca-certificate plays this role in this setup: the service can validate a user certificate by using the ca-certificate. So the list of valid CA certificates is similar to the set of passports accepted at a border. A passport can be stolen, so a country time-to-time issues a black list of the invalid numbers. The Certificate Revocation List (CRL) is this list for the CA: the list of invalid certificate numers signed by this CA. automatically updated every night/week LCG/EGEE User tutorial, Torino (Italy) – January

Authorization Information
CA VO-LDAP user service certificate cert signing host-cert cert signing ca-certificate crl cert/crl update host-request grid-cert-request cert-request grid-cert-request cert.pkcs12 convert proxy-cert grid-proxy-init registration gridmap mkgridmap user requests a certificate user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs generating a gridmap file from the LDAP database for authorization and mapping Real life example: Normally a visa is bind (glued into) the traveller’s passport, so an officer at the border can check it without contacting the country’s central authority, which issued it. In the current EDG setup the services has to download the list of valid passports, which are acceptable for the VO. The list of valid certificates is stored in the gridmap-file. This will change in the future to mimic the behaviour of our real life example. automatically updated every night/week LCG/EGEE User tutorial, Torino (Italy) – January

host/proxy certs exchanged
Using a Service CA VO-LDAP user service certificate cert signing host-cert cert signing ca-certificate crl cert/crl update host-request grid-cert-request cert-request grid-cert-request host/proxy certs exchanged proxy-cert grid-proxy-init cert.pkcs12 convert registration gridmap mkgridmap user requests a certificate (once in every two-three years) user sends the requests to the CA, which sends back the signed certificate conversion to browser digestable PKCS12 format registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!) generats a proxy certificate (24 hours lifetime) host/service requests a certificate host/service sends the requests to the CA, which sends back the signed certificate retrival of the trusted CA certificates and their CRLs (automatically updated every night/week) generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week) user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently) Real life example: The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country. The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life. LCG/EGEE User tutorial, Torino (Italy) – January

Further Information Grid
LCG Security: LCG Registration: Globus Security: Background GGF Security: GSS-API: GSS-API: \ GSSAPIPG/toc.html IETF PKIX charter: PKCS: LCG/EGEE User tutorial, Torino (Italy) – January

ESRIN Grid Workshop Tutorial

Similar presentations

Presentation on theme: "ESRIN Grid Workshop Tutorial"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

ESRIN Grid Workshop Tutorial

Similar presentations

Presentation on theme: "ESRIN Grid Workshop Tutorial"— Presentation transcript:

Similar presentations

About project

Feedback