reklama

Perfect Forward Secrecy i pro „asynchronní komunikaci“?

Zajímalo by mě, pro jaké druhy komunikace funguje perfect forward privacy. U komunikace v reálném čas to je jasné, to je OTR. Ale jde to i pro klasickou asynchronní "poštu"? Hraje v tom roli požadavek na end to end šifrování (a teď nemyslím tu parodii, co mají  kapitalistické komunikační služby, že sice šifrují, ale jen k uživatelům, takže na serveru jsou čitelné)

 Co k tomu je potřeba? (Například být nějaký čas společně online, aby si obě strany "vyměnili klíč" pro následující zprávu)

A pak dotaz k OTR? Jak často je dobré měnit samotné šifrovací klíče? U každé zprávy/ u každé relace nebo každý týden nebo po x bajtech dat? Co například hrozí, když se klíče mění po týdnu a co útočník musí udělat k jakým zprávám bude mít přístup (například k incidentu dojde 4. den, tak jestli to ohrozí bezpečnost zpráv 2. den nebo 6. den)
« Poslední změna: 03. 04. 2019, 10:36:16 od Petr Krčmář »
vitalia.cz,root.cz,lupa.cz##+js(addEventListener-defuser.js, mousedown)
/promo/api$xmlhttprequest
##.design-advert
fuckadblock.js$script

reklama


Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #1 kdy: 30. 05. 2019, 08:59:03 »
No a to je právě to.  Předpokládám, že u DNSSEC je to stejné, že s jiným časem tedy nelze zaručit tu autenticitu a klidně mohu komunikovat s někým jiným jiným. Chci, aby mi to fungovalo i s jiným časem (se všemi riziky). Ale chci mít možnost, aby to fungovalo i takto a ne že, když budu mít jiné datum, tak v rámci bezpečnosti "nenavážu ani bajt".

O jaké DNSSEC klienty jde? systémové? v prohlížečích? je na to nějaký flag jako výše?
vitalia.cz,root.cz,lupa.cz##+js(addEventListener-defuser.js, mousedown)
/promo/api$xmlhttprequest
##.design-advert
fuckadblock.js$script

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #2 kdy: 30. 05. 2019, 09:18:01 »
Předchozí příspěvek jsem chtěl změnit, ale neuložil se. Smazat už nejde.
Chtěl jsem se zeptat na další  věci:

  • Jaký je rozdíl mezi Obyčejným a Perfect forward privacy
  • Když se mluví o forward privacy u https, znamená to že bez něj (dřív) to fungovalo tak, že se k šifrování používal  jedno z tohoto?
    - veřejný a soukromý klíč serveru (furt stejný)-tedy asymetrická šifra. Ale i v klubu zahrádkářů se ví, že asymetrické šifry jsou tak 1000x pomalejší, takže to se mi nezdá, takže 2. možnost
    - symetrický klíč, který je nějak určen na začátku komunikace, ale pokud asym. klíče se dozví protiNSAtrana, dozví se i ten symetrický?
    _ Následně se to změnilo tak, že je klíč generovaný pomocí Diffí Hellmana (tudíž náhodný, kde náhodnost pochází od klienta i servera) a jeho pravost zaručena pomocí soukromého klíče serveru.  tím pádem tohle stačí k tomu, aby se dalo mluvit o forward secrecy?
vitalia.cz,root.cz,lupa.cz##+js(addEventListener-defuser.js, mousedown)
/promo/api$xmlhttprequest
##.design-advert
fuckadblock.js$script

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #3 kdy: 30. 05. 2019, 11:48:01 »
SSL/TLS komunikace vždy používá pro šifrování přenášených dat symetrickou šifru. Klíče se vyměňují na začátku spojení a případně může později v rámci probíhajícího spojení dojít k výměně nových klíčů.

Předpokládám, že se ptáte na perfect forward secrecy. Standardní TLS komunikace je taková, že pokud si někdo uloží obsah šifrované komunikace a následně by se mu podařilo získat privátní klíč serveru, dokáže zpětně komunikaci rozšifrovat. PFC znamená, že když teď zaznamenáte tu šifrovanou komunikaci, bude chráněná i v budoucnosti, konkrétně v případě úniku privátního klíče serveru.

