Flow Through a Circular Pipe: Understanding the Hydraulics
Dive into the world of fluid mechanics with a focus on the flow through circular pipes. Explore the intricacies of flow velocity, pressure, and losses, and gain insight into effective control methods. Learn about entrance loss coefficients, culvert flow control, and practical applications in hydraulic engineering. This comprehensive guide, enriched with visual aids, offers valuable knowledge for hydraulic system design and optimization.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Soapbox Jens Jensen, UKRI-STFC / EOSC Future 29 Sep 2021
Normal state of operations Authority can issue or bless or revoke EE credentials, and No one who is not the Authority can do so EEs can authenticate to services, and Each EE can present a unique-{1,2,3} id No one who is not the EE can present the same id in authentication EEs can obtain and present attributes for authorisation EEs cannot obtain auz attrs that they are not entitled to Community can define, assign, approve and revoke auz attrs for EEs No one who is not the Community can do so
Abnormal state of operations Authority cannot issue or bless or revoke EE credentials, or Someone who is not the Authority can do so EEs cannot authenticate to services, or Not all EEs can present a unique-{1,2,3} id Not unique-1 (shared), or unique-2 (not traceable), or unique-3 (reassigned) Someone who is not the EE can present the same id in authentication (while not intentionally shared) EEs cannot obtain and present attributes for authorisation EEs can obtain auz attrs that they are not entitled to Community cannot define, assign, approve or revoke auz attrs for EEs Someone who is not the Community can do so
Authority Authority has lost secret Authority has secret Someone else has secret
How to not keep a secret? Give managers parts to keep Give PAs parts to keep Give tech staff parts to take home and keep safely Split it in thirds (the AB/AC/BC 2-of-3 scheme) Keep it only to yourself Keep it on memory sticks which can go walkabout Implement encryption schemes which require HPC Keep it only in your HSM (even if you have two)
How to not keep a secret? What of general m-of-n schemes? Implemented by HSMs SSSS is the generic solution Provably secure (like OTP) Questions of a SSS: Who has the pieces? Cf. the keep-something-or-other-safe How are the pieces protected? Passwords and pins can will be forgotten Can pieces be revoked or disabled?
Is RCauth the a solution? The key has precisely three active copies The key is safe from attacks by management/non-techies/techies Only one person per site has temporary access to the key Key is activated only during HSM import
How could an RCauth scheme fail? Site loses a HSM/key and needs to rebuild it from the other two Everything else is recovered automatically Or recoverable through the established secure channels If we need to redistribute the key to a site We need the key in exportable form somewhere Can t just have it inside an HSM Doing the key parts exchange from scratch is not appealing It took ages It will take even ages-er now, as in general travel is required
How can an RCauth scheme rebuild itself In QKD, existing secrets are used to establish more secrets If not interrupted, it becomes self sustaining Initial OTPs: Nikhef s OTP is 1Mb, so can use more of it Deliberate choice: offset exchanged separately, can use unused parts STFC s OTP is 1kb, so is fully used Deliberate choice: small enough to write down (in principle) Generate new OTPs But they have to be stored somewhere So we re back to square 1?
How can an RCauth scheme rebuild itself If site X has lost the private key Use both sites Y, Z to recover it Each site sends half of the private key However, this requires non-HSM copies at one site (Z, say) Or exportable-from-HSM Y generates ??and secretly shares with X, Z Z calculates ??= ?? K and secretly shares ??with X X calculates ?? ??to recover K Advantage: is done only when needed (low likelihood)
How can an RCauth scheme rebuild itself Can we do (even) better (speculatively)? Allow a pre-shared recovery scheme (needs a bit more thought) Alternatively allow for (rare) failure Start with N>3 interconnected sites When a site fails, it stays failed Can do stochastic modelling on service availability
Could an RCauth model be used for other stuff? Say site X has a secret Site X has N (trusted!) friends, sites ?? Site X splits its secret K into N parts ??and i gives ??to ?? It would require collusion by all N to leak the secret You d probably use a threshold scheme, though Also needs secure channels for inter-site comms Like the PGP stuff we used to do Our infrastructure was designed to protect asymmetric keys However, OTP requires symmetric keys
Other failure modes? Forgotten/lost secrets Bit rot (you think you have the secret but haven t) Rarely used things like once-a-year signing/requests Leaked (or suspected-leaked) secrets A LOCKSS copy goes astray Broken cryptographic whatsits Including Quantum Computing Software entropy E.g. upgraded systems which lose backward compatibility Human-based ACLs Social engineering, or just
What are the weakest links? The EE (person) who doesn t manage their credential well? Can t, won t, doesn t care A colleague who clicks a link in an email? Not all staff are equally security conscious External threats The usual Internet baddies, from the script kiddies to national players Ransomware Entropy Bit rot and other Insider threat Malicious insider honest but curious or well intentioned but somehow breaking stuff
Recovery modes Lots of expertise in the AAAI community Though not always working in the same direction (IGTF itself is mostly uni-directional) I have mentioned the gap previously filled by CAOPS before Some bits of technical innovation Like the RCauth stuff Or the SimpleSAMLPhp work Very little forward planning though? Risks are low likelihood but can have high impact
Who is working on the technical risks? AARC project/community looked at trust risks, e.g. LoA NIST quantum safe crypto Some sporadic UK work E.g. John Kewley s writeup (slideup) of SHA1 compromise impact Other work presented at past PMAs The WLCG working groups are great but don t seem to be active in this space
Conclusion RCauth potentially useful Even beyond running a HA CA Community-shared experience and software Maybe we need to use the PMA wikis again? Lots of expertise across the AAAI community Not enough (community-shared) forward planning for risks
