EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI Introduction of SHA-2 in the EGI Infrastructure David Groep, EGI-IGTF Liaison Nikhef and BiG Grid, for EGI.eu EGI Technical Forum 20121

EGI-InSPIRE RI 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 EGI Technical Forum 20122

EGI-InSPIRE RI 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, EGI Technical Forum 20123

EGI-InSPIRE RI 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 EGI Technical Forum 20124

EGI-InSPIRE RI 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 EGI Technical Forum 20125

EGI-InSPIRE RI 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 EGI Technical Forum 20126

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 – 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

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

EGI-InSPIRE RI 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) EGI Technical Forum 20129

EGI-InSPIRE RI 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 EGI Technical Forum

EGI-InSPIRE RI 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) EGI Technical Forum

EGI-InSPIRE RI 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 EGI Technical Forum

EGI-InSPIRE RI 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 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 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 EGI Technical Forum

EGI-InSPIRE RI 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 EGI Technical Forum

EGI-InSPIRE RI 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 EGI Technical Forum

EGI-InSPIRE RI 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) EGI Technical Forum

EGI-InSPIRE RI SHA-2 time line EGI Technical Forum SHA-2 widely available for testing 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

EGI-InSPIRE RI QA EGI Technical Forum 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...