Security 1: Introduction

Security 1: Introduction Dr John Watt Grid Security Engineer National e-Science Centre University of Glasgow j.watt@nesc.gla.ac.uk 10th July 2006

Overview • Introduction to Security (14.30-15.00) • Security: Is it possible? • Fundamentals • A Question of Trust • Authentication (15.00-15.30) • Who am I?? • Basic Cryptography • Public Key Infrastructures (PKIs) • Certificates and Authorities • Proxies and Temporary Credentials

Introduction to Security

Introduction to Security • What do we mean by security anyway? • Secure from whom? • From systems administrator? From rogue employee? Mr. H. Acker…? • Secure against what? • Denial of Service? Identity theft? Legally sensitive data acquisition? • Or even MPs leaving laptops on the Tube… • Secure for how long? • “I recommend overwriting a deleted file seven times: the first time with all ones, the second time with all zeros, and five times with a cryptographically secure pseudo-random sequence. Recent developments at the National Institute of Standards and Technology with electron-tunnelling microscopes suggest even that might not be enough. Honestly, if your data is sufficiently valuable, assume that it is impossible to erase data completely off magnetic media. Burn or shred the media; it's cheaper to buy media new than to lose your secrets…." • -Applied Cryptography 1996, page 229

Introduction to Security • Secure technology ≠ secure system • System using 2048+ bit encryption technology, packet filtering firewalls, PMIs, PKIs… • …. on running laptop in unlocked room • … on PC with password on “post-it” on screen/desk • We have heard worse than this, naming no names! • Famous quote to muse over: • “…if you think that technology can solve your security problems then you don’t know enough about the technology, and worse you don’t know what your problems are…” • Bruce Schneier, Secrets and Lies in a Digital Networked World

Fundamentals • Key terms that are typically associated with security • Authentication • Authorisation • Audit/accounting • Integrity • Fabric Management • Confidentiality • Privacy • Trust All are important for Grids but some applications may have more emphasis on certain concepts than others

Fundamentals - Authentication • Authentication • the establishment and safe propagation of a user’s identity in the system • e.g. so site X can check that user Y is attempting to gain access to resources • Note does not check what user is allowed to do, only that we know (and can check!) who they are • Masquerading always a danger (and realistic possibility) • Need for user guidance on security • Password selection • Treatment of certificates • Hardware tokens • … • Is anonymity required? • Authentication on the Grid is achieved with Public Key Infrastructures (PKIs)

Fundamentals - Authorisation • Authorisation • concerned with controlling access to services based on policy • Can this user invoke this service making use of this data? • Complementary to authentication • Know it is this user, now can we restrict/enforce what they can/cannot do • Many different contenders for authorisation infrastructures • PERMIS • VOMS • CAS • AKENTI • Authorisation on the Grid must be scalable.

Fundamentals - Auditing • Auditing/Accounting • the analysis of records of account (e.g. security event logs) to investigate security events, procedures or the records themselves • Includes logging, intrusion detection and auditing of security in managed computer facilities • well established in theory and practice • Grid computing adds the complication that some of the information required by a local audit system may be distributed elsewhere, or may be obscured by layers of indirection • e.g. Grid service making use of federated data resource where data kept and managed remotely • Need tools to support diagnostics • Do we need to log all information? (Can We? More pertinent probably) • How long do we keep it for? • … • Auditing tools are in development for some authorisation infrastructures • PERMIS Secure Audit System

Fundamentals - Integrity • Integrity • Ensuring that data is not modified since it was created, typically of relevance when data is sent over public network • Technical solutions exist to maintain the integrity of data in transit • checksums, PKI support, … • Grid also raises more general questions • e.g. provenance • maintaining the integrity of chains or groups of related data • Integrity can be checked through the use of digital signatures

