Seifenkasten Jens Jensen Berlin PMA, Jan 2015

Jens Jensen, STFC/RAL CA processes – overview Key generation and storage (qv) Receiving requests (CSR, CRR, …) Validating requests Archiving request metadata Signing certificate/CRL Supporting certificate “in the wild” (qv) Audit processes Person stuff: users, operators, authorisers Support processes (helpdesk, /phone) Post-expiry support (qv)

Jens Jensen, STFC/RAL CA Processes – detail Key generation and storage –Generation of trustworthy key pair –Storage of “working copy” and activation data E.g. HSM, or offline Physical protection –Storage of backup copies Who can access backup copies – n-of-m –Knowledge of code/processes

Jens Jensen, STFC/RAL CA Processes – details Supporting certificate “in the wild” –Certificate status –Revoked when needed or other incident handling –Extensions to support its use in middleware –Crypto to support its validity/lifetime –Timely renewal and rekey Post expiry support –Validity (e.g. for digital signatures) –Late renewal/rekey

Jens Jensen, STFC/RAL Question(s) How brittle are these processes What sort of things make them break? –Is it bad if they break? –Can we mitigate breakage? –Can they be made less fragile? –Are we making them less fragile or more? –How easy is it to make them robust? History: have they broken before?

Jens Jensen, STFC/RAL History – have they broken before? Key generation and storage Deployment processes (rollout and retiring CA certs) Backups (backing up b0rken data) Receiving requests (CSR, CRR, …) Validating requests Archiving request metadata Signing certificate/CRL Supporting certificate “in the wild” Audit processes Intrusion – attacker breaking into the system Support processes (helpdesk, /phone) Post-expiry support Few incidents are generic

Jens Jensen, STFC/RAL Why stuff breaks Brittle software –“Liberal in what it sends, conservative in what it accepts” –Resistant to changes –Tested on narrow cases –Complexity –Adding “features” instead of robustness

Jens Jensen, STFC/RAL Why stuff breaks Person problems –Don’t know the right process –Can’t be bothered –Shortcuts – under pressure from snr person, or time –Trying to be “helpful” Dumb downstream design –E.g. (a) CA retirement process, (b) reliance on issuer name, (c) checking for “expired” CRLs (even if no certs are issued)

Jens Jensen, STFC/RAL Why stuff breaks Usual software design/impl./test reasons Unknowns – back doors, unexpected risk Attacks (e.g. by bots, script kiddies) Lack of funding, lack of skills Hacks –Often necessary but can be brittle –Can break software updates All software dev is hard to do properly –Particularly science code?

Jens Jensen, STFC/RAL How can we make stuff less brittle Sharing: Documented stuff that works, code, processes –Sharing IdPs –Sharing code – kind of failed to do that Security analysis/testing Rewrite / reimplement –Make use of trustworthy components Design to be robust (“anti-fragile”?) (How good are we at doing this?)

Jens Jensen, STFC/RAL How can we make stuff less brittle Outsource: use commercial supplier More nagging? (RP software) Learn from failures –Share incidents – and near misses? Reviews help new CAs Compare CAs like DigiCert –that can put Real Funding™ behind the problem

Jens Jensen, STFC/RAL How can we really make stuff less brittle? Focus on stuff that works… GFD.225 and other best practices docs –“Not another unmaintained document” Science can do proper code development –Regression tests, robust by design –Preproduction testing, Change control –Just not done by default What else?

Jens Jensen, STFC/RAL How open can we be about “incidents” –How useful will a writeup be to others –Few generic incidents, only CA-specific of interest Separate into areas –crypto, –technology, –person “incidents”, –software dev