Building Trust in Digital Identities

Slides presented at the Secure Digital identities for a Digital Single Market in Europe workshop.

Transcript

1. Building Trust in Digital Identities Secure Digital identities for a Digital Single Market in Europe Frederic Jacobs
2. What is trust? “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the agility to monitor or control that other party” (Mayer et al., 1995)
3. What is trust? “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the agility to monitor or control that other party” (Mayer et al., 1995)
4. Trusting is accepting some vulnerability
5. Major Concerns Related to Online Privacy and Security Risks, Percent of Households with Internet Users, 2015 Source: NTIA - US Dept of Commerce
6. Eurobarometer on Data Protection Source: European Commission Special Eurobarometer 431
7. Threat Modeling • Is the eventual risk of compromise not outbalancing the advantages yielded by the trust relationship? • Can I mitigate misplaced trust? • Maybe there is an entity I trust enough? (Centralized) • Maybe trust should be distributed to a quorum? (Federated) • Maybe trust should be completely distributed without central nodes? (Decentralized)
8. What enables trust?
10. User Experience
11. Social Engineering Trust
12. Warning fatigue
13. –Russian proverb taught by Suzanne Massie to Ronald Reagan “Доверяй, но проверяй” (trust, but verify)
14. Standards • Security Management Standards • ISO27K, IETF RFC 2196, NIST 800-53, BSI 100-1, BSI 100-3 • Technical Security Standards • AES, TLS, RADIUS, OpenID • Vulnerability Management Standards • ITU-T X.1520, CVE • Security Assurance Standards • ISO 15408 • Regional and Domain-specific Standards
15. Compliance & Security • Getting compliance on software updates takes time. Meanwhile .gov or hospitals might be vulnerable • Data localization doesn’t matter. Where are the keys stored? • Are standards kept up-to-date? • Studies show that password policies (rotation, restrictions …) make users less secure
16. Audits / Penetration Testing • How effective? Hard to say • Usually, easy to find the low-hanging fruit. Raising costs for attacker to find vulnerabilities • Most large tech companies have a “red team” that is constantly looking for vulnerabilities before the “bad guys” find them
17. Open-Source • Software being open-source enables easier third- party auditing of the software by security researchers and academics • Why easier? • No need for reverse engineering • Builds can be instrumented for analysis techniques (such as static analysis, fuzzing, constraint solving…)
18. Funding OSS as critical infrastructure • Important to identify and support open-source software that constitutes critical infrastructure for the EU • EU-FOSSA: Pilot Project for auditing of Open Source Software at the European Institutions
19. Reproducible Builds • What good is it that the source code of an application is online if it can’t be reproduced? • Reproducibility efforts supported by (containerized) deterministic build processes
20. Key Transparency • Certificate transparency holds certificate authorities accountable • Can be applied in other areas including software updates, end-to-end encrypted messaging (CONIKS) … • Distributed ledger community is working on solving similar problems
21. –Vladimir Lenin “Trust is good, control is better”
22. End-to-end Encryption ✉ “Trust us, we won’t read or mine your chats.” ✉ “You don’t have to trust us, we can’t read your chats”
23. Zero-Knowledge Systems “we know nothing about the encrypted data you store on our servers”
24. Formally verified software • Advances in formal methods helps us build safer software that operates matching a given formal specification • Still out of reach for large & fast-moving code bases
25. Proofs and Voting Can we trust them? • Let’s assume we have a formally verified implementation of a voting protocol that comes with strong security proofs • Should we be using it? • Lack of widespread understanding of how the voting system fundamentally works • “The election is gonna be rigged” feeling • There might be lower-level attacks • Does it run in a trusted environment? • How do we verify the silicon?
26. Thanks. Contact: me@fredericjacobs.com