Bezpečný přenos hesla/klíče

[Ondřej Novák]

Ahoj.

Tak zajímavě se rozjela diskuze o obtížném dešifrování, doufám, že stejně dobře mi poradíte i v tomto případě. Potřebuju bezpečně přenést heslo/klíče z jednoho počítače na druhý, který má bohužel jednu zásadní nevýhodu. Je pořád stejné. Ale mělo by se vždy po použití smazat. Přesněji je součástí jiného většího hesla/klíče a slouží k tomu, aby k odemčení zašifrovaných dat byly vždy dvě strany. Ta druhá strana zároveň svou částí hesla autorizuje požadavek, který zasílá, tedy mělo by být nemožné, aby se za tuto stranu někdo vydával. Je samozřejmě jisté že,

1. přenášet mohu pochopitelně po zabezpečeném kanále (SSL/TSL)
2. mohu k autentifikaci použít digitální podpis.
I tak to ale znamená, že přijímaci strana musí vědět, že nebyla oklamána. Ideální bylo, kdyby součástí požadavku bylo i heslo k odemčení zabezpečených dat nutných k dokončení akce.

Příklad.
Mám dva stroje.
1. agent
2. master

Agent se neustále chodí ptát mastera na úkoly a pokud se objeví úkol, master mu v odpovědi zašle parametry úkolu. Předpokládá se, že agent je zodpovědný za provedení zabezpečené operace například s citlivými daty (třeba výplatu peněz).

Je mi blbý do odpovědi dávat přímo to heslo, i když bude putovat zabezpečeným kanálem. Lepší by bylo, kdyby heslo bylo předáno po kanálu nějak fikaně. Třeba jako OTP autentifikace. Ale je potřeba nakonec získat vlastní text hesla, tedy nestačí jen potvrzení Ano/Ne, zda druhá strana se správně identifikovala.

Opět jsem nejprve použil googla, abys se pokusil najít řešení vlastními silami. Dovedlo mě to k D/H key exchange a RSA.

• Agent pošle na mastera požadavek a s ním vyšle náhodný řetězec jako challenge
• Master kromě toho, že sestaví odpověď, tak provede výpočet X = F(a,b,s), kde X heslo, který chci přenést, F je hledaná funkce, a je challenge, s je tajná hodnota, kterou mohou znát obě strany, ale by se X nemělo nechat spočítat. Server vypočítá b a odešle ho v odpovědi.
• agent přijme b, hodnotu a zná,  spočítá F(a,b,s) a získá X. to použije na odemčení zabezpečených dat a pak X z paměti vymaže.

Pokud by vládu nad agentem převzal útočník, nebude schopen spočítat b, protože nezná x. I kdyby se mu podařilo agenta kompromitovat (třeba pomocí jiné chyby) a vyřadil by kontrolu autorizace požadavku, tak bez správného hesla a tedy hodnoty x nezmůže nic.

Otázka zní, jaká je funkce F.

Napadla mě primitivní odpověď jako příklad   F(a,b,s) = a XOR b XOR s.  Ze znalosti X,a,s jsem schopen spočítat b. Ze znalosti a,b,s jsem schopen spočítat X. Ovšem bez jedne z obou proměnných X neodvodím.

A otázka. Kde bych hledal podobnou funkci, ale s mnohem lepší implementací. Cílem je, aby v případě, že útočník získá jedno nebo i oba řetězce (například z komunikace), aby i tak nebyl schopen spočítat X a zejména pak simulovat mastera a tím ho donotit provést neautorizovanou operaci.

PS: není to jediné zabezpečení

[Reklama]

[podlesh]

Tak zajímavě se rozjela diskuze o obtížném dešifrování, doufám, že stejně dobře mi poradíte i v tomto případě.

To nejsou vysoké nároky...

Potřebuju bezpečně přenést heslo/klíče z jednoho počítače na druhý,
....
I tak to ale znamená, že přijímaci strana musí vědět, že nebyla oklamána. Ideální bylo, kdyby součástí požadavku bylo i heslo k odemčení zabezpečených dat nutných k dokončení akce.

