1 Digital Signature and Digital Identity from RSA to eIDAS Emanuele CIsbani [email protected] 31-03-2021 - Università Milano Bicocca 

2 2 Agenda ● Beginning ● Standards ● Digital Identity ● Decentralization ● Tools 

3 Beginning 

Symmetric Cryptography Un uomo che non si interessa allo Stato noi non lo consideriamo innocuo, ma inutile; e benchè in pochi siano in grado di dare vita ad una politica, beh tutti qui ad Atene siamo in grado di giudicarla. Noi non consideriamo la discussione come un ostacolo sulla via della democrazia. Noi crediamo che la felicità sia il frutto della libertà, ma la libertà sia solo il frutto del valore. Insomma, io proclamo che Atene è la scuola dell’Ellade e che ogni ateniese cresce sviluppando in sé una felice versatilità, la fiducia in se stesso, la prontezza a fronteggiare qualsiasi situazione ed è per questo che la nostra città è aperta al mondo e noi non cacciamo mai uno straniero. Qui ad Atene noi facciamo così. 4 https://www.tools4noobs.com/online_tools/encrypt/ xq2YkJdEv5VjHIAEdnrRO09ldohxnj8DjNjFX73rHKMtxqX6cA I71TTPMILmCvRrh8yAwfLildPiy5XqXgdjQMg8VVer8k6oggiy QeKLI3vv1vwykvJwl1FIX6K+LywlaOTsKN5cEIKP95+I+I9mnr /lZuH+R2psdDs/bu6aw++3lYQq5/+Z55tuE49JZ+ABq7b71m+ F26BFn9jPYyxtFekUqOqDtLwJ4lyIFFK+qbTPpL/AEDrdQaee Gp7PINvc0Ejnhht8LjHGiAGenCoWud2FfhXEsJTT8+42VBs m1k3kN+CQ6wu9j2e2Bqr0UbhR6WJgadVk51Z21zBpBkLo1 Uc+veEUP6XDCzZBN/9D3HarJp6t+kLfOKOCjBBPxdIoYPkR qBWT9Pcm4bP0JDVBMUnmakSlpbndz+zXSaQZRVPwHuI1 dWtPW4ZPWhsevjQBrITKEnPszYuNTkb/Ouxb6qMr+NyX1G V5AQ+npMu+Lj5/QevpH99amyj8+caNrjdTUlOB0y5r/luQaF4 8xExenOc+8jn9vUJn3v5BX26hp9IEr4lnNMimmarH8H1V5Ov Wy6rSFxsr74tyZnmw4Il7TTcsTeLiLPs+7qqapTsZHejSVJB1x Y+5qWutvyzIYfSq2nuNHRPuwkdDC9VZPureEGwYi0pkdgfU DVm3RQLoWmrm8IayItFVcPxEHHHTce7pec4Y4+IktHQlJX SMrfbGFugRo/iAjy/+dp3rV0wFqsj6YGwlyWjWw0n1KXYHOG jIyWMbXG+2CxTI4qKRGI3kayz8HO0rHkNYZ9LgxnqTvKbQ Nvcd3g9u/r53q/wJ7WkGYjeRdlHvHSCLwFXdbUoja2Q+AjZu CXYI/vyASrgANh3wPNabnMhu5HpKkTkOuHfExsZPKHes7n 6GtqasQR5QiZ/evq613Os9BpXM2/WvCQn3773LdSrV2bqY Ac6g5SZe Pericle DES-CBC Base64 

Symmetric Cryptography In symmetric encryption, the recipient of the encrypted message must have the same key used by the sender who encrypted it This requires that the sender and recipient previously have a secure channel through which to exchange the key 5 

6 6-11-1976, New Directions in Cryptography Abstract - Two kinds of contemporary developments in cryptography are examined. Widening applications of teleprocessing have given rise to a need for new types of cryptographic systems, which minimize the need for secure key distribution channels and supply the equivalent of a written signature. This paper suggests ways to solve these currently open problems. It also discusses how the theories of communication and computation are beginning to provide the tools to solve cryptographic problems of long standing. Whitfield Diffie 5-6-1944 Prophet of Privacy Martin Hellman 1-10-1945 https://ee.stanford.edu/~hellman/publications/24.pdf https://cacm.acm.org/magazines/2016/6/202666-qa-finding-new-directions-in-cryptography/fulltext https://www.wired.com/1994/11/diffie/ 

