Attribute-based Authentication and Signing with IRMA Summer School - PowerPoint PPT Presentation

Where we are, so far Attribute-based Authentication and Signing with IRMA Summer School on real-world crypto and privacy IRMA overview Bart Jacobs — Radboud University and Privacy by Design foundation bart@cs.ru.nl Cryptographic essentials Šibenik, Croatia, 15 June 2018 IRMA in action Conclusions Page 1 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing IRMA Demo: authenticate/sign with relevant IRMA history, in two phases attributes only Essentials: 2008 – now : scientific research project at Radboud University ◮ • active research line on attribute-based authentication attributes instead of ◮ • 3 PhD theses so far, postdocs too, many publications identities, on user’s phone financial support from: NLnet, Translink, BZK, NWO, KPN • collected by user him/herself ◮ prototype implementations on: • attributes are reliable ◮ smart card — at first, but no longer supported ◮ (digitally signed by source) smart phone — for Android only ◮ both authentication and ◮ signing 2016 – now : technology deployment via non-profit foundation ◮ https://privacybydesign.foundation set up in fall 2016 • decentralised architecture: ◮ foundation runs infrastructure, and issues some attributes • attributes only on phone eg. from: iDIN (banks), EduGain (academia), BIG (health) • Cryptographic basis: Idemix ◮ both Android and iOS apps, with common code-base in Go • IRMA is free & open source ◮ • attribute verification pilots are emerging • attribute-based signatures added recently Page 2 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 3 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing IRMA overview IRMA overview

� � � � � � � � � � � � Centralised versus decentralised, schematically Bigger picture: open identity platform Centralised : everything goes via the Identity Provider (eg. FB Connect) The internet was designed without security or identity guarantees ◮ understandable, at the time • 3 prove Identity increasingly a problem: identity fraud, lack of trust, missed • · · · Verifier Verifier Provider 3 opportunities authenticate • many ad hoc solutions, often harming privacy 1 2 2 1 User IRMA has the grand ambition to be such identity add-on ◮ it’s globally available, see dashboard page with metrics • Decentralised : everyting goes via the User (think IRMA) not : one size fits all, like Facebook connect • but : different attributes, depending on national traditions • Identity · · · Verifier Verifier • identity management is culturally sensitive Provider • it requires national ‘trust anchors’, see later prove issue prove 2 1 3 User Page 4 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 5 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing IRMA overview IRMA overview Bigger picture: General Data Protection Regulation Bigger picture: non-profit sector realisation GDPR has identity management requirements in two places: Identity management is a strategic and sensitive topic ◮ Inspection rights ◮ • it’s all about regulating who has access to what & who checks • people can ask organisations what data they have on them, for Public authorities often do a bad/mediocre job which purpose, from which sources, etc. ◮ they fail altogether: NL (partly), UK, US, . . . • also: right of correction & deletion • or they come up with privacy-unfriendly (always identifying, • only possible with (strong) authentication of the requestor • centralised) solutions: Estonia, Belgium, India, . . . Consent obligations ◮ Corporations have too many side-interests ◮ each form of data processing requires a legal ground (art. 6) • • either making it expensive or forcing user profiling • one such ground is consent, for a specific purpose • also centralised solutions • consent requirements are in art. 7: free, separate, clear, etc. typically they are not universally trusted by citizens — certainly • processor must keep “proof” of consent; what is it? • not when they monopolise best realisation: digital signatures • Maybe non-profit organisations can do IT better they can be stored, and shown to others — like regulators ◮ • ☛ ✟ eg. Let’s Encrypt in US, or SIDN in NL (for domain names) • ✞ ☎ • IRMA is also a social experiment IRMA is the unique platform with integrated authentication & signing ✝ ✆ • its decentralised architecture requires alternative funding ✡ ✠ Page 6 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 7 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing IRMA overview IRMA overview

