TLS 1.3, https://caniuse.com 19 mai 2019

Web Security

PKI Applications Lecture 7

Pascal Lafourcade

2019-2020

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

2 / 118

Aper¸cu

TLS 1.3, https://caniuse.com 19 mai 2019

4 / 118

TLS 1.3, https://caniuse.com 1 mai 2020

TLS 1.3

I Clean up: Remove unused or unsafe features

I Security: Improve security by using modern security analysis techniques

I Privacy: Encrypt more of the protocol

I Performance: Our target is a 1-RTT handshake for naive clients; 0-RTT handshake for repeat connections

I Continuity: Maintain existing important use cases https://tlswg.github.io/tls13-spec/

6 / 118

TLS 1.3 removes obsolete and insecure features

I SHA-1 I RC4 I DES I 3DES I AES-CBC I MD5

I Arbitrary Diffie-Hellman groups — CVE-2016-0701 I EXPORT-strength ciphers – Responsible for FREAK and

LogJam

TLS 1.3 1-RTT handshake: 12 messages in 3 flights, 16 derived keys, then data exchange.

TLS 1.3 : Notations 1

8 / 118

TLS 1.3 : Notations 2

TLS 1.3 : Notations 3

10 / 118

TLS 1.3 : Handshake

TLS 1.3 : Resumption

12 / 118

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

Attacks cryptographie Sp´ ecification Implentation alea

I 1995 : n´egociation `a la baisse dans SSLv2

I 1998 : attaque de Bleichenbacher sur PKCS#1 v1.5 I 2002 : Mauvaise interpr´etation de l’extension X.509 (IE) I 2008 : contournement de la validation de certificats OpenSSL I 2009 : collision MD5 sur des certificats concrets

I 2009 : attaque sur la ren´egociation

I 2009 : confusion dˆue `a des caract`eres nuls dans les certificats

I 2011 : BEAST attaque TLS 1.0 attaque sur l’IV implicite dans le mode CBC I 2011 : Mauvaise interpr´etation de l’ extension X.509 (iOS)

I 2012 : Mining your Ps and Qs (absence d’al´ea `a la g´en´eration de cl´e RSA) I 2013 : Lucky 13 (oracle de padding CBC) + biais statistiques sur RC4 I 2014 : goto fail Apple

I 2014 : contournement de la validation de certificats dans GnuTLS I 2014 : Triple Handshake (ren´egociation et reprise de session) I 2014 : Heartbleed et EarlyCCS

I 2015 : FREAK et LogJam I 2016 : DROWN

14 / 118

Failles dans SSL/TLS

I Des vuln´erabilit´essont toujours d´ecouvertes dans SSL/TLS I derni`ere en date : DROWN, rendue publique le 1<sup>er</sup>mars 2016 I Il y a des correctifs, mais les serveurs doivent ˆetre mis `a jour

I ren´egociation non s´ecuris´ee(2009, MITM) : 1,8 +0,6 % vuln´erables

I BEAST(Browser Exploit Against SSL/TLS, 2011, violation de la contrainte d’origine des cookies) : 91,5 %

I CRIME(Compression Ratio Info-leak Made Easy, 2012) : 3,2 %

I d´egradation du protocole(forcer l’utilisation de SSL 3.0) : 28,0 %

I attaques sur RC4(2013) : 8,5+34,8 % I POODLE sur TLS(2014) : 3,0 %