Fundamentals - Fabric Management • Fabric Management • consists of the distributed computing, network resources and associated connections that support Grid applications • impacts Grid security in these ways: • an insecure fabric may undermine the security of the Grid • Are all sites fully patched (middleware/OS)? • Can we limit damage of virus infected machine across Grid? • Identify it, quarantine it, anti-virus update/patch, re-instate into VO, … • fabric security measures may impede grid operations • e.g. firewalls may be configured to block essential Grid traffic

Fundamentals - Confidentiality • Confidentiality • is concerned with ensuring that information is not made available to unauthorised individuals, services or processes • It is usually supported by access control within systems, and encryption between systems • Confidentiality is generally well understood, but the Grid introduces the new problem of transferring or signalling the intended protection policy when data staged between systems • Authentication and Authorisation infrastructures usually implement confidentiality, so we are already there!

Fundamentals - Privacy • Privacy • particularly significant for projects processing personal information, or subject to ethical restrictions • e.g. projects dealing with medical, health data • Privacy requirements relate to the use of data, in the context of consent established by the data owner • Privacy is therefore distinct from confidentiality, although it may be supported by confidentiality mechanisms. • Grid technology needs a transferable understanding of suitable policies addressing privacy requirements/constraints • Should allow to express how such policies can be • defined, • applied, • implemented, • enforced, …

Trust • Trust • characteristic allowing one entity to assume that a second entity will behave exactly as the first entity expects • Important distinction between ‘trust management’ systems which implement authorisation, and the wider requirements of trust • e.g. health applications require the agreement between users and resources providers of restrictions that cannot be implemented by access control • e.g. restrictions on the export of software, or a guarantee that personal data is deleted after use • therefore a need to understand and represent policy agreements between groups of users and resource providers • such policies may exist inside or outside the system, and are typically not supported by technical mechanisms

Trust • Key concept for Grid security • Overall Grid security policy is impossible • Sites must integrate local security policies to create Virtual Organisations • Essential to have mechanisms which allow trust to be established between participating institutions • Security Policies should: • Be kept and managed by the local site • The Grid should aim to integrate existing site policies rather than centralise them. • A ‘Federation’ of trusted sites for VOs • Shibboleth??

Authentication

Who Am I?? • I am • The President of the United States • The Secretary General of the United Nations • David Beckham • Keith Richards • The girl who served your cup of coffee this morning.. • All of these people may need to use a computer • How can we confirm their identities?

Who am I?? • I am John Watt (allegedly) • To prove it I have • A Driving Licence • I got by passing my test and producing my passport • A Passport • I went to the passport office with my Birth certificate • A Birth Certificate • I can’t remember getting this!

Who am I?? • Is there a logical chain working here? • Note that, generally, the credentials given on the previous page tend to depend on the one below it. • But the DVLA (UK Driving Licence Authority) state on their website: • “Note - Birth certificates are not absolute proof of identity and so we may ask you to provide other evidence to allow us to check your identity.” • What other evidence? A passport? • But that depends on you producing a birth certificate! • A bank account? • You need a passport for that! • NO!

Who am I?? • But they do have one thing in common • They are non-local credentials • They attempt to define a unique (nationally at least) reference that will establish your identity • Do we need something similar for the Grid?? • First of all, we need to establish how identity can be proved and securely moved around a network. • The Grid community are (in principle) in agreement about how this should be done • But first we need to look at the basics of this system, and it has to do with an age old problem…

Basic Cryptography • When I were a lad… • My friend would post an important message through my letterbox… • But we had ‘code wheels’ • Rotate the inner wheel by the number of jumps indicated at the beginning of the message • And translate… 3 V L R P J B I I 3 Y O U S M E L L

Basic Cryptography • What if someone else got hold of the wheel? • Our plans for world domination are in ruins • Because what makes the wheel work is the extra information included with the original encrypted message: • Without this number the message will stay encrypted • This number is the encryption ‘key’ • And is transmitted UNENCRYPTED • We could agree this face-to-face, but why not just give the message then?? What if I was grounded? (happened a lot) • Lets look at this at a slightly more mature level… 3 V L R P J B I I