Takhle od pohledu mi to přijde jako ideální příležitost použít nějakou asymetrickou šifru s párem klíčů (PKI). Myslím samozřejmě přímo, ne přes její specializované aplikace jako je digitální podpis.

Pokud jsem dobře pochopil, tak velká výpočetní náročnost není na závadu, čímž padá jeden z hlavních problémů pro praktické použití. Samozřejmě existují i jiné, ale to už asi bude nutno si nastudovat literaturu nebo alespoň dokumentaci.

Napadla mě primitivní odpověď jako příklad   F(a,b,s) = a XOR b XOR s.  Ze znalosti X,a,s jsem schopen spočítat b. Ze znalosti a,b,s jsem schopen spočítat X. Ovšem bez jedne z obou proměnných X neodvodím.

A otázka. Kde bych hledal podobnou funkci, ale s mnohem lepší implementací. Cílem je, aby v případě, že útočník získá jedno nebo i oba řetězce (například z komunikace), aby i tak nebyl schopen spočítat X a zejména pak simulovat mastera a tím ho donotit provést neautorizovanou operaci.

Lineární funkci opravdu ne, to je zjevné... IMHO by to měla stačit každá PRP (pseudo-random permutation), takže stačí vybrat libovolnou blokovou šifru (AES / xFish / cokoliv).

Disclaimer: navržené algoritmy jsem nijak důkladně nezkoumal a navíc nelze říct že rozumím kryptografii; znám nějaké základní pojmy
a dvě zlatá pravidla pro praktické použití kryptografie:

• Nevymýšlet vlastní systémy a použít již vymyšlené a seriózně ověřené.
• Pokud možno ani neimplementovat a použít již hotové knihovny.

[JardaP .]

Takhle od pohledu mi to přijde jako ideální příležitost použít nějakou asymetrickou šifru s párem klíčů (PKI). Myslím samozřejmě přímo, ne přes její specializované aplikace jako je digitální podpis.

Jo, jenze kdyz utocnik uz ovladl agenta, tak ma v ruce klice. Muze tedy desifrovat a fixlovat, co se mu zachce.

To je stejne, jako s tou tajnou hodnotou s. Jak zajistit, aby ji znaly obe strany a pritom byla tajna? Kdyz ma utocnik agenta, tak si ji tam nekde najde.

Rekl bych, ze je to oboji dost na hovno a symetricke sifrovani pomuze tak leda tomu, ze by nekdo poslouchal na drate a prolomil sifrovani komunikace. Tedy sifrovani dalsi kryptografickou vrstvou jineho typu pak utocnika dost otravi.

[pepak]

Master kromě toho, že sestaví odpověď, tak provede výpočet X = F(a,b,s), kde X heslo, který chci přenést, F je hledaná funkce, a je challenge, s je tajná hodnota, kterou mohou znát obě strany, ale by se X nemělo nechat spočítat. Server vypočítá b a odešle ho v odpovědi.

Tady jsi mě svým zápisem hrozně zmátnul, protože formální popis máš úplně jiný než slovní popis, a zatímco slovní popis dává smysl, formální ne. Asi jsi spíš měl na mysli, že b = F(a, s, X), ne?

Otázka zní, jaká je funkce F.

Možností je spousta, například F(a, s, X) := RSASign(RSAencrypt(a||nonce||X, VKagent), SKmaster), kde a je tvoje challenge, nonce je jedinečná hodnota, která se nikdy nebude opakovat, X je heslo, VKagent je veřejný klíč agenta, SKmaster je soukromý klíč mastera. Agent ověří podpis (k tomu potřebuje veřejný klíč mastera), pak dešifruje zprávu (k tomu potřebuje svůj soukromý klíč), zkontroluje a odstraní a, zkontroluje a odstraní nonce (dotaz do databáze, jestli už to nonce bylo použito) a zůstane mu X, které použije.

Ale celé to je hodně vratké:
- To X musí být jednorázové heslo, jinak si to (hacknutý) agent může uložit a pak už žádnou další komunikaci nepotřebuje.
- Když agent posílá challenge serveru, musí to být nějak autentizované - nelze připustit, aby se někdo vydával za agenta a poslal si svoji vlastní challenge.