I Heartbleed(2014, acc`es m´emoire arbitraire dans OpenSSL) : 0,3 %

I pas de forward secrecy: 21,2 +29,4 %

I cl´es trop petites: 0,1 % (cl´e publique),6,9 +25,2 % (´ech. de cl´es)

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

16 / 118

TLS 1.2 AES CBC

CBC:

Ci =EK(Pi⊕Ci−1),C0 =IV Pi =DK(Ci)⊕Ci−1,C0 =IV

M has to be pad usingPKCS₇ : Pad with n bytes each equal to n: 01,0202,030303,04040404,etc ... if n= 0 then add a full block of 16.

Padding Oracle

If padding is incorrect⇒ error message.

TLS 1.2 AES CBC

C₀=IV,C_i =E_K(P_i⊕Ci−1),P_i =D_K(C_i)⊕Ci−1

Last-bit Attack

I ConsiderC₁⁰||C2 whereC₁⁰ =r1||r2||. . .||r15||l16

I We try all values for l16

I If Padding oracle answer the cipherC0||C₁⁰||C2 is valid then P2[16] = 01 we deduceD_K(C2)[16] =l16⊕P2[16].

else try another value ofl₁₆

It works since we just modify one bit so if the oracle says yes then we deduce that the padding is 01.

18 / 118

TLS 1.2 AES CBC

Previous Last-bit Attack

I ConsiderC₁⁰||C2 whereC₁⁰ =r1||r2||. . .||r14||l15||l16

I We try all values for l15 andl16 such that P2[16] = 02 it means l16⊕c2[16] = 02, so l16=c2[16]⊕02

I If Padding oracle answer the cipherC0||C₁⁰||C2 is valid then P₂[15] = 02 we deduceD_K(C₂)[15] =l₁₅⊕P₂[15].

else try another value ofl₁₅ And so on ...

TLS 1.2 AES CBC

Padding Attack

I Apply previous method for all bits of last messsages.

I Then to all blocks.

I Only for IV you need to perform a brute force attack which is resaonable.

20 / 118

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

Padding Oracle On Downgraded Legacy Encryption:

Poodle

I Attaque sur SSL 3.0, Google le 14 octobre 2014.

I Permet de d´echiffrer les informations ´echang´ees entre client et serveur

I SSL 3.0 utilise RC4 / CBC

22 / 118

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

Compression Ratio Info-leak Made Easy CRIME

ClientHello and ServerHello: Negociation of Compression Algorithm

DEFLATE Algorithm: combination of the LZ77 (Dictionary coder) algorithm and Huffman coding.

GOAL:

Recover secret authentication cookies, to do session hijacking on an authenticated web session.

24 / 118

Idea of CRIME

I Active attack

I Observation of the change in size of the compressed request payload.

I composed of the secret cookie and content added by the attacker.

I If the size of compressed content is reduced ⇒ injected content matches some part of the secret

I Divide and conquer techniques are used to recover the secret.

Idea of CRIME on an example

I If request contains ”cookie =123” and ”cookie =456”

compression of size k

I If request contains ”cookie = 123” and ”cookie = 156”

compression of size k⁰ <k

I If request contains ”cookie = 123” and ”cookie = 126”

compression of size k⁰⁰<k⁰

I If request contains ”cookie = 123” and ”cookie = 123”

compression of size k⁰⁰⁰ <k⁰⁰

Prevention

I Upgrade your browser to the latest version I Disable compression

26 / 118

Idea of CRIME on an example

I If request contains ”cookie =123” and ”cookie =456”

compression of size k

I If request contains ”cookie = 123” and ”cookie = 156”

compression of size k⁰ <k

I If request contains ”cookie = 123” and ”cookie = 126”

compression of size k⁰⁰<k⁰

I If request contains ”cookie = 123” and ”cookie = 123”

compression of size k⁰⁰⁰ <k⁰⁰ Prevention

I Upgrade your browser to the latest version I Disable compression

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

27 / 118

TLS Attack

FREAK attack [BDFKPSZZ 2015] : Implementation flaw ; use fast 512-bit factorization to downgrade modern browsers to broken export-grade RSA

Logjam : Active downgrade to export DH

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

29 / 118

Heartbleed : Mars 2014 par Google et Codenomicon

I Int´egr´ee par erreur lors de la mise `a jour Heartbeat I Permet d’acc´eder `a n’importe quelle donn´ee en clair I Tr`es dangereux : ne laisse aucune trace

Principe

I Oubli de validation de la correspondance entre la taille de la r´eponse et la taille demand´ee par le client

I Le client peut demander une r´eponse plus longue que pr´evu, et obtenir des donn´ees contenues dans le buffer

Heartbleed : Principe

Fonctionnement normal

I Client : Dis-moi “Hello” ca fait 5 lettres I Sever : Hello

Attaque

I Client : Dis-moi “Hello” ca fait 500 lettres I Sever :

Hello -livereload-port 35729 --dev-logger-port 53703 --nobrowserLocal:http://localhost:8 100External:http://172.27.64.63:81 00 DevApp:

31 / 118

Heartbleed : Correctif

/* Read type and payload length first */

hbtype = *p++;

n2s(p, payload);

/* Correctif */

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0;

/* silently discard per RFC 6520 sec. 4 */

pl = p;

/* Enter response type, length and copy payload */

*bp++ = TLS1_HB_RESPONSE;

s2n(payload, bp);

memcpy(bp, pl, payload);

Ne pas utiliser les versions vuln´erables d’OpenSSL (1.0.1 `a 1.0.1f inclus)

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

33 / 118

HSTS :HTTP Strict Transport Security

Activation pour 1 an avec sous domaines et pr´echarg´e : Strict-Transport-Security "max-age=31536000;

includeSubDomains; preload""

I Remplace automatiquement tous les liens non s´ecuris´es par des liens s´ecuris´es avant d’acc´eder au serveur.

I Si la s´ecurit´e de la connexion ne peut ˆetre assur´ee (par exemple, le certificat TLS est auto-sign´e), celui-ci affiche un message d’erreur et interdit `a l’utilisateur l’acc`es au site `a cause de cette erreur.

But

Prot´eger les utilisateurs de sites web contre quelques attaques r´eseau passives (´ecoute clandestine) et actives.

Une attaque du type man-in-the-middle ne peut pas intercepter de requˆete tant que le HSTS est actif pour ce site.

Pour s’enregistrer : hstspreload.org

HSTS Installation for Apache Web Server

# Use HTTP Strict Transport Security to force client

# to use secure connections only

Header always set Strict-Transport-Security

"max-age=300; includeSubDomains; preload"

Exemples : Paypal

35 / 118

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

Web security analysis,

2. Analyse Application

————————

Applications logic

3. Test Clinet-side controls 9. Test for logic flaws Acces Handing

4. Test authentication 5. Test session management 6. Test access controls Input Hnadling

7. Fuzz all parameters

8.Test for issues with specfic functionalities Application Hosting

10. Test fro shared hosting issues 11. Test the web server

————————

12. Miscellaneous Checks 13. Information Leakage.

37 / 118

1. Map application content

Linked content

1.1 Explore visible content 1.2 Consult public ressources

—————————

Other content

1.3 Discover hidden content 1.4 Discover default content

—————————

Non-standard access method 1.5 Identifier-specific functions 1.6 Debug parameters

2. Analyse Application

2.1 Identify functionality 2.2 Identify data entry points 2.3 Identify technologies

=>Map the attack surface

39 / 118

3. Test Clinet-side controls

3.1 Transmission of data via client Hiddent fields

Cookies

Preset parameters ASP.NET ViewState 3.2. Client-side input controls

Lenght Limits JavaScript validation Disable Elements 3.3 Browser Extensions

Java applets ActiveX controls Flash objects Sliverlight objects

4. Test authentication

4.1 Undestand the mechanism Data attacks

4.2 Test password quality

4.3 Test for username enumeration 4.4 Test for password guessing Special functions

4.5 Test account recovery 4.6 Test “rememberme”

4.7 Test impersonation function Credential handling

4.8 Test username uniqueness 4.9 Test credential predictability 4.10 Check unsafe transmission 4.11 Check for unsafe distribution 4.12 Check insecure storage Authentication logic

4.13.1 Test for fail-opne logic 4.13.2 Test for multistage processes 4.14 Exploit vulnerabilities

41 / 118

5. Test session management

5.1 Understand the mechanism Token Generation

5.2 Test for meaning 5.3 Test for predactibility Token Handling

5.4 Check for insecure transmission 5.5 Check for disclosure login

5.6 Test mappingof token to sessions 5.7 Test session termination

5.8 Test for session fixation 5.9 Check for CSRF

5.10 Check cookies scope

6. Test access controls

6.1 understand the requirements 6.2 Test with multiple accounts 6.3 Test with limites acces 6.4 Test for insecure methods

43 / 118

7. Fuzz all parameters

7.1 Fuzz all request parameters 7.2 SQL Injectionf

7.3 XSS and response injection 7.4 OS command injection 7.5 Path traversal

7.6 Script injection 7.7 File inclusion

8.Test for issues with specfic functionalities

8.1 SMTP injection 8.2 Native code flaws 8.3 SOAP injection 8.4 LDAP injection 8.5 XPath injection

8.6 Back-end request injection 8.7 XXE injection

45 / 118

9. Test for logic flaws

9.1 Identify key attack surface 9.2 Multisatge processes 9.3 Incomplete input 9.4 Trust boundaries 9.5 Transaction logic

10. Test fro shared hosting issues

10.1 Test segregation in shared infrastructures

10.2 Test segregation between ASP-hosted applications

47 / 118

11. Test fro shared hosting issues

11.1 Test for default credetnials 11.2 Test for default content

11.3 Test for dangerous HTTP methods 11.4 Test for proxy functionality

11.5 Test for virtual hosting misconfiguration 11.6 Test for web server software bug

11.7 Test for web application firewalling

12. Miscellanous Checks

12.1 Test for DOM-based attacks 12.2 Test for local privacy vulnerabilities 12.3 Test for weak SSL/TLS ciphers

12.4 Check same -origin policy configuration

49 / 118

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

Cookies

Implemented in 1994 in Netscape and described in 4-page draft I No spec for 17 years

I Attempt made in 1997, but made incompatible changes I Another attempt in 2000 (”Cookie2”), same problem I Around 2011, another effort succeeded (RFC 6265) I Ad-hoc design has led to interesting issues

51 / 118

Cookies attributes

I Expires - Specifies expiration date. If no date, then lasts for session

Browsers do session restoring, so can last way longer!

I Path - Scope the ”Cookie” header to a particular request path prefix

I Domain - Allows the cookie to be scoped to a domain broader than the domain that returned the Set-Cookie header

Set-Cookie: theme=dark; Expires=¡date¿;

Fingerprinting, passive tracking

Website finds things different about each visitor to re-identify users!

Exemple

I Browsers used I OS used I Fonts installed I Plugins installed I Video/Audio Hardware I Software installed

You are unique ! https://panopticlick.eff.org

https://audiofingerprint.openwpm.com/

https:

//www.leblogduhacker.fr/ce-que-lon-sait-sur-vous/

https://history.google.com/history/ ^{53 / 118}

Google Safe Browsing

Google maintains a list of known malware/phishing URLs

https://testsafebrowsing.appspot.com/s/phishing.html

Google Safe Browsing

https://transparencyreport.google.com/safe-browsing/

overview

I Browser queries the list on every navigation NO

I Send URLs to the Google Safe Browsing server to check their status

I Privacy: URLs are not hashed, so the server knows which URLs you look up

https://testsafebrowsing.appspot.com/

55 / 118

Shodan

First search engine for Internet-connected devices.

https://www.shodan.io/

I Google I Facebook I Twitter I Linkedin I WebPage

I Recherche Sur Twitter https://followerwonk.com/

I Search by Name and Find People in the USA.

https://www.zabasearch.com/

I Trouvez une entreprise, un particulier partout dans le monde https://www.infobel.com/

I Lullar informations `a partir d’email

https://lullar-com-3.appspot.com/en I Spokeo informations sur les r´eseaux sociaux

https://www.spokeo.com/

57 / 118

Webmii

People search engine

https://webmii.com/

Cookieless cookies

Utilisation des ETag !

I Le navigateur envoie au serveur Apache, l’ETag du fichier qu’il s’apprˆete `a lui demander et qu’il poss`ede dans son cache.

I Si l’ETag est identique⇒ pas besoin de le t´el´echarger ! CQFD

http://lucb1e.com/rp/cookielesscookies/

59 / 118

Contre mesures

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

61 / 118

Application : Messagerie instantan´ ee

62 / 118

Application : Off-the-Record Messaging (OTR)

Invent´e par N. Borisov, I. Goldberg et E. Brewer en 2004.

I Confidentialit´e : Personne ne peut lire vos messages I Authentification : Sˆur de parler `a son interlocuteur

I R´evocabilit´e (deniability) des conversations : personne ne doit pouvoir prouver que vous ˆetes l’auteur des messages.

I Les messages sont authentiques et non-modifi´es

I Confidentialit´e persistante (Perfect forward secrecy) : La perte des clefs priv´ees ne compromet pas les conversations pass´ees.

Utilise AES, SHA-1, Diffie-Hellman dans le protocole AKE

63 / 118

Application : AKE

(1) ^AESr(g

x)||HASH(g^x)

−−−−−−−−−−−−−−−−−−−−−−−→

g^y

←−−−−−−−−−−−−−−−−−−−−−−− (2)

Bob (3) −−−−−−−−−−−−−−−−−−−−−−−→^{r||AESc(XB)||MACm2(AESc(XB))} Alice

AES_c0(X_A)||MAC_m0

2(AES_c0(X_A))

←−−−−−−−−−−−−−−−−−−−−−−− (4)

(5) ^TA||MACmk(TA)||oldmackeys

−−−−−−−−−−−−−−−−−−−−−−−→

A partir de` s := (gy)^x g´en´ere par hachage : I 2 clefs sym´etriquesc etc⁰

I 4 clefs MAC m₁,m⁰₁,m₂ et m⁰₂ X_B :=Kpub_B||keyid_B||SIGB₍M_B) X_A :=Kpub_A||keyid_A||SIG_A(M_A)

MB :=MACm1(g^x||g^y||KpubB||keyidB) ; M_A :=MAC_m⁰

1(g^y||g^x||Kpub_A||keyid_A) ;

T_A:= (keyid_A||keyid_B||next_dh||ctr||AES−CTR_ek,ctr(msg))

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

65 / 118

Idea of Zero Knowledge Proof

Prover (P)

(P) convinces (V) that it knows something without revealing any information

Verifier (V)

Applications:

I Authentication systems: prove its identity to someone using a password without reavealing anything about the secret. I Prove that a praticipant behavior is correct according to the

protocol (e.g. integrity of ballots in vote).

I Group signature, secure multiparty computation, e-cash ...

Idea of Zero Knowledge Proof

Prover (P)

(P) convinces (V) that it knows something without revealing any information

Verifier (V) Applications:

I Authentication systems: prove its identity to someone using a password without reavealing anything about the secret.

I Prove that a praticipant behavior is correct according to the protocol (e.g. integrity of ballots in vote).

I Group signature, secure multiparty computation, e-cash ...

66 / 118

Cave example (0)

Door with a secret code

Cave example (I)

V waits outside while P chooses a path

68 / 118

Cave example (II)

V enters and shouts the name of a path

Cave example (III)

P returns along the desired path (using the secret if necessary)

A= “P does not know the secret” is equivalent to say “P is lucky”

Pr[A] = 1 2 Afterk tries,

Pr[A] = (1 2)^k

A= “P knows the secret”, then Pr[A] = 1−Pr[A] = 1−(1

2)^k

70 / 118

Cave example (III)

P returns along the desired path (using the secret if necessary) A= “P does not know the secret”

is equivalent to say “P is lucky”

Pr[A] = 1 2

Afterk tries,

Pr[A] = (1 2)^k

A= “P knows the secret”, then Pr[A] = 1−Pr[A] = 1−(1

2)^k

Cave example (III)

P returns along the desired path (using the secret if necessary) A= “P does not know the secret”

is equivalent to say “P is lucky”

Pr[A] = 1 2 Afterk tries,

Pr[A] = (1 2)^k

A= “P knows the secret”, then Pr[A] = 1−Pr[A] = 1−(1

2)^k

70 / 118

Cave example (III)

P returns along the desired path (using the secret if necessary) A= “P does not know the secret”

is equivalent to say “P is lucky”

Pr[A] = 1 2 Afterk tries,

Pr[A] = (1 2)^k

A= “P knows the secret”, then Pr[A] = 1−Pr[A] = 1−(1

2)^k

Graph 3-coloring is NP-complete: • • •

1 2

3 4

5

6 7

8

9

10

Petersen graph

71 / 118

Graph 3-coloring is NP-complete: • • •

1 2

3 4

5

6 7

8

9

10

Petersen graph

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u∈V,r_u

→ ∀u ∈V,eu =H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(v_j))−→ V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj) Choosesi andj

72 / 118

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→ V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj) Choosesi andj

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→ V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj) Choosesi andj

72 / 118

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→ V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj)

Choosesi andj

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→ V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj)

Choosesi andj

72 / 118

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→

V accepts, ife_ui =H(π(c(u_i))||r_ui) and e_uj =H(π(c(u_j))||r_uj)

Choosesi andj

P wants to prove to V his 3-coloring of G = (E , V )

P selects a permutationπ of the 3 colors.

π(

1 2

4 3 5

6 7

8 9

10

)=

1 2

4 3 5

6 7

8 9

10

Chooses∀u ∈V,r_u

→ ∀u ∈V,eu=H(π(c(u))||ru)→

←−u_i,u_j ←−

−→r_ui,r_uj, π(c(u_i)), π(c(vj))−→

V accepts, ife_ui =H(π(c(u_i))||r_ui) and

e_uj =H(π(c(u_j))||r_uj) Choosesi andj

72 / 118

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t=g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s Chooses a randomc t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t=g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s Chooses a randomc t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

73 / 118

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s Chooses a randomc t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→ V accepts, ift·y^c =g^s

Chooses a randomc

t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

73 / 118

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→ V accepts, ift·y^c =g^s

Chooses a randomc

t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s

Chooses a randomc

t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

73 / 118

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s Chooses a randomc

t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

Schnorr Protocol, 1991

LetG_q a cyclic group of orderq with a public generatorg Goal

P wants to prove the knowledge ofx, where y=g^x

Chooses a randomr

−→t =g^r −→

←−c ←−

−→s =r+x·c −→

V accepts, ift·y^c =g^s Chooses a randomc t·y^c =g^r ·(g^x)^c =g^r+x·c =g^s

73 / 118

Things to bring home

I Existence of Interactive Zero-knowledge Proof I 3 protocols :

1. Cave

2. Graph 3 coloring

3. Discret Logarithm (Schnorr)

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

75 / 118

Asynchronous Messaging Protocols

Secure Channel

Alice and Bob need not be online at the same time to communicate.

Stage Definition

Chain 1 1. Hello

2. How are you?

...

Chain 2

1. Good, and you?

...

Chain 3 1. Great!

...

Stage (1,1): “Hello“

Stage (2,1): “How are you? “ Stage (1,2): “Good, and you? “ Stage (x,y): x^th message of chain y

77 / 118

Security Properties

I Confidentiality I Authentication

I PFS: Perfect Forward Secrecy I PCS: Post-Compromise Security

PFS and PCS

PFS: Protects sessionsbefore a compromise happens.

compromise

PCS: Protects sessionsafter a compromise happens. compromise

79 / 118

PFS and PCS

PFS: Protects sessionsbefore a compromise happens.

compromise

PCS: Protects sessionsafter a compromise happens.

compromise

Signal protocol

I The Signal protocol achieves (amongst other things) PCS by its double-ratchet algorithm.

I Idea: key evolution (symmetric and asymmetric).

80 / 118

Simple ratchet

H−→ Key Derivation Function (KDF)

x 7→H(x)7→H(H(x))7→. . .

asymmetric: x−→ obtained via DH value. symmetric: x−→ chain key (ck).

Simple ratchet

H−→ Key Derivation Function (KDF)

x 7→H(x)7→H(H(x))7→. . .

asymmetric: x−→ obtained via DH value.

symmetric: x−→ chain key (ck).

81 / 118

Simple ratchet

H−→ Key Derivation Function (KDF)

x 7→H(x)7→H(H(x))7→. . .

asymmetric: x−→ obtained via DH value.

symmetric: x−→ chain key (ck).

Ratcheting in Signal

ms: master secret rk: root key

dh: Diffie-Hellman value ck: chain key mk: message key I Asymmetric

ms KDFr

rk ck

KDFr

dh

dh rk⁰

ck⁰

I Symmetric

ck KDF_m

ck⁰ mk

KDF_m

ck” mk⁰

82 / 118

Ratcheting in Signal

ms: master secret rk: root key

dh: Diffie-Hellman value ck: chain key mk: message key I Asymmetric

ms KDFr

rk ck

KDFr

dh

dh rk⁰

ck⁰

I Symmetric

ck KDF_m

ck⁰ mk

KDF_m

ck”

mk⁰

Full Ratcheting

ms KDF_r

rk₁ ck^1,1

KDF_r dh

dh rk2

ck^1,2

KDF_m

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

83 / 118

Full Ratcheting

ms KDF_r

rk₁ ck^1,1

KDF_r dh

dh rk2

ck^1,2

KDF_m

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

Full Ratcheting

ms KDF_r

rk₁ ck^1,1

KDF_r dh

dh rk2

ck^1,2

KDF_m

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

83 / 118

Compromise example

ms KDFr

rk1

ck^1,1

KDFr

dh

dh rk₂

ck^1,2

KDFm

ck^2,1 mk^1,1

KDF_m

ck^3,1 mk^2,1

KDFm

ck^2,2 mk^1,2

KDF_m

ck^3,2 mk^2,2

ck^2,1

ck^3,1 dh

Compromise example

ms KDFr

rk1

ck^1,1

KDFr

dh

dh rk₂

ck^1,2

KDFm

ck^2,1 mk^1,1

KDF_m

ck^3,1 mk^2,1

KDFm

ck^2,2 mk^1,2

KDF_m

ck^3,2 mk^2,2 ck^2,1

ck^3,1

dh

84 / 118

Compromise example

ms KDFr

rk1

ck^1,1

KDFr

dh

dh rk₂

ck^1,2

KDFm

ck^2,1 mk^1,1

KDF_m

KDFm

ck^2,2 mk^1,2

KDF_m ck^2,1

dh

Registration phase

Each partyP registers public keys on a server:

I identity key: ipk_P I signed pre-key: prepkP

Alice retrieves Bob’s public key to initiate the communication

→ms.

85 / 118

Compromising Signal

ik_I ek_I rchk^0,1

ipkR prepkR

rchk^0,2 DH(prepkR,ikI) DH(ipkR,ekI)DH(prepkR,ekI)

DH(prepkR,rchk^0,1) ms

X3DH

KDFr

ck^1,1

KDFm

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

rk1

DH(rchpk^0,1,rchk^0,2)

KDFr

ck^1,2

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

KDFr

rchk^0,3

DH(rchpk^0,2,rchk^0,3)

ck^1,3 rk2

KDF_m

ck^2,3 mk^1,3

KDFm

ck^3,3 mk^2,3

ikI ekI rchk^0,1

ms

DH(prepk_R,rchk^0,1)

ck^1,1

ck^2,1

ck^3,1

rk₁

ck^1,2

ck^2,2

ck^3,2

DH(rchpk^0,2,rchk^0,3)

Compromising Signal

ik_I ek_I rchk^0,1

ipkR prepkR

rchk^0,2 DH(prepkR,ikI) DH(ipkR,ekI)DH(prepkR,ekI)

DH(prepkR,rchk^0,1) ms

X3DH

KDFr

ck^1,1

KDFm

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

rk1

DH(rchpk^0,1,rchk^0,2)

KDFr

ck^1,2

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

KDFr

rchk^0,3

DH(rchpk^0,2,rchk^0,3)

ck^1,3 rk2

KDF_m

ck^2,3 mk^1,3

KDFm

ck^3,3 mk^2,3

ik_I ek_I rchk^0,1

ms

DH(prepk_R,rchk^0,1)

ck^1,1

ck^2,1

ck^3,1

rk₁

ck^1,2

ck^2,2

ck^3,2

DH(rchpk^0,2,rchk^0,3)

86 / 118

Compromising Signal

ik_I ek_I rchk^0,1

ipkR prepkR

rchk^0,2 DH(prepkR,ikI) DH(ipkR,ekI)DH(prepkR,ekI)

DH(prepkR,rchk^0,1) ms

X3DH

KDFr

ck^1,1

KDFm

ck^2,1 mk^1,1

KDFm

ck^3,1 mk^2,1

rk1

DH(rchpk^0,1,rchk^0,2)

KDFr

ck^1,2

KDF_m

ck^2,2 mk^1,2

KDFm

ck^3,2 mk^2,2

KDFr

rchk^0,3

DH(rchpk^0,2,rchk^0,3)

ck^1,3 rk2

KDF_m

ck^2,3 mk^1,3

KDFm

ck^3,3 mk^2,3

ik_I ek_I rchk^0,1

ms

DH(prepkR,rchk^0,1)

ck^1,1

ck^2,1

ck^3,1

rk1

ck^1,2

ck^2,2

ck^3,2

DH(rchpk^0,2,rchk^0,3)

Outline

TLS 1.3 Attacks

CBC Padding Oracle Attack Poodle Attack

CRIME Attack Freak Attack Heartbleed HSTS Methodology Privacy/Tracing OTR

ZKP Signal

Bitcoin et altcoins Conclusion

87 / 118

La r´ evolution Bitcoin 2009

Bitcoin

I Cryto-monnaie d´ecentralis´ee et distribu´ee

21 millions BTC

89 / 118

Inarrˆ etable car distribu´ ee

Infalsifiable

91 / 118

Auditable

Bitcoin : monnaie ´ electronique

Cr´e´ee en 2008 par Satoshi Nakamoto (1 BTC≈945 euros)

1 BTC = 1 Bitcoin

0,01 BTC = 1 cBTC = 1 centiBitcoin (ou bitcent) 0,001 BTC = 1 mBTC = 1 milliBitcoin

0,000 001 BTC = 1 µBTC = 1 microBitcoin 0,000 000 01 BTC = 1 Satoshi

93 / 118

Taux de change du bitcoin

2013/01 2013/06 2014/01 2014/06 2015/01 2015/06 2016/01 2016/06 2017/01 2017/06 2018/01 2018/06 2019/01 2019/06 2020/01

0e 5 000e 10 000e 15 000e

Euros

C o u r s d u b i t c o i n e n e

Clef sym´ etrique

chiffrement d´echiffrement

Clef symétrique Clef symétrique

Exemples I DES I AES

95 / 118

Chiffrement ` a clef publique

chiffrement d´echiffrement

Clef publique

Clef privée

Exemples

I RSA :c =m^e mod n I ElGamal : c ≡(g^r,h^r ·m)

Signature

signature

clef secr´ete clef publique v´erification

Clef privée

Clef publique

RSA:m^d modn

97 / 118

Signature

signature

clef secr´ete clef publique v´erification

Clef privée

Clef publique

RSA:m^d modn

Fonction de Hachage (RIPEMD-160, SHA-256, SHA-3)

Propri´et´es de r´esitance I Pr´e-image

I Seconde Pr´e-image

I Collision

98 / 118

Fonction de Hachage (RIPEMD-160, SHA-256, SHA-3)

Propri´et´es de r´esitance I Pr´e-image

I Seconde Pr´e-image

I Collision

Fonction de Hachage (RIPEMD-160, SHA-256, SHA-3)

Propri´et´es de r´esitance I Pr´e-image

I Seconde Pr´e-image

I Collision

98 / 118

Fonction de Hachage (RIPEMD-160, SHA-256, SHA-3)

Propri´et´es de r´esitance I Pr´e-image

I Seconde Pr´e-image

I Collision

Bitcoins : caract´ eristiques

I Le nombre total de bitcoins est fini 21 millions BTC I Les transactions utilisent desPKI I Num´ero de compte :

RIPEMD-160(SHA-256(ECDSA_pub)) I Toutes les transactions sont publiques I Blockchain : un syst`eme pair-`a-pair qui

garantit la validit´e des transactions

99 / 118