Secure Communication by Ratcheting F Bet¨ ul Durak and Serge Vaudenay ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE SV 2018 ratchet ASK 2018 1 / 43
Secure Communication 1 Ratcheting 2 Our Results 3 SV 2018 ratchet ASK 2018 2 / 43
Secure Communication 1 Ratcheting 2 Our Results 3 SV 2018 ratchet ASK 2018 3 / 43
Atomic Secure Communication Init $ sk ct pt pt Send Receive the state is a (symmetric) secret key sk; it is FIXED Init $ − → sk Send ( sk , pt ) → ct Receive ( sk , ct ) → pt ′ correctness : pt = pt ′ security : ...check the literature on AE... SV 2018 ratchet ASK 2018 4 / 43
Aim: Communication Integrity Init $ ( sk , 0 ) ct 1 pt 1 pt 1 Send Receive ( sk , 1 ) ( sk , 1 ) ct 2 pt 2 pt 2 Send Receive ( sk , 2 ) ( sk , 2 ) ct 3 pt 3 pt 3 Send Receive . . . . . . security : the list of received messages can only be (a prefix of) the list of sent messages SV 2018 ratchet ASK 2018 5 / 43
Aim: Forward Privacy Init $ st S ( 0 ) st R ( 0 ) ct 1 pt 1 pt 1 Send Receive st S ( 1 ) st R ( 1 ) ct 2 pt 2 pt 2 Receive Send st S ( 2 ) st R ( 2 ) ct 3 pt 3 pt 3 Send Receive . . . . . . security : leaking st S ( 2 ) , st R ( 2 ) does not compromise pt 1 , pt 2 SV 2018 ratchet ASK 2018 6 / 43
Aim: Post-Compromise Security (1) Init $ st S ( 0 ) st R ( 0 ) ct 1 pt 1 Send $ pt 1 Receive st S ( 1 ) st R ( 1 ) ct 2 pt 2 Send $ pt 2 Receive st S ( 2 ) st R ( 2 ) ct 3 pt 3 Send $ pt 3 Receive . . . . . . security : leaking st S ( 1 ) does not compromise any message! SV 2018 ratchet ASK 2018 7 / 43
Aim: Post-Compromise Security (2) Init $ st S ( 0 ) st R ( 0 ) ct 1 pt 1 Send $ pt 1 Receive st S ( 1 ) st R ( 1 ) ct 2 pt 2 Send $ pt 2 Receive st S ( 2 ) st R ( 2 ) ct 3 pt 3 Send $ pt 3 Receive . . . . . . security : leaking st R ( 1 ) compromises pt 2 , pt 3 (there is nothing to do about it) SV 2018 ratchet ASK 2018 8 / 43
Aim: Bidirectional Communication Init $ st A ( 0 ) st B ( 0 ) ct 1 pt 1 Send $ pt 1 Receive st A ( 1 ) st B ( 1 ) ct 2 pt 2 Send $ pt 2 Receive st A ( 2 ) st B ( 2 ) ct 3 pt 3 Send $ pt 3 Receive st A ( 3 ) st B ( 3 ) ct 4 pt 4 Send $ pt 4 Receive . . . . . . SV 2018 ratchet ASK 2018 9 / 43
Aim: Asynchronous + Random Role Init $ st A ( 0 ) st B ( 0 ) pt A 1 Send $ Send $ pt B 1 st A ( 1 ) st B ( 1 ) pt A 2 Send $ pt A 1 Receive st A ( 2 ) st B ( 2 ) pt B 1 Send $ pt B 2 Receive st A ( 3 ) st B ( 3 ) pt B 2 pt A 2 Receive Receive . . . . . . SV 2018 ratchet ASK 2018 10 / 43
Secure Communication 1 Ratcheting 2 Our Results 3 SV 2018 ratchet ASK 2018 12 / 43
Ratchet state update in a one-way manner (for forward security ) using randomness (for post-compromise security ) SV 2018 ratchet ASK 2018 13 / 43
Bidirectional Asynch. Ratcheted Key Agreement Init $ st A ( 0 ) st B ( 0 ) Send $ Send $ k A 1 k B 1 st A ( 1 ) st B ( 1 ) k A 2 Send $ k A 1 Receive st A ( 2 ) st B ( 2 ) Send $ k B 1 k B 2 Receive st A ( 3 ) st B ( 3 ) k B 2 k A 2 Receive Receive . . . . . . SV 2018 ratchet ASK 2018 14 / 43
CRYPTO 2017 Bellare-Singh-Asha-Jaeger-Nyayapati-Stepanovs Ratcheted Encryption and Key Exchange: The Secu- rity of Messaging unidirectional no receiver leakage allowed complicated definitions SV 2018 ratchet ASK 2018 15 / 43
CRYPTO 2018 Poettering-R¨ osler Ratcheted Key Exchange, Revisited Jaeger-Stepanovs Optimal Channel Security Against Fine-Grained State Compromise: The Safety of Messaging both need key update primitives (HIBE, random oracles, ...) complicated definitions SV 2018 ratchet ASK 2018 16 / 43
Poettering-R¨ osler Security Game SV 2018 ratchet ASK 2018 17 / 43
Jaeger-Stepanovs Security Game SV 2018 ratchet ASK 2018 18 / 43
Cryptosystem with Key Update (for PR18 and JS18) Generate $ Encrypt ( pk , pt ) $ Decrypt ( sk , ct ) → pt ′ , → ( sk , pk ) , → ct, − − UpdateSk ( sk , ad ) → sk ′ , UpdatePk ( pk , ad ) → pk ′ correctness : for all coins, pt, ad 1 , . . . , ad n , if Generate $ pk sk ad 1 UpdatePk UpdateSk ad 1 ad n UpdatePk UpdateSk ad n pk ′ sk ′ ct Encrypt $ pt ′ pt Decrypt then pt = pt ′ security : ...well... SV 2018 ratchet ASK 2018 19 / 43
Cryptosystem with Key Update from HIBE Algorithm Generate () 1: HIBE . Init $ − → ( msk , mpk ) 2: pk ← ( mpk , ⊥ ) ▷ second part is id (empty for root) 3: return ( msk , pk ) ▷ root secret is msk Algorithm UpdateSk ( sk , ad ) 4: return HIBE . Extract ( sk , ad ) ▷ extract ad-child secret Algorithm UpdatePk ( pk , ad ) 5: parse pk = ( mpk , id ) ▷ mpk never changes 6: return ( mpk , id . ad ) ▷ just concatenate ad to id Algorithm Encrypt ( pk , pt ) 7: parse pk = ( mpk , id ) 8: return HIBE . Encrypt ( mpk , id , pt ) Algorithm Decrypt ( sk , ct ) 9: return HIBE . Decrypt ( sk , ct ) SV 2018 ratchet ASK 2018 20 / 43
Signature with Key Update (for JS18) Generate $ Sign ( sk , m ) $ → ( sk , vk ) , → σ , Verify ( vk , σ, m ) → accept / reject, − − UpdateSk ( sk , ad ) → sk ′ , UpdatePk ( vk , ad ) → vk ′ correctness : for all coins, m , ad 1 , . . . , ad n , if Generate $ sk vk UpdateVk ad 1 UpdateSk ad 1 ad n UpdateSk UpdateVk ad n sk ′ vk ′ m , σ Sign $ m Verify out then out = accept security : ...well... SV 2018 ratchet ASK 2018 21 / 43
Secure Communication 1 Ratcheting 2 Our Results 3 SV 2018 ratchet ASK 2018 22 / 43
Our Definition 3 algorithms: Init $ , Send $ , Receive correctness KIND-security: generated keys look like random caveat: exceptions... (difficult to identify) FORGE-security: participants see the same messages caveat: “trivial forgeries” (after state exposure) RECOVER-security: after forgeries, genuine messages are no longer accepted SV 2018 ratchet ASK 2018 23 / 43
BARK Bidirectional Asynchronous Ratcheted Key Agreement SV 2018 ratchet ASK 2018 24 / 43
Correctness For all sequence sched, Pr[ Correctness ( sched ) → 1 ]= 0 Oracle RATCH ( P , rec , upd ) Game Correctness ( sched ) 1: ( acc , st ′ P , k P ) ← Receive ( st P , upd ) 1: set all lists and queues to ∅ 2: if acc then $ 2: Init ( 1 λ ) → ( st A , st B , z ) − st P ← st ′ 3: 3: i ← 0 P append k P to received P 4: 4: loop key 5: end if 5: i ← i + 1 6: return acc 6: ( P , role ) ← sched i if role = rec then 7: Oracle RATCH ( P , send ) if in queue P empty then return 0 8: 7: ( st ′ P , upd , k P ) ← Send ( st P ) pull upd from in queue P 9: 8: st P ← st ′ P acc ← RATCH ( P , rec , upd ) 10: 9: append k P to sent P key if acc = false then return 1 11: 10: return upd if received P key not prefix of sent P key then return 1 12: 13: else upd ← RATCH ( P , send ) 14: push upd to in queue P 15: 16: end if 17: end loop SV 2018 ratchet ASK 2018 25 / 43
KIND Security � [ ] [ ]� For all ppt A , � KIND A KIND A � � Pr 0 , C clean → 1 − Pr 1 , C clean → 1 � = negl ( λ ) Game KIND A Oracle TEST ( P ) b , C clean 1: if t test ̸ = ⊥ then abort 1: set all variables to ⊥ $ 2: if k P = ⊥ then abort 2: Init ( 1 λ ) − → ( st A , st B , z ) 3: b ′ ← A RATCH , EXP st , EXP key , TEST ( z ) 3: t test ← time 4: if b = 1 then 4: if ¬ C clean then abort return k P 5: 5: return b ’ 6: else return random { 0 , 1 } | k P | 7: 8: end if exclude trivial attacks Oracle EXP key ( P ) 1: return k P the EXP oracles can be used for Oracle EXP st ( P ) trivial attacks without forgeries 1: return st P not easy to identify trivial attacks in the case of forgeries SV 2018 ratchet ASK 2018 26 / 43
A Few Technical Notions: Matching Status t ′ ≤ t ⇒ ∃ t , t ′ P in matching status at time t ⇐ received P msg ( t )= sent P msg ( t ) received P msg ( t )= sent P msg ( t ′ ) P P Property t ′ If P in matching status at time t ... ... P in matching status at time t t ... P in matching status at any time < t ... P and P generate the t same keys SV 2018 ratchet ASK 2018 27 / 43
A Few Technical Notions: Direct Leakage k P ( t ) directly leaks if we are in one of those configurations: P P P P t RATCH t RATCH t 0 ( EXP key ) t e t ( EXP st ) t e no RATCH no RATCH Receive t ( EXP key ) t e t t RATCH no RATCH t ( P in matching status at time t ) SV 2018 ratchet ASK 2018 28 / 43
A Few Technical Notions: Indirect Leakage k P ( t ) indirectly leaks if P is in matching status at time t and either the corresponding k P ( t ) directly leaks or we are in this configuration: P P t ′ t RATCH t Send t e ( EXP st ) no RATCH t SV 2018 ratchet ASK 2018 29 / 43
A Few Cleanness Notions C leak : k P test ( t test ) does leaks neither directly nor indirectly mandatory: we must have this clause in C clean C P test trivial forge : P test had no trivial forgery before seeing upd test C A , B trivial forge : neither A nor B had a trivial forgery before seeing upd test C ratchet : upd test was sent by a participant P , then accepted by P , then P sent some upd, then it was accepted by P ( C leak ∧ C P test trivial forge ) -KIND security ← PR18 and JS18 ⇓ ( C leak ∧ C A , B trivial forge ) -KIND security ← our protocol ⇓ (++) ( C leak ∧ C ratchet ) -KIND security ← we are happy here SV 2018 ratchet ASK 2018 30 / 43
Recommend
More recommend