Obecně bych ti vřele doporučil, pokud se tím chceš zabývat, aby sis otevřel dokumentaci k OpenSSL, našel tu nejvíce high-level funkci, která odpovídá tvým požadavkům, a tu použil. Na čím nižší úroveň půjdeš, tím spíš nasekáš v implementaci chyby, které umožní ji prolomit. Například si z neznalosti zvolíš takový soukromý klíč RSA nebo takovou grupu pro DH, které půjdou snadno prolomit.

[pepak]

Pozn.: || značí operaci spojení řetězců.

[Reklama]

[podlesh]

Takhle od pohledu mi to přijde jako ideální příležitost použít nějakou asymetrickou šifru s párem klíčů (PKI). Myslím samozřejmě přímo, ne přes její specializované aplikace jako je digitální podpis.

Jo, jenze kdyz utocnik uz ovladl agenta, tak ma v ruce klice. Muze tedy desifrovat a fixlovat, co se mu zachce.

To je stejne, jako s tou tajnou hodnotou s. Jak zajistit, aby ji znaly obe strany a pritom byla tajna? Kdyz ma utocnik agenta, tak si ji tam nekde najde.

Ne tak docela: útočník který ovládl agenta má v ruce jeden klíč a může tedy fixlovat jednu stranu - toho agenta. Tím zas tak moc nezíská, nedokáže ovládnout jiné agenty kteří mají jiné klíče (to jsem zapomněl zmínit, to je důležité).

Samozřejmě průšvih je pokud ovládne mastra. Typicky je master zabezpečen ještě dalšími vrstvami a výrazně lépe (hlavně v modelech server - client). Pokud by bylo nutné počítat sovládnutím kohokoliv, tak se dostáváme do oblasti distribuovaných algoritmů a to už je jiná liga.

[Ondřej Novák]

Dobře, tak ještě se to pokusím vysvětlit jinak.

Problem je, že provedení výplaty v libovolném systémů Xcoinů  potřebuju privátní klíč, který si musím držet v počítači, který výplaty provádí (právě od toho má být ten agent, aby to nesedělo přímo na masterovi). A mé úvahy se stále točí kolem rizik. Je zřejmé, že privátní klíče musí být chráněny heslem ... ať už pomocí dlouhé passphrase, nebo i nějakou formou šifrování s pomalým dešifrováním. Problém je, že to heslo nemůže být jednorázové.

Mě jde o to, aby útočník pokud ovládne jednu nebo druhou stranu, neměl možnost provést výplatu. Chtěl bych docílit tohoto
 * Útočník pokud leakne data z agenta (předpokládám, že to bude jeho první cíl) nebude mít nikdy kompletní passphrase k odemčení privátních klíčů
 * Útočník, pokud leakne data z  mastera , tak zase nebude mít ty privátní klíče.
 * Ǔtočník se může pokusit ovládnout agenta na dálku tím, že se bude vydávat za jeho mastera (ale stále musí znát passphrase od původního mastera).