7 Secure communication over an insecure channel The system...has since become known as Diffie–Hellman key exchange. While that system was first described in a paper by Diffie and me, it is a public key distribution system, a concept developed by Merkle, and hence should be called 'Diffie–Hellman–Merkle key exchange' if names are to be associated with it. I hope this small pulpit might help in that endeavor to recognize Merkle's equal contribution to the invention of public key cryptography. Martin Hellman Ralph C. Merkle (1952) 

8 1977 - Rivest, Shamir and Adleman Ron Rivest (1947), Adi Shamir (1952), and Leonard Adleman (1945) at the Massachusetts Institute of Technology, made several attempts over the course of a year to create a one-way function that was hard to invert. Rivest and Shamir, as computer scientists, proposed many potential functions, while Adleman, as a mathematician, was responsible for finding their weaknesses. For a time, they thought what they wanted to achieve was impossible due to contradictory requirements. In April 1977, they spent Passover at the house of a student and drank a good deal of Manischewitz wine before returning to their homes at around midnight. Rivest, unable to sleep, lay on the couch with a math textbook and started thinking about their one-way function. He spent the rest of the night formalizing his idea, and he had much of the paper ready by daybreak. source: https://en.wikipedia.org/ 

Asymmetric Cryptography With a key pair of which one is private and the other is public, it becomes possible to exchange information in a secure way in the absence of a secure channel The public key is used to encrypt and the private key to decrypt 9 

Digital Signature But we can use the keys also in the opposite sequence, ie we can use the private key to decipher (!) a data that is "clear text" - as if it were an enciphered data. The result is an unreadable "deciphered" data that only if "enciphered" with the corresponding public key regenerates the starting clear text message Since only the owner of the private key can generate it (deciphering), that strange "deciphered" data is a signature! 10 

Encryption and Signature 11 Hello Alice! 010010010 110111001 011000000 0 101010011 010010100 0110100111 encryption message signature decipher encipher verify sign 

12 Standards 

13 The critical connection between identity and key How to guarantee the signer identity? ● Certification Authority (CA) How to ensure that the signer has exclusive control of the private key? ● Hardware Security Module (HSM) and SmartCard ● Two Factor Authentication (2FA) How to manage the end of the exclusive control of the key before the expiration date? ● Revocation process ● Certificate Revocation List (CRL) ● Online Certificate Status Protocol (OCSP) ● Timestamp Service Authority (TSA) User Private Key 

14 Secure Signature Creation Device 

15 Smart Card 

16 RSA (1977) - Public Key Cryptography Standards Id Name Comments PKCS#7 Cryptographic Message Syntax Standard See RFC 2315. Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS #10 message). Formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on. PKCS#10 Certification Request Standard See RFC 2986. Format of messages sent to a certification authority to request certification of a public key. See certificate signing request. PKCS#11 Cryptographic Token Interface Also known as "Cryptoki". An API defining a generic interface to cryptographic tokens (see also hardware security module). Often used in single sign-on, public-key cryptography and disk encryption[10] systems. RSA Security has turned over further development of the PKCS #11 standard to the OASIS PKCS 11 Technical Committee. PKCS#12 Personal Information Exchange Syntax Standard See RFC 7292. Defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key. PFX is a predecessor to PKCS #12. This container format can contain multiple embedded objects, such as multiple certificates. Usually protected/encrypted with a password. Usable as a format for the Java key store and to establish client authentication certificates in Mozilla Firefox. Usable by Apache Tomcat. source: https://en.wikipedia.org/ 

17 RFC5280 - PKIX: Public Key Infrastructure (X.509) Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications. The components in this model are: ● end entity: user of PKI certificates and/or end user system that is the subject of a certificate; ● CA: certification authority; ● RA: registration authority, i.e., an optional system to which a CA delegates certain management functions; ● CRL issuer: a system that generates and signs CRLs; and ● repository: a system or collection of distributed systems that stores certificates and CRLs and serves as a means of distributing these certificates and CRLs to end entities. 

18 RFC5280 - PKIX: Public Key Infrastructure (X.509) 

19 RFC5652 - Cryptographic Message Syntax This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The CMS describes an encapsulation syntax for data protection. It supports digital signatures and encryption. The syntax allows multiple encapsulations; one encapsulation envelope can be nested inside another. Likewise, one party can digitally sign some previously encapsulated data. It also allows arbitrary attributes, such as signing time, to be signed along with the message content, and it provides for other attributes such as countersignatures to be associated with a signature. The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [PROFILE]. 

20 RFC5652 - Cryptographic Message Syntax (simplified) 

21 RFC3161 Time-Stamp Protocol (TSP) 

eIDAS: l’identità digitale a valore legale electronic IDentification Authentication and Signature eIDAS is the basis for the construction of the Digital Single Market in Europe eIDAS requires interoperability throughout Europe from 1/7/2016 The Qualified Electronic Signature has legal value equivalent to the handwritten one The Regulation implies mandatory adoption for all Member States 22 