Princip PFC spočívá v tom, že se obě komunikující strany dohodnou na tajném klíči, které znají obě strany ale nedá se (ani se znalostí privátního klíče serveru) z té komunikace získat. Teoreticky byste to mohl použít i u asynchronní komunikace – obě strany by si nejprve vyměnily informace, aby mohly ustavit ten tajný klíč. Ale v praxi se to nepoužívá, není k tomu důvod. Privátní klíč, kterým dešifrujete e-maily, byste měl být schopen chránit mnohem lépe, než jak je chráněn privátní klíč třeba webového serveru. Server potřebuje ten privátní klíč při každém navázání TLS spojení, takže tam nemůže někdo sedět a pokaždé zadávat PIN, například.

DNSSEC s tím nijak nesouvisí, tam se nijak nešifruje, jenom podepisuje.

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #4 kdy: 31. 05. 2019, 12:09:50 »
Standardní TLS komunikace je taková, že pokud si někdo uloží obsah šifrované komunikace a následně by se mu podařilo získat privátní klíč serveru, dokáže zpětně komunikaci rozšifrovat.
Tohle je ten zakopaný pes. Asi jen z historických důvodů mě zajímá, jestli tehdy bez PFC samotné šifrování probíhalo přímo asymetricky(klíčem byl přímo priv.klíč) a nebo symetrickou šifrou(která byla nějak dohodnuta  jinak pomocí Diffí Hellmana a  tudíž šla odvodit z zaznamenané komunikace.)

Takže dnes se https používá 3 algoritmy:
-asymetrická šifra( RSA / Eliptické křivky), aby klient mohl ověřit autenticitu serveru
-algoritmus  pro vyjednání (tajného + volatilního ) šifrovacího klíče- Diffí Hellman (RSA / EC)
- nějaká symetrická šifra (AES,RC4 slabá?) pro vlastní obsah
Není to jednoduché pochopit, co je zač, když to člověk nezná, navíc když je tam "popis šifry" 3x a a navíc Eliptická může být šifra i DH výměna, různé přípony způsobu řetězení bloků CEC,XTS. V chromu vidím zase kulový. Dřív to ukazovalo tohle, ale není to vidět ani v konzoli-Security ani u zámečku.

druhý příspěvek sem nepatřil. Ptal jsem se i na " obyčejné forward secrecy".
vitalia.cz,root.cz,lupa.cz##+js(addEventListener-defuser.js, mousedown)
/promo/api$xmlhttprequest
##.design-advert
fuckadblock.js$script

reklama


Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #5 kdy: 31. 05. 2019, 12:44:29 »
Tohle je ten zakopaný pes. Asi jen z historických důvodů mě zajímá, jestli tehdy bez PFC samotné šifrování probíhalo přímo asymetricky(klíčem byl přímo priv.klíč) a nebo symetrickou šifrou(která byla nějak dohodnuta  jinak pomocí Diffí Hellmana a  tudíž šla odvodit z zaznamenané komunikace.)
Samotná komunikace byla vždy šifrovaná symetricky.

-asymetrická šifra( RSA / Eliptické křivky), aby klient mohl ověřit autenticitu serveru
Autenticita serveru se ověřuje na základě podpisu certifikátu a toho, že server podá důkaz vlastnictví privátního klíče příslušejícího k certifikátu. Sice podpisy a šifrování fungují na podobných principech, ale doporučuju to nemíchat.

-algoritmus  pro vyjednání (tajného + volatilního ) šifrovacího klíče- Diffí Hellman (RSA / EC)
Bez PFS si kleint a server nešifrovaným kanálem vymění náhodná čísla a klient pošle serveru před-klíč zašifrovaný veřejným klíčem serveru. Z toho se pak vyrobí skutečný šifrovací klíč použitý pro (symetrické) šifrování komunikace. Pokud někdo šifrovanou komunikaci odposlechne a zaznamená, a později získá privátní klíč serveru, dokáže rozšifrovat ten před-klíč poslaný klientem a tím pádem má všechny informace, které měly k dispozici klient i server, dokáže odvodit použitý šifrovací klíč a komunikaci rozšifrovat.

Algoritmus D-H výměny klíčů je založený na tom, že během výměny klíčů pořád zůstává část, kterou zná jenom klient nebo jenom server a není to privátní klíč serveru. Takže i když si útočník komunikaci uloží a později získá privátní klíč serveru, pořád nemá dostatek informací, aby dokázal zrekonstruovat šifrovací klíč použitý pro šifrování komunikace.