Agent by měl použít passphrase k odemčení klíče a podepsání transakce a pak to zaslané heslo přepsat náhodnými znaky (a doufat, že se to mezitím někam neodswapovalo. A mne šlo o to, jak nejlépe zasílat tu passphrasi. Když si tam zřídím HTTPS s certifikátem, který bude agent ověřovat aby tím vyloučil man-middle-attack, je přijatelné to heslo do odpovědi mastera dávat v plaintextu? Mě to nepřišlo jako bezpečné.

Samozřejmě že ty strany může ovládnout na živo, ale tenhle typ ovládnutí předpokládá, že se vláme to serveru a získá v něm nějaká významná práva (třeba roota), nebo že bude sedět přímo u stroje. Tohle zabezpečení bych řešil na jiných úrovních.

[Jenda]

Ježiš, tohle dopadne. Asi bylo málo vyhackovaných směnáren. (osobně bych si při současném stavu počítačové bezpečnosti nic takového provozovat netroufl)

Pokud se vláme na mastera, může začít agentům vydávat vlastní příkazy k úhradě. Pokud se vláme na agenta (který, jestli jsem to dobře pochopil, podepisuje transakce), počká, až přijde heslo z mastera, a klíč si prostě zkopíruje. Jediné, co může pomoct, je mít více agentů a na každém jenom část částky (takže při napadení neukradne všechno) - na druhou stranu, pokud napadne jednoho agenta, nejspíš budou tu stejnou chybu sdílet všichni; proti napadení mastera by mohlo pomoct mít nějaký limit pro maximální výplatu za 24 hodin (třeba), po jehož dosažení to bude čekat na akci operátora - opět pak útočník ukradne maximálně výši limitu.

V posílání klíče přes SSL/SSH/… nevidím problém.

[Ondřej Novák]

Ježiš, tohle dopadne. Asi bylo málo vyhackovaných směnáren. (osobně bych si při současném stavu počítačové bezpečnosti nic takového provozovat netroufl)

Jediné, co může pomoct, je mít více agentů a na každém jenom část částky (takže při napadení neukradne všechno)

Což o to, s tím počítám. Systém právě počítá s nasazením vícero agentů na různé lokality (dokonce se uvažuje na různé operační systémy a platformy) a do cloudů. Každý by měl držet jen část coinů a navíc určité procento přelejvat do cold walletu, ke kterým bude mít přístup pouze člověk. Dokonce lze snad dokázat, že pokud budu držet živé rezervy řádově v pár desítek procent vůči cold walletu, nebude vůbec potřeba coiny z cold walletu přelejvat zpět (viz systém částečných rezerv v bankách).

Napadení masteru je samozřejmě single point of failure, na druhou stranu, je dost problém to navrhnout jinak, když je potřeba vést centrální evidenci. Samozřejmě, že agenti nebudou chodit přímo na mastera, ale na některé z jeho slavů, který některé požadavky bude přeposílat na svého mastera, takže útočník bude muset prolomit víc míst. Samotný master nebude sedět přímo na internetu.

Výplatu lze také omezit pouze na adresy registrované v centrální evidenci. Lze to zařídit tak, že jeden slave nařídí agentovi vyplatit coiny uživateli 12345 a agent se půjde zeptat jiného slave, kdo je to uživatel 12345 a jestli má na virtuálním účtu skutečně tolik peněz.

To už je trochu offtopic.

počká, až přijde heslo z mastera, a klíč si prostě zkopíruje.

Kolik je úspěšných útoků nasazení trojského koně na server, který je schopen poslouchat a čekat na klíč (zabezpečenou komunikaci). Dejme tomu, že agent je standardní linuxový počítač s firewallem pouze ven a uvnitř běží aplikace jako binárka pod běžným userem, který sepravidelně připojuje na mastera. Pokud nepřekonám firewall, musím se dovnitř vlámat nějak přes ten request, třeba pomocí buffer overun tam vecpat vlastní kód. Za předpokladu, že donutím agenta, aby šel na můj nepřátelský server. Spíš jsem uvažoval o tom, že někdo okopíruje databázi, případně udělá dump celého stroje, nějaký pracovník telehausu nebo správce cloudu.

[podlesh]

Mě jde o to, aby útočník pokud ovládne jednu nebo druhou stranu, neměl možnost provést výplatu. Chtěl bych docílit tohoto
 * Útočník pokud leakne data z agenta (předpokládám, že to bude jeho první cíl) nebude mít nikdy kompletní passphrase k odemčení privátních klíčů
 * Útočník, pokud leakne data z  mastera , tak zase nebude mít ty privátní klíče.
 * Ǔtočník se může pokusit ovládnout agenta na dálku tím, že se bude vydávat za jeho mastera (ale stále musí znát passphrase od původního mastera).

Pokud bych to myslel opravdu vážně, tak by začas studovat na  https://en.wikipedia.org/wiki/Secret_sharing , přečetl si nejakou literaturu a našel navržené protokoly. Určitě něco bude, ale není to tak běžné aby to takhle z ruávu vysypal někdo na rootu.

Samozřejmě můžu začít navrhovat něco vlastního. Třeba zašifrovat všechno dvakrát pomocí RSA - nejdřív jeden klíč a pak druhý, takže každá ze stran bude muset poslat té druhé požadavek na částečné dešifrování aniž by se ta druhá strana něco zajímavého dozvěděla. Ale bacha na to, určitě tam bude spousta zranitelností - stačí se podívat na různé autentizační protokoly a jak se proti nim našly útoky...

[Jenda]

Výplatu lze také omezit pouze na adresy registrované v centrální evidenci. Lze to zařídit tak, že jeden slave nařídí agentovi vyplatit coiny uživateli 12345 a agent se půjde zeptat jiného slave, kdo je to uživatel 12345 a jestli má na virtuálním účtu skutečně tolik peněz.

No ale ta centrální evidence má zase jeden nějaký frontend, na který se leze typicky přes potenciálně děravý web. A tam si prostě zupdatuju, kolik peněz „ve skutečnosti“ mám a tedy kolik mi můžeš vyplatit.

[Tomáš Marný]

Mně neustále uniká, oč se tu tazatel vlastně pokouší. Vždyť otázka bezpečné výměny klíčů nezabezpečeným kanálem ja dávno vyřešená - bez toho by vůbec nebyly myslitelné elektronické bankovní operace či mobilní sítě GSM 2G a výš (ať už metodou výměny výzev při použití symetrických metod, nebo asymetrickými metodami v kombinaci s certifikací). Stejně tak to "pomalé dešifrování" - proboha, na co? Stačí zvolit vhodnou délku klíče; v případě použití hesla se toto zpomalení řeší metodou natahování klíče - např. osolením a vícenásobnou aplikací kryptografické hashe, což nutí útočníka při pokusu o hrubou sílu (samozřejmě myšleno v kombinaci s tabulkami) každý pokus prohnat tou samou (výpočetně nezanedbatelnou) natahovací funkcí.

Hlavně - proboha!!! - do žádného v praxi nasazovaného řešení, zvláště, má-li operovat s nějakými daty podléhajícími právní ochraně, nezkoušejte procpat nějaké své tvůrčí pokusy z oblasti kryptografie! Držte se zásady, že řešení, jež nebylo dostatečně otestováno - jednak profíky v labech, jednak v praxi dostatečně motivujícími výzvami typu "kdo to první zlomí, získá $500k" - jest považovati a priori za nebezpečné!

[Ondřej Novák]

No ale ta centrální evidence má zase jeden nějaký frontend, na který se leze typicky přes potenciálně děravý web. A tam si prostě zupdatuju, kolik peněz „ve skutečnosti“ mám a tedy kolik mi můžeš vyplatit.

No to bys právě neměl. Web já osobně považuju za stejně bezpečný jako kdyby to byla aplikace běžící uživateli na desktopu. Mimochodem, celý systém se bude ovládat výhradně přes api, webkovky budou pouze api používat, api bude i veřejné.

Hlavně - proboha!!! - do žádného v praxi nasazovaného řešení, zvláště, má-li operovat s nějakými daty podléhajícími právní ochraně, nezkoušejte procpat nějaké své tvůrčí pokusy z oblasti kryptografie! Držte se zásady, že řešení, jež nebylo dostatečně otestováno - jednak profíky v labech, jednak v praxi dostatečně motivujícími výzvami typu "kdo to první zlomí, získá $500k" - jest považovati a priori za nebezpečné!

Proč myslíš, že sem chodím se ptát. Nehledám vlastní řešení, hledám existující řešení. Ale nemůžeš to nikdy postavit z toho co už je, protože jednak je to vývoj nové věci, dále je to otázka ceny (prostě nemůžeš zabezpečit platební systém, kde se bude točit maximálně 1mil korun systémem za 10mil kourun) a pak je také dobré na místě opatrnost, protože standardní věci mají také standardní prolamovací protějšky. Neznáš bohužel míru s jakou uvažuju v projektu použít standardní ověření postupy (v labech) a kde bude mé vlastní autorské dílo.