1. www.egi.eu EGI-InSPIRE RI-261323 EGI-InSPIRE www.egi.eu EGI-InSPIRE RI-261323 Introduction of SHA-2 in the EGI Infrastructure David Groep, EGI-IGTF Liaison Nikhef and BiG Grid, for EGI.eu 2012-09-17 EGI Technical Forum 20121

2. www.egi.eu EGI-InSPIRE RI-261323 Background Digital signatures are used in identity PKI and TLS session establishment What is signed is not the text itself, but a ‘digest’ or ‘hash’ thereof If you find two texts with the same digest, you can swap these without breaking the signature This is referred to as ‘breaking’ the digest Many digests have been devised and broken like MD2, MD4, or MD5, or are trivial (CRC32) and not used for crypto 2012-09-17 EGI Technical Forum 20122

3. www.egi.eu EGI-InSPIRE RI-261323 SHA-1 and SHA-2 SHA-1: 1 st generation (SHA-“0” was withdrawn) –160 bits nominal, 80 bits effective, 51 bits ‘left’ –published 1995 –NIST end date December 2010 SHA-2: 2 nd generation ‘secure hash algorithm’ –several variant lengths: 256 (224), 512 (384) –most common: 256 and 512 –published 2001, 2012-09-17 EGI Technical Forum 20123

4. www.egi.eu EGI-InSPIRE RI-261323 Why bother? inherent threat to signatures (and PKI) if SHA-1 is spectacularly broken –fake certificates could suddenly be trusted although threat to SHA-1 is different than MD5 SHA-1 is broken ‘enough’ for make CABForum act and forbid its use –would anyway be following NIST advice –makes all commercial CAs move (Comodo: TCS, InCommon; DigiCert: OSG, QuoVadis) –US govt making SHA-2 requirement to bid some communities already require SHA-2 2012-09-17 EGI Technical Forum 20124

5. www.egi.eu EGI-InSPIRE RI-261323 Preventing a sudden mess IGTF is to try preventing sudden melt-down by pushing for SHA-2 now –allow regular rekey cycle to take care of legacy SHA- 1 certificates, without upsetting users/admins –introduce SHA-2 gradually to allow transition –introduce early enough to escape from the mathematicians and cryptanalysts –in synch with other commercial/OSS software 2012-09-17 EGI Technical Forum 20125

6. www.egi.eu EGI-InSPIRE RI-261323 Considerations Strength of SHA-1 is decreasing (from 80 bits now down to 51 bits) –collision can now be found in ~500 coreyears? –making a colliding certificate is luckily much harder for the moment –but also MD5 was ‘suddenly’ broken But not all middleware is ready –software issues almost force move to both SHA-2 and RFC3820 proxies at same time 2012-09-17 EGI Technical Forum 20126

7. Current state of affairs There are various pieces of middleware and experiment-ware that need to be made ready for SHA-2 or RFC proxy support – SHA-2: dCache, BeStMan (RFC proxies already supported by these) – RFC: Argus, CREAM, WMS, DIRAC, … – Central EGI/OSG/… services – https://twiki.cern.ch/twiki/bin/view/LCG/RFCproxySHA2support https://twiki.cern.ch/twiki/bin/view/LCG/RFCproxySHA2support EGI Operations will help with the assessment All EMI-2 products (released May 21) should support RFC proxies – WMS not yet available – Very little uptake so far – Also SHA-2 should be supported, except for dCache – verified? It may be many weeks before the affected products can be endorsed by UMD for generic deployment on EGI sites – EMI-2 is a major release with many changes OSG did not report additional constraints for their MW Maarten Litmaath (CERN)7

8. Updated phases and milestones (1) 1. Deployment of SW supporting RFC proxies – Proxy usage: Legacy RFC  only in special tests SHA-2  only in special tests – SW supports: Legacy RFC  maybe SHA-2  maybe – Milestone: All deployed SW supports RFC proxies  summer 2013 ? – Additional goal: All deployed SW supports SHA-2, except dCache and BeStMan  summer 2013 ? Maarten Litmaath (CERN)8

9. www.egi.eu EGI-InSPIRE RI-261323 Software time lines Software support time linesin EGI –UMD-1 EoL around May 2013 (no SHA-2) –UMD-2 available now (mostly w/SHA-2) –UMD-3 availability around May 2013 Need to agree acceptable timeline for all major RPs in IGTF bearing in mind the risk to SHA1 –wLCG needs stability for extended running –other RPs ‘should’ be ready, but more actual testing would be nice (PRACE, OSG) 2012-09-17 EGI Technical Forum 20129