Bigger picture: value-driven design Where we are, so far After Cambridge-Analytica scandal one reaction was that our ◮ ICT-infrastructure needs to better reflect moral values esp. ‘public’ and/or ‘European’ values should be better reflected • not only ‘code as legal order’ but also ‘code as moral order’ • IRMA overview value-driven (or value-sensitive) design exists as academic strand ◮ Cryptographic essentials much of this work remains rather theoretical • IRMA tries to bring this into practice. Emphasis on: ◮ IRMA in action self-sovereignty — terminology nicked from blockchain believers • transparancy and openness (e.g. of code and designs) • independent, non-for-profit and non-monopolising Conclusions • decentralised • • both security and privacy — not just one of them • catch-phrase: contextual authentication & signing — after Helen Nissenbaum’s contextual privacy/integrity Page 8 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing IRMA overview Credentials and attributes in IRMA context Example credential: address An IRMA app contains multiple credentials, each with multiple attributes: Address Country     City  Separately usable  attributes Street + Number     Credential =  Postal code Issued eg. by: public authorities, or by banks Name is not included here; can be stored elsewhere ◮ The issuer’s signature guarantees authenticity and integrity ◮ Expiry info is omitted, but exists per credential, not per attribute ◮ Any subset of the attributes can be shown in transactions. ◮ Same attribute (eg. name) can be in different credentials, from ◮ This is called selective disclosure. different issuers, with different trust levels (eg. Facebook or banks) Page 9 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 10 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Cryptographic essentials Cryptographic essentials

Attribute representation I Attribute representation II System parameters : Let k be the secret key. A credential is a triple: ◮ n = pq , for large “safe” primes: p , q , where p = 2 p ′ + 1 , q = 2 q ′ + 1, � 1 / e ◮ � Z with also p ′ , q ′ prime v , e , C = 0 R a 1 1 R a 2 2 R a 3 3 R a 4 S v R k 4 The pair ( p , q ) is the secret key of the credential issuer where v , e are random, with e · 1 / e ≡ 1 mod φ ( n ) = ( p − 1 )( q − 1 ) . quadratic residues: R 0 , R 1 , R 2 , R 3 , R 4 , S , Z ∈ QR n ⊆ Z ∗ ◮ n The crucial signature verification equation is: (5 R ’s, for say 4 attributes per credential, plus the user’s secret key) ◮ C e · S v · R k 0 · R a 1 1 · R a 2 2 · R a 3 3 · R a 4 Z mod n ≡ 4 A 4-tuple ( a 1 , a 2 , a 3 , a 4 ) of attributes a i is represented via a multi-exponent: R a 1 1 · R a 2 2 · R a 3 3 · R a 4 ∈ Z n 4 Blinding of the signature/credential the equation still holds for v ′ := v + e · r , C ′ := C · S − r This multi-exponent must be randomised and signed , via a so-called ◮ Camenisch-Lysyanskaya signature (2002). the RSA-exponent e remains the same; it is not disclosed itself to ◮ the verifier, but only via a zero-knowledge proof Page 11 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 12 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Cryptographic essentials Cryptographic essentials Selective disclosure essentials Signing in IRMA, via Schnorr ZKP (with memory refresh) Assume I wish to disclose attributes a 1 , a 3 , but not a 2 , a 4 . Assume a generator g ∈ G in a finite group of prime order q , with ◮ ◮ publicly given h = g x ∈ G , where x ∈ Z ∗ • The blinding of the credential e , v , C is skipped here q . I reveal attribute values a 1 , a 3 and credential (parts) v , C P wants to prove to V that she knows x — without revealing it. ◮ ◮ Via a zero-knowledge proof I show that I know exponents ε, κ, α 2 , α 4 def ◮ = g w ∈ G P − → V : a with w ∈ Z ∗ q random with: V − → P : c ∈ Z q a random challenge Z C ε · S v · R κ def 0 · R α 2 · R α 4 ≡ mod n P − → V : r = c · x + w 2 4 R a 1 1 · R a 3 3 V now checks g r ?? = h c · a Note that V can prove nothing to others: anyone can produce values ◮ r and a with g r = h c · a . This is also a signature scheme: take hash of message as challenge: ◮ c = H ( m ) . Idemix is used this way in IRMA, with domain separation & extended ◮ with a time-stamp server — using quantum secure signature! Page 13 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Page 14 of 30 Jacobs Šibenik, Croatia, 15 June 2018 Authentication and Signing Cryptographic essentials Cryptographic essentials