23 European Telecommunications Standards Institute ETSI plays a key role in supporting regulation and legislation with technical standards and specifications. To do this they cooperate with other organizations including: ● the European Commission (EC) ● the European Free Trade Association (EFTA) ● the Electronic Communications Committee (ECC) of the European Conference of Postal and Telecommunications Administrations (CEPT) ● Supporting European regulation & legislation ETSI produces standards to support European regulation and legislation. These are defined in Regulations, Directives and Decisions developed by the EU. 

24 ETSI Advanced Electronic Signatures For an electronic signature to be considered as advanced, it must meet several requirements: ● The signatory can be uniquely identified and linked to the signature ● The signatory must have sole control of the signature creation data (typically a private key) that was used to create the electronic signature ● The signature must be capable of identifying if its accompanying data has been tampered with after the message was signed ● In the event that the accompanying data has been changed, the signature must be invalidated 

25 ETSI Advanced Electronic Signatures Advanced electronic signatures that are compliant with eIDAS may be technically implemented through the Ades Baseline Profiles that have been developed by the European Telecommunications Standards Institute (ETSI): ● CAdES, CMS Advanced Electronic Signatures is a set of extensions to Cryptographic Message Syntax (CMS) signed data making it suitable for advanced electronic signatures. ● PAdES, PDF Advanced Electronic Signatures is a set of restrictions and extensions to PDF and ISO 32000-1 making it suitable for Advanced Electronic Signature. ● XAdES, XML Advanced Electronic Signatures is a set of extensions to XML-DSig recommendation making it suitable for Advanced Electronic Signatures. ● ASiC Baseline Profile. ASiC (Associated Signature Containers) specifies the use of container structures to bind together one or more signed objects with either advanced electronic signatures or time-stamp tokens into one single digital (zip) container. 

26 ISO 32000-1:2008 - Portable Document Format ISO 32000-1:2008 specifies a digital form for representing electronic documents to enable users to exchange and view electronic documents independent of the environment in which they were created or the environment in which they are viewed or printed. It is intended for the developer of software that creates PDF files (conforming writers), software that reads existing PDF files and interprets their contents for display and interaction (conforming readers) and PDF products that read and/or write PDF files for a variety of other purposes (conforming products). 

27 PAdES - PDF Advanced Electronic Signatures ETSI - TS 102 778-1 - Electronic Signatures and Infrastructures (ESI) 

28 Electronic Signatures and Infrastructures source: ETSI TS 119 102-1 

29 Qualified Electronic Signature Creation Device QSCD is a Secure Signature Generation Device that is certified and approved for being used to generate Qualified Electronic Signatures (QES). It uses technical and procedural means to ensure: • Signing keys are kept secret • Signing keys are created using established cryptographic techniques • Signing keys can only be used by the right owner • Compliance to the stringent standards for QES. 

30 Qualified Trust Service Provider 

31 eIDAS Qualified Electronic Signature A qualified electronic signature is: ● an advanced electronic signature ● with a qualified digital certificate ● that has been created by a qualified trust service provider (QTSP) ● using a qualified signature creation device (QSCD) 

32 Digital Identity 

33 Digital Identity in EU - Today 