10. www.egi.eu EGI-InSPIRE RI-261323 Revised time line For Relying Parties including EGI “The recommendation is that IGTF CAs will not issue general availability SHA-2 certificates before 1 August 2013” EUGridPMA Lyon meeting 2012-09-17 EGI Technical Forum 201210

11. www.egi.eu EGI-InSPIRE RI-261323 EoL Considerations If SHA-1 is broken, revocation and transition will be immediate as inspired by the categorization in the HASHRAT document The scheduled end of life for SHA-1 end-entity certificates (EEC’s) is 1 September 2014, meaning that SHA-1 EECs SHOULD have a validUntil date no later than that date. If there are CAs with EECs having a later date, the primary mitigation of the risk in case SHA-1 is broken will be removal of said CA from the IGTF distribution (and by inference from EGI via ‘obsoletion’ in the distro) 2012-09-17 EGI Technical Forum 201211

12. www.egi.eu EGI-InSPIRE RI-261323 CA time lines CAs SHOULD have SHA-2 capability by October 1 st 2012 There is no need to move existing CA self-signed roots to SHA-2 since we rely only on the distributed metadata Since intermediate CAs are distributed but the distribution can be superseded by dynamic CA chains (subject to the namespace constraints) … these SHOULD be SHA-2 after 31 March 2014, but if still based on SHA-1 these MUST be revoked and re- issued if and when SHA-1 is broken (like for EECs). New CA certificates generated after April 2014 SHOULD be SHA-512 noting that existing (self-signed) CA certs MAY be SHA-1. 2012-09-17 EGI Technical Forum 201212

13. www.egi.eu EGI-InSPIRE RI-261323 SHA variants and CRLs Only SHA-256 and SHA-512, and not 224 nor 384. Each CA MAY pick its own variant. CRLs on the default CDP URL SHOULD be SHA-1 until at least 1 September 2014. CAs MAY start distributing SHA-2 based CRLs after that date, and MAY have SHA-2 based CRLs available on alternate CDPs after 1 October 2012. If the same subject is signed twice (once SHA-1 and once SHA-2) the certificates must use different serial numbers. The same is true of CRLs with same data: these must have different sequence numbers. 2012-09-17 EGI Technical Forum 201213

14. www.egi.eu EGI-InSPIRE RI-261323 Vulnerabilities Breakage of the SHA-1 algorithm in a way that allows trivial generation of plaintexts with a specific hash necessitates removal of SHA-1 algo support. This is a software vulnerability issue outside of our scope and SHOULD be dealt with using regular vulnerability mechanisms of the RPs. It then WILL necessitate SHA- 2 based root certs as well. 2012-09-17 EGI Technical Forum 201214

15. www.egi.eu EGI-InSPIRE RI-261323 SLCS CAs ‘end-of-life’ SHA-2 migration recommendation does not apply to certificates with a short life time (for SLCS CAs) until at least 1 September 2014. 2012-09-17 EGI Technical Forum 201215

16. www.egi.eu EGI-InSPIRE RI-261323 Testing middleware You can test with dedicated SHA-2 CAs –OpenID test personal certs: CILogon Basic (personal only) –CERN IT/IS TCA SHA-2 expt. CA (host+personal) Or with accredited CAs (host+personal) –BalticGrid, ROSA, DutchGrid, GridCanada, DigiCert, (past 1 Oct: INFN, CESNET and more) 2012-09-17 EGI Technical Forum 201216

17. www.egi.eu EGI-InSPIRE RI-261323 SHA-2 time line 2012-09-17 EGI Technical Forum 201217 SHA-2 widely available for testing 201320142015 1 August 2013: SHA-2 certs ‘general availability’- expect seeing SHA-2 be used in many places ~ April 2013: EoL of UMD-1 1 Sept 2013: CAs on 12-month cycle can start SHA-2 only mode or use reduced life cycle 1 Sept 2014: last ‘regular’ long-lived SHA-1 cert expires selected CAs can continue issuing SHA-1, but face risk of removal in case SHA-1 is broken 1 Sept 2014: default CRL distribution point will become SHA-2 end of ‘critial ops’ mode for wLCG now

18. www.egi.eu EGI-InSPIRE RI-261323 QA 2012-09-17 EGI Technical Forum 201218 Today: start SHA-2 testing – preferentially with your local CA 1 August 2013: SHA-2 general availability certs 1 September 2014: default CRLs move to SHA-2 end of life for last regular SHA-1 cert if SHA-1 is not decidedly broken before these dates...