- nějaká symetrická šifra (AES,RC4 slabá?) pro vlastní obsah
Těch variant je spousta, ještě se liší podle velikostí klíčů. Je to jeden z parametrů komunikace, který si na začátku dohadují klient se serverem. A taky jedno z potenciálních míst útoku, když se útočníkovi podaří některé nabízené algoritmy z komunikace odstranit a donutí tak obě strany, aby se dohodly na nějaké slabé šifře, kterou umí útočník zlomit.

druhý příspěvek sem nepatřil. Ptal jsem se i na " obyčejné forward secrecy".
Nic takového neexistuje. Resp. někdy se to používá jako synonymum pro PFS.

Není to jednoduché pochopit, co je zač, když to člověk nezná, navíc když je tam "popis šifry" 3x a a navíc Eliptická může být šifra i DH výměna, různé přípony způsobu řetězení bloků CEC,XTS. V chromu vidím zase kulový. Dřív to ukazovalo tohle, ale není to vidět ani v konzoli-Security ani u zámečku.

Pokud vás zajímá, jak funguje TLS, doporučuju The Illustrated TLS Connection.

Jinak u reálné komunikace zrovna webové prohlížeče do toho vstupuje ještě fakt, že (s HTTP/1.1) má prohlížeč typicky otevřených spojení několik, klíče rotuje docela často a navíc tak, aby je měl předem připravené – takže když má nějaký důvod komunikovat se serverem, používá starý klíč ale zároveň si bokem dohodne se serverem nový klíč, který použije příště. Což je zase umožněné díky tomu, že si klient se serverem mohou dohodnuté klíče uložit bokem a použít je při navazování dalšího TLS spojení, čímž se přeskočí úvodní handshake, který trvá docela dlouho. Takže když máte webový prohlížeč a snažíte se analyzovat jeho TLS provoz, není to vůbec jednoduché se v tom zorientovat.

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #6 kdy: 01. 06. 2019, 20:13:03 »
Teoreticky u asynchronní komunikace bychom PFS mohli dosáhnout pomocí nějakých krátkodobějších klíčů. I když, nevím, jestli bych tomu říkal PFS. A praktické využití je s otazníkem, můžeme být nuceni ten klíč například uložit na disk. Nebo jej uložíme do RAM a v případě restartu budeme po protistraně chtít zprávu poslat znovu, což ale otevírá prostor pro další útoky.

> PFC

Co je PFC? Myslel jsem si, že jde o překlep k „PFS“, ale vidím to tu opakovaně…

 > A taky jedno z potenciálních míst útoku, když se útočníkovi podaří některé nabízené algoritmy z komunikace odstranit a donutí tak obě strany, aby se dohodly na nějaké slabé šifře, kterou umí útočník zlomit.

Určitě je dobré slabé ciphersuites pokazazovat, ale mohou znamenat menší riziko, než jak to může vypadat na první pohled. Aby se použila nějaká slabá šifra (přesněji ciphersuite), musí (aspoň při správně implementaci TLS) současně:

1. Klient tuto ciphersuite podporovat (a tedy poslat v seznamu podporovaných ciphersuites client hello).
2. Server tuto šifru podporovat.
3. Server tuto šifru musí vybrat, tedy ji musí upřednostnit před všemi ostatními cuphersuites poslanými prohlížečem.

Nabízí se tu ještě možnost, jak toto obejít. Útočník pozmění komunikaci (nejspíš zúží seznam podporovaných ciphersuites v client hello) a nechá klienta se serverem vyjednat slabší ciphersuite. To by ale mělo být odhaleno, pokud si dobře pamatuju, v závěru handshake při zprávě finished. Takže jediná šance, jak by mohl útočník provést downgrade (bez zneužití implementačních chyb a při podpoře a preferenci lepších ciphersuites) je udělat zásadní průlom již při handshake. To se teoreticky může stát, ale při pohledu na historické zranitelnosti, uspějete možná tak u export-grade ciphersuites.

Pokud je tedy podporována dostatečně velká škála moderních ciphersuites, pak nějaká archaická nemusí být s trochou štěstí rizikem. Tím nepopírám, že je best practice to vypnout, pokud to jde.

> Takže dnes se https používá 3 algoritmy:

Kromě podpisových algoritmů certifikátu (kterých se mimochodem může použít i více při jednom spojení), algoritmu pro výměnu klíčů a algoritmu pro samotné šifrování tu je ještě:

* Typicky mode of operation (pokud to má u dané šifry smysl).
* Autentizační algoritmus. Pomocí něj lze detekovat, že se někdo snaží komunikaci pozměnit. Když budu vědět, že posíláte šifrovaně příkaz k platbě, mám za určitých podmínek určité možnosti to různě upravit – změnit třeba částku nebo příjemce. Tomu ale brání právě autentizace (MAC). MAC je jako digitální podpis, ale symetrický.  Někdy je autentizace již součástí mode of operation, což je například u AES-GCM a tuším obecně u všech ciphersuites v TLS 1.3.
* Pseudorandom function – nějaká hashovací funkce. Nechci teď hledat, kde se přesně používá, ani sem psát nějaké tušení.
* A to je snad všechno (lovím to z hlavy).

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #7 kdy: 03. 06. 2019, 00:14:09 »
Zminil bych zde ECIES - https://cs.wikipedia.org/wiki/ECIES - coz je kryptosystem, ktery je zamereny na ochranu payloadu, nikoliv transportni vrstvy (aka kontrast k TLS/SSL).
Neni to samozrejme Perfect Forward Secrecy, ale je to urcite zajimavy koncept toho, jak 'znahodnit' zpravu tak, aby stejny obsah, ktery je sifrovan pro stejneho prijemce vypadal po kazde jinak.

Samozrejme hodne zjednodusuji.

Potkal jsem systemy zalozene na ECIES (napr. C-ITS pro car-to-car komunikaci), ktere dosahuji podobneho stavu jako u PFS tim, ze maji hodne agresivni rotaci klicu, tzn. prijemce ma nekolik paru klicu, ty se rotuji v ramci minut, takze pokud nekdo disponuje zachycenymi zpravami a ukradl vam nejake klice, tak dokaze desifrovat pouze velmi maly usek prenasenych dat.
« Poslední změna: 03. 06. 2019, 00:19:24 od alexfa »

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #8 kdy: 03. 06. 2019, 08:05:11 »
Neni to samozrejme Perfect Forward Secrecy, ale je to urcite zajimavy koncept toho, jak 'znahodnit' zpravu tak, aby stejny obsah, ktery je sifrovan pro stejneho prijemce vypadal po kazde jinak.
To je ale něco jiného, než PFS. I u běžného šifrování zpráv (např. e-mailů) pomocí PKI je zašifrovaná zpráva pokaždé jiná. Šifruje symetrickou šifrou s náhodně vygenerovaným klíčem, ke zprávě se připojí i ten klíč a jenom ten se zašifruje asymetrickou šifrou. Tím, že je šifrovací klíč náhodně generovaný, bude i identická zpráva zašifrována pokaždé jinak. A podle popisu ECIES mi připadá, že používá přesně stejné schéma šifrování, tj. pokud útočník získá privátní klíč příjemce, dokáže dešifrovat dříve přenesené zprávy.

Potkal jsem systemy zalozene na ECIES (napr. C-ITS pro car-to-car komunikaci), ktere dosahuji podobneho stavu jako u PFS tim, ze maji hodne agresivni rotaci klicu, tzn. prijemce ma nekolik paru klicu, ty se rotuji v ramci minut, takze pokud nekdo disponuje zachycenymi zpravami a ukradl vam nejake klice, tak dokaze desifrovat pouze velmi maly usek prenasenych dat.
To je pak ale FS zajištěna tou rychlou rotací klíčových dvojic, ne šifrovacím schématem. A mimochodem na tu rychlou rotaci klíčů bude potřeba dost entropie.

Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?
« Odpověď #9 kdy: 03. 06. 2019, 11:11:54 »
To, že stejnou zprávu zašifrujete pokaždé jinak, je běžný požadavek, a až na speciality jako AES-SIV (které se explicitně snaží být deterministické) je to dnes v moderní kryptografii zajištěno snad všude, protože máte nějakou nonce, o kterou se algoritmus opře. Nedělá se to jen kvůli tomu, aby útočník nedovedl detekovat dvě identické zprávy, ale i aby nedovedl detekovat dvě podobné zprávy (stejný prefix, stejný suffix, …), případně i kvůli dalším útokům (xor attack na streamovou šifru). Podmínkou je samozřejmě unikátní nonce* a nesmíme použít nějakou legacy věc jako ECB.

*) Jedna z mnoha nástrah pro začátečníky: Chce to po mě nějaký nonce, co já vím, co to je? Hodím tam pár bajtů, co my přišly pod ruku. Jé, ono to nějak šifruje, to asi bude OK. Jenže není, takováto věc může útočníkovi odkrýt zajímavé informace.


 

reklama