Basic Cryptography • The above scenario describes a SYMMETRIC key system • Same key is required for encryption and decryption • But this key CANNOT be transmitted without compromising both sides’ messages. encrypt decrypt A B decrypt encrypt

Basic Cryptography • We need some way of transmitting the key so it can’t be stolen. • Can we encrypt the key? No, but we can do something analogous… • 1) Split the key into two parts, one for encryption and one for decryption. • 2) Make the encryption key PUBLIC for anyone to use, but keep your decryption key PRIVATE. • Note that in some implementations the private key may also be used to encrypt and the public key to decrypt (see Digital Signatures)

Basic Cryptography • We have solved the key transmission problem by only transmitting an encryption key • Now anyone who wishes to send you a message uses your PUBLIC key to encrypt it, safe in the knowledge that the only person who can decrypt it is the holder of the PRIVATE key (i.e. you!) • The public and private keys are broken apart according to a complex mathematical formula that means it would take months/years to crack messages without the private key. • Tends to outlive credentials issued (e.g. credit cards)

Basic Cryptography • This is ASYMMETRIC encryption • Public key is available for B to write messages to A • Only A can read them as they hold the Private key. Publish key Receive key B A receive decrypt encrypt public private

Basic Cryptography • Symmetric encryption only guarantees privacy • The message is still encrypted, but there is no evidence of who encrypted it, nor any guarantee the data has not been tampered with. • Asymmetric encryption can be used to authenticate • By encrypting a message with someone’s private key, you can be sure ONLY they will be able to read it. • And… • Some level of integrity may be provided (digital signatures)

Public Key Infrastructures (PKIs) • PKIs provide a mechanism for privacy, integrity and authentication using public keys • Implemented with DIGITAL CERTIFICATES • Your UNIQUE virtualised identity • Issued by a CERTIFICATE AUTHORITY • Entity which administers certificates and issues them correctly • X509 (1988) is the standard for PKI certificates • Binds a globally unique X500 distinguished name to a public key • In reality, CAs tend to choose any name they want • Legal disclaimer, liability transfer. A mess, but not critical • Web browser compatible

Public Key Infrastructures (PKIs) • For our purposes (Grid), an X509 certificate contains the following primary information: • The CA • The Subject • The Public Key • A Digital Signature • + validity, version, algorithms Certificate: Data: Version: 1 (0x0) Serial Number: 6 (0x6) Signature Algorithm: md5WithRSAEncryption Issuer: C=gb, O=glasgow, OU=admin, CN=soa Validity Not Before: Jun 1 13:38:45 2006 GMT Not After : Jul 10 13:38:45 2010 GMT Subject: C=gb, O=glasgow, OU=dcs, CN=anthony Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:df:f7:e6:f3:3c:69:da:62:ba:d3:bf:e8:1a:9c: 3d:2e:8b:a5:51:21:6e:f0:8a:66:c8:1e:0b:70:95: 0e:f3:c7:78:63:e0:fc:bc:06:dd:42:fc:cd:c3:11: ec:f6:b6:b2:be:2e:09:35:aa:35:ad:ae:39:b0:ea: 04:93:51:1e:85:96:40:26:b8:42:dd:ba:a7:56:eb: c5:69:a6:b9:ff:5d:0d:f0:88:93:bd:6e:a4:2c:b2: ae:2d:f0:70:73:7e:b5:01:21:b5:e2:5b:89:2a:e3: 0f:a0:1f:95:71:31:cd:43:a2:16:57:d6:94:e2:e9: 72:c5:8c:21:83:3a:31:c4:85 Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 8f:74:21:08:db:fa:e4:af:4e:d5:46:90:ad:0f:1e:8f:97:09: 52:eb:f6:f5:c3:4e:bc:07:68:c7:4f:fe:1c:ab:f5:76:3f:ed: 2b:62:81:6f:2c:ad:78:a4:06:7e:4b:7a:96:4b:17:96:5d:db: 34:b3:fe:5b:72:85:0d:32:f2:78:2a:20:32:43:87:2d:0c:70: 96:a8:5f:63:82:cb:3e:c0:5f:9a:2e:bb:50:dd:79:b8:2a:d0: a4:32:6c:e6:b3:72:ab:31:70:16:52:f3:85:20:98:58:38:f1: 6a:b1:c1:0c:81:83:f4:70:f1:2b:fb:0d:93:ae:35:8a:32:56:

Certificate Authorities • A Certificate Authority (CA) is a third party that signs certificates and ensures that the subject name and public key actually belong to that person • How? • The old fashioned way… • Example… The UK e-Science Certificate Authority • Initial contact – application (online) • Credential verification (IN PERSON) • Go to CA or Regional Authority (RA) • Issue – download (online) • UK CA requires the application and issuing terminals to be the same ( this is where the PRIVATE key of your certificate is)

Certificate Authorities • A CA may delegate Regional Operators to confirm people’s identities • Saves me having to travel from Glasgow to Oxford if I want a certificate • CA records a piece of personal identification for their records • Passport, Driving Licence, Staff/Student Matric Card • CA extends an existing ID infrastructure – good thing

Certificate Authorities • A CA also is in charge of revoking certificates • CA publishes a Certificate Revocation List • Download to your browser • Shows all invalid certificates in the organisation • A CA MUST be explicitly trusted by the system • Trusted Root CAs list in Windows • Certificate cannot be used until the CA’s root certificate has been accepted as trusted • Accepted very much like Software Licences i.e. nearly always!

Digital Signatures • CAs confirm the certificate’s authenticity by digitally signing it • CA computes a hash of the certificate using an agreed (non-secret) algorithm • CA encrypts this hash with their private key and appends to bottom of certificate • Recipient computes their own hash of the info • Recipient decrypts the hash the CA sent (with the CA’s public key) and compares with their own • Proves the CA signed the info and the info hasn’t been tampered with • Encryption of the info is optional (for privacy)

A problem • Are there any pitfalls to digital certificates? • Can we alter their contents? • No, the CA signed the certificate thus ensuring its integrity • Can we spoof? • You will need your own CA, and if the application doesn’t trust it, your certificates won’t work. So no. • What can we do? • STEAL IT! • Someone who holds your digital certificate (and private key) may safely assume your identity on the Grid • This problem isn’t going away. How can we deal with this?

Proxies • Temporary credentials • If the certificate is that sensitive, we shouldn’t fire it off across the Grid where you will lose track of it. • Instead create a PROXY CERTIFICATE • A proxy certificate is a new version of your certificate, but this time with your original certificate as the CA • It has a VERY SHORT lifetime • So if it is stolen, it can only be used for a short time (24 hrs) • Revocation is unnecessary as it expires so quickly • You don’t need to revoke the ORIGINAL certificate as it was only the proxy (which is different) which was stolen • Proxy certificates have another feature which becomes obvious when you actually look at what a proxy looks like…

Proxies • A proxy certificate seems to be 3 certificates in one! • Not so, the proxy certificate is only the first certificate • The second is the private key of the proxy • The third is the original certificate the proxy was made from • Why?? -----BEGIN CERTIFICATE----- MIIB6zCCAVSgAwIBAgIEV3PyzjANBgkqhkiG9w0BAQQFADA/MQswCQYDVQQGEwJn YjEQMA4GA1UEChMHZ2xhc2dvdzEMMAoGA1UECxMDZGNzMRAwDgYDVQQDEwdhbnRo b255MB4XDTA2MDcwNzE0MDIzMVoXDTA2MDcwODAyMDczMVowVDELMAkGA1UEBhMC Z2IxEDAOBgNVBAoTB2dsYXNnb3cxDDAKBgNVBAsTA2RjczEQMA4GA1UEAxMHYW50 aG9ueTETMBEGA1UEAxMKMTQ2NzIxNjU5MDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC QQCWU12wPJzHv500RzFYn9bA/acRm1ZoNKszpum02cChyvDh58XRfdA+uVBhPHvx udqZtN/GHaKaz/2/+j3wmbsRAgMBAAGjIzAhMB8GCisGAQQBm1ABgV4BAf8EDjAM MAoGCCsGAQUFBxUBMA0GCSqGSIb3DQEBBAUAA4GBALzb0FfjQ6gx3rNgcMxi6vec 2Dtz+Y03TpkkAeeJJhn5mHRB6oDJGTKM/t7wjxgdkhp3Bbd7dA3D6psrslMrum+2 kk4FG6khqspWsMeyTUvepA7Qo3mO7YyXzbFIXwdU18jJyOXtl/9xvxvGa7IX3blg zFiEOZslvO3MSwojrEZp -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- MIIBOgIBAAJBAJZTXbA8nMe/nTRHMVif1sD9pxGbVmg0qzOm6bTZwKHK8OHnxdF9 0D65UGE8e/G52pm038YdoprP/b/6PfCZuxECAwEAAQJAGD9MLmAofcO3jLYrDHuD vU9swldHAbn1H3i927D/9FizZqpkEe+KhD59+gE91eL8mw6xagj3vkTi6HS0Ff3E 0QIhAMV5ZrSFczh1VAyVDkXyQxvR5qgPCp5GJwO/Psamo8jFAiEAwuC/YoN75Ox2 PFnSVbHy60pm0rAEkIrkLu7xKqYcVd0CIFjsultAXQpni1m/JZZJ6f51HzE+1MFB RgBh9pruH4MhAiEAtsyhWeRiPCu/AP90eKQSbLl+2BT6Qye1wXyrRklI/RUCID5+ RNLI8mR2xUx4HRyW/RcJDLaDtBAr0NO7gPUvdYd3 -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIB6zCCAVQCAQYwDQYJKoZIhvcNAQEEBQAwPTELMAkGA1UEBhMCZ2IxEDAOBgNV BAoTB2dsYXNnb3cxDjAMBgNVBAsTBWFkbWluMQwwCgYDVQQDEwNzb2EwHhcNMDYw NjAxMTMzODQ1WhcNMTAwNzEwMTMzODQ1WjA/MQswCQYDVQQGEwJnYjEQMA4GA1UE ChMHZ2xhc2dvdzEMMAoGA1UECxMDZGNzMRAwDgYDVQQDEwdhbnRob255MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDf9+bzPGnaYrrTv+ganD0ui6VRIW7wimbI HgtwlQ7zx3hj4Py8Bt1C/M3DEez2trK+Lgk1qjWtrjmw6gSTUR6FlkAmuELduqdW 68Vpprn/XQ3wiJO9bqQssq4t8HBzfrUBIbXiW4kq4w+gH5VxMc1DohZX1pTi6XLF jCGDOjHEhQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAI90IQjb+uSvTtVGkK0PHo+X CVLr9vXDTrwHaMdP/hyr9XY/7StigW8srXikBn5LepZLF5Zd2zSz/ltyhQ0y8ngq IDJDhy0McJaoX2OCyz7AX5ouu1Ddebgq0KQybOazcqsxcBZS84UgmFg48WqxwQyB g/Rw8Sv7DZOuNYoyVhsn -----END CERTIFICATE-----

Proxies • Proxies propagate through the grid by signing new versions of themselves • Using the proxy certificate and its private key, any number of new proxies may be spawned across each required resource. • Acheives two goals • DELEGATION • Proxy acts on your behalf • SINGLE SIGN-ON • You only need to logon to the Grid once

Summary • Security is a combination of technical implementation and sociological behaviour • There can be no overall security policy for the Grid – integrate existing site policies • The establishment of identity on the Grid (authentication) is achieved through the use of PKI Certificates and Proxies

Security 1: Introduction