34 Digital Identity in Italy - Today ● Qualified Electronic Signature: users > 20 Mln, signs > 3 Bln/yr (AGID 2020) ● SPID (Sistema Pubblico Identità Digitale): 34 % of population (Oss. Poli Mi 2021) ● PEC (Posta Elettronica Certificata): users > 11 Mln, msgs > 3 Bln/yr (AGID 2020) ● eIDAS - Chapter II - Electronic Identification - (?) ● CID (Carta d'Identità Digitale) - No PIN no party! 

35 Digital Identity in EU - Tomorrow The Commission will soon propose a secure European e-identity. One that we trust and that any citizen can use anywhere in Europe to do anything from paying your taxes to renting a bicycle. A technology where we can control ourselves what data and how data is used. Ursula von der Leyen President of the European Commission 16 September 2020 

36 Digital Identity in EU - Challenges ● Levels of Assurance: Onboarding, AML/KYC, Legal Transactions, ... ● Model: Federated Trusted Identity Providers (or Self Sovereign Identity?) ● Technology: OAuth/SAML/OpenID-Connect (or SSI/EBSI/…?) ● Economic incentives to interoperability and standards adoption ● Monetization of the identification process carried by Identity Providers ● Governance Framework 

37 Decentralization 

38 1991 - Pretty Good Privacy Zimmermann had been a long-time anti-nuclear activist, and created PGP encryption so that similarly inclined people might securely use BBSs and securely store messages and files. No license fee was required for its non-commercial use, and the complete source code was included with all copies. PGP found its way onto the Internet and rapidly acquired a considerable following around the world. Users and supporters included dissidents in totalitarian countries (some affecting letters to Zimmermann have been published, some of which have been included in testimony before the US Congress), civil libertarians in other parts of the world (see Zimmermann's published testimony in various hearings), and the 'free communications' activists who called themselves cypherpunks (who provided both publicity and distribution); decades later, CryptoParty activists did much the same via Twitter. source: https://en.wikipedia.org/ 

39 1992 - The Web of Trust The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP version 2.0: As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys. source: https://en.wikipedia.org/ 

40 1997 - OpenPGP In July 1997, PGP Inc. proposed to the IETF that there be a standard called OpenPGP. The IETF accepted the proposal and started the OpenPGP Working Group. OpenPGP is on the Internet Standards Track and is under active development. Many email clients provide OpenPGP-compliant email security as described in RFC 3156. The current specification is RFC 4880 (November 2007), the successor to RFC 2440. RFC 4880 specifies a suite of required algorithms consisting of ElGamal encryption, DSA, Triple DES and SHA-1. In addition to these algorithms, the standard recommends RSA as described in PKCS #1 v1.5 for encryption and signing, as well as AES-128, CAST-128 and IDEA. Beyond these, many other algorithms are supported. The standard was extended to support Camellia cipher by RFC 5581 in 2009, and signing and key exchange based on Elliptic Curve Cryptography (ECC) (i.e. ECDSA and ECDH) by RFC 6637 in 2012. Support for ECC encryption was added by the proposed RFC 4880bis in 2014. source: https://en.wikipedia.org/ 

41 Resources GNU Privecy Guard https://gnupg.org/ Signing Your Code with Git https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work Key Server https://en.wikipedia.org/wiki/Key_server_(cryptographic) On Digital Signatures and Key Verification https://www.qubes-os.org/security/verifying-signatures/ 

42 Hal Finney Harold Thomas Finney II (May 4, 1956 – August 28, 2014) was a developer for PGP Corporation, and was the second developer hired after Phil Zimmermann. In his early career, he was credited as lead developer on several console games. He also was an early bitcoin contributor and received the first bitcoin transaction from bitcoin's creator Satoshi Nakamoto. source: https://en.wikipedia.org/ 

43 Timestamping Complementarity PKI-TSA Bitcoin-OTS A standard with legal value that has been around for a long time Not yet a standard A service that depends on a central trustee A service based on a permissionless, resilient and decentralized system, without a single point of failure Verifying a timestamp requires the involvement of the original issuing TSA Anyone can verify the timestamp autonomously running a Bitcoin full node or connecting to any trusted block explorer Usually a TSA undertakes to guarantee the validity of a timestamp for no more than twenty years There is no predefined limit to the validity of an OTS timestamp, the system aims to survive perpetually The service of qualified TSAs usually has a specific cost per single attestation The service is free of charge for clients and the cost for the provider is very low (a negligible fee for a small Bitcoin transaction, approximately every hour, no matter how many requests are aggregated each time) The timestamp issue is immediate The time attestation in the form of a promise is immediate, its upgrade takes about an hour Timestamps can reach fractional second precision The time attestation proves data existence only in an interval of hours "Chaining up Time" https://ssrn.com/abstract=3743330 

44 Tools 

45 Distrust the infrastructure Check the validity ● Check the integrity ● Check the authenticity ○ Check the ownership of the key ○ Check the expiration and revocation ○ Check the signature date and time 

46 Browser 

47 Acrobat 

48 OpenSSL Get and read a CRL ● openssl crl2pkcs7 -in example.crl -out example.p7m ● openssl pkcs7 -in example.p7m -print Get and read a Timestamp Response ● openssl ts -query -data file.png -no_nonce -sha512 -cert -out file.tsq ● curl -H "Content-Type: application/timestamp-query" --data-binary '@file.tsq' https://freetsa.org/tsr > file.tsr ● openssl ts -reply -in file.tsr -text 

49 Resources Verify https://vol.ca.notariato.it/it Italian Trusted LIST https://www.agid.gov.it/it/piattaforme/firma-elettronica-qualificata/certificati EU Trusted LIST (Root CA Certs) https://webgate.ec.europa.eu/tl-browser/#/ 

50 Grazie! Emanuele CIsbani [email protected] 30-03-2021 - Università Milano Bicocca