Skip to content
GitHub no longer supports this web browser. Learn more about the browsers we support.
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] SHA-3 mellett HMAC-SHA512 támogatása #100

Open
bachratyg opened this issue Jan 6, 2020 · 8 comments
Open

[FEATURE] SHA-3 mellett HMAC-SHA512 támogatása #100

bachratyg opened this issue Jan 6, 2020 · 8 comments
Assignees
Labels

Comments

@bachratyg
Copy link

@bachratyg bachratyg commented Jan 6, 2020

Az igény összefoglalása / Summary of the request

Jelenlegi SHA-3 aláírás képző algoritmus lecserélése hasonló biztonsági szintet nyújtó, de jóval szélesebb körben elterjedt és ezért könnyebben fejleszthető/fenntartható megoldásra.

Az általam javasolt megoldás / The solution I propose

A jelenlegi requestSignature képzés módosítása az alábbiak szerint:

  • SHA-3 helyett az aláírás képzése HMAC-SHA512 algoritmussal történjen
  • a HMAC algoritmus bemenő key paramétere a technikai felhasználó aláíró kulcsa
  • a HMAC algoritmus bemenő message paramétere a konkatenáció maradéka az aláíró kulcs kihagyásával

Elfogadható alternatívák / Acceptable alternatives

Egyéb tartalom / Additional content

Ahogy arra korábban rámutattak (pl. #99) a SHA-3 implementálásához adott esetben külső függőséget kell igénybe venni. Ez azt is jelenti, hogy ha biztonsági probléma van az érintett függőség vonatkozásában, akkor azt a fejlesztőnek kell figyelemmel kísérnie illetve menedzselnie saját verziókibocsátáson keresztül.

Ha jól értem a #6 (comment) alapján a requestSignature feladata, hogy egyrészt hitelesítse a feladót (az aláíró kulcson keresztül) és biztosítsa az üzenet integritását. (Kihagytam valamit?) A szignatúra most egy egyedi konstrukcióval történik, ahogy az az 1.5.1-ben le van írva, erre a use case-re viszont már létezik szabványos FIPS eljárás: HMAC. Kriptográfiában ökölszabály, hogy egyedi megoldások helyett a jól beváltat kell preferálni.

Ami a biztonságot illeti collision resistance kapcsán nincs ismert hatékony támadás, még quantum computing figyelembe vételével sem, a SHA-2 length extension gyengeségét pedig a HMAC kiküszöböli. Ebből a szempontból nem tűnik rosszabb választásnak a HMAC-SHA512, mint a SHA-3 512.

Ezeket az előnyöket látom a mostani konstrukcióval szemben:

  • a javasolt algoritmus konkrétan az üzenetek autentikációjára/integritásának védelmére van kitalálva, jól dokumentált, szabványos (FIPS/ISO) eljárás
  • 20+ év iparági kutatás és tapasztalat (szemben a SHA-3 kb. 10 évével és általánosabb céljával)
  • jóval szélesebb körben használt (a teljesség igénye nélkül IPSec, TLS, JWT, SSH, Kerberos). Ha bármilyen biztonsági probléma van, azzal magasabb prioritáson foglalkozik az iparág.
  • széles körű natív támogatás, nincs feltétlenül szükség 3rd party libre.
  • fejlesztőtől kevesebb ráfordítást igényel a kifejlesztés és a karbantartás is.

A fentiekből nekem úgy tűnik, hogy a HMAC-SHA512 biztonságilag egyenértékű, üzletileg pedig jobb választás. Van olyan további szempont, amit nem vettem figyelembe és a SHA-3 oldalára billenti a mérleg nyelvét?

@kabelnet2

This comment has been minimized.

Copy link

@kabelnet2 kabelnet2 commented Jan 6, 2020

De remélem ezt nem a 2.0-hoz javaslod, ami néhány hónap múlva indul élesben és amit már hónapok óta fejleszt aki nem az utolsó pillanatra hagyja.
Az elterjedségre és egyebekre meg csak annyit: nem csak PC van a világon.

@bachratyg

This comment has been minimized.

Copy link
Author

@bachratyg bachratyg commented Jan 6, 2020

A módosítás kvázi-kompatibilis módon elvégezhető, opcionálisan meg kell taggelni a requestSignature-t a kapcsolódó algoritmussal (mint az egyébként bevett gyakorlat mind digitális aláírásnál, időbélyegzésnél, sőt még jelszó hash tárolásnál is).

Például

<requestSignature alg="HMAC-SHA256">...

vagy

<requestSignature>...</requestSignature>
<requestSignatureAlgorithm>HMAC-SHA256</requestSignatureAlgorithm>

A címke nem kötelező, ha az xml-ben nincs megadva, akkor a jelenlegi működés változatlan. A kérés üzenetek jelen formájukban és tartalmukkal továbbra is érvényesek maradnak, a válaszüzenetekben nincs requestSignature. Az adózó oldalán nem történik változás, nem kell felkészülni új váratlan adattag megjelenésére. Kizárólag a NAV oldali feldolgozást érinti a beavatkozás.

@kabelnet2
Arra kérnélek, hogy ne legyenek előítéleteid mások körülményeivel! Nem a szándék az egyetlen tényező abban, hogy ki mit mikor milyen ütemezéssel fejleszt.

Az elterjedségre és egyebekre meg csak annyit: nem csak PC van a világon.

Ezt légy szíves fejtsd ki bővebben!

@bachratyg bachratyg changed the title [FEATURE] SHA-3 helyett HMAC-SHA512 [FEATURE] SHA-3 mellett HMAC-SHA512 támogatása Jan 6, 2020
@NTCA-developer NTCA-developer self-assigned this Jan 10, 2020
@NTCA-developer

This comment has been minimized.

Copy link
Contributor

@NTCA-developer NTCA-developer commented Jan 10, 2020

Szia @bachratyg

Először is köszönjük a javaslatot, látszik hogy szántál rá időt. Én szeretném hasonlóképp honorálni ezt és ígérem, hogy nem intézzük el a témát kettő félmondatból. Majd lesznek kérdéseim és észrevételeim is arra amit írtál. Pont ezért viszont szeretném a türelmedet kérni, mivel ma megvolt a nyitott githubos igények egyeztetése és az előtted lévőknek szeretnék előbb válaszolni.

Még jelentkezem.

@NTCA-developer

This comment has been minimized.

Copy link
Contributor

@NTCA-developer NTCA-developer commented Jan 21, 2020

Szia!

Köszönöm a türelmed. Először - ahogy ígértem - reagálnék arra amit írtál és utána jön az én gondolatmenetem.

Kriptográfiában ökölszabály, hogy egyedi megoldások helyett a jól beváltat kell preferálni.

Ebben teljes mértékben egyetértek veled, csak a végkövetkeztetésben térünk el. A módozat ahogy mi a MAC-et számítjuk nem attól lesz custom, hogy mi az hash függvény inputja. A hash függvény pont arra van hogy bármit etethetsz vele. A fejlesztőnek sem az a 2 darab append utasítás a baj, ami az input stringet összeállítja a hashelés előtt. Erről a témáról írtam egy évvel ezelőtt a 2019/3 dev diary bejegyzésben.

"Alapvetően 2 választási lehetőség áll előttünk, vagy definiálunk egy saját, HMAC algoritmust valamilyen salt használatával, vagy szabvány algoritmust választunk, ami a legtöbb mai programnyelvben függőségként behúzható. Vannak érvek egyik és másik megoldás mellett is, mi support oldalról nézve is célszerűbbnek látjuk, ha szabvány megoldás felé mozdulunk el."

Ami a biztonságot illeti collision resistance kapcsán nincs ismert hatékony támadás, még quantum computing figyelembe vételével sem, a SHA-2 length extension gyengeségét pedig a HMAC kiküszöböli.

Itt csak egy kicsi pontosítást szeretnék tenni. A collision resistance a CRC32-nél merült fel, a hash függvény kapcsán sosem volt ilyen problémánk, mivel a kollízióvédelem az SHA család esetén a másodlagos előkép védelemben implicit benne van. (A length-extension kapcsán pedig igazat szólsz, a HMAC orvosolja ezt, itt nincs vita köztünk)

A módosítás kvázi-kompatibilis módon elvégezhető, opcionálisan meg kell taggelni a requestSignature-t a kapcsolódó algoritmussal

Ebben is igazad van, pl a SAML szabványok - akiknek az élete nagyjából csak attribútumokból áll - is így csinálják, a HMAC-ot meg lehetne kompatibilis módon is csinálni a jelenlegi működés mellé. Kicsit ugyan csúnya lenne, hogy attribútum nélkül úgy ellenőrizzük a requestSignature értékét ahogy a specifikáció előírja, explicit megadás esetén pedig máshogy, ha rálépnénk erre az útra akkor jó volna kötelezően jelöltetni a használt hash funkciót. De ezt még el lehetne engedni.

És akkor jöjjön a fő gondom.

A fejlesztők egy meghatározó csoportja nem kriptográfus, ők legfeljebb alkalmazói a kriptográfiai funkcióknak. Ahhoz viszont hogy a HMAC implementáció - hiába írja le a FIPS-198 a szabvány módját - megfelelő legyen nagyon nem mindegy, hogy

  • hash (key || message) vagy
  • hash (message || key) vagy
  • hash (key || message || key) vagy
  • hash (key || hash (key || message))

És ha körülnézel az interneten sajnos mindegyikre találsz példát, hiába szabadna csak az utolsót használni. Ráadásul az utóbbi időben nem szokás a HMAC-ot az első két passból kiszámolni, illik iterálni rajta egy tetszőlegesen nagy prímszámmal, de legalább 3-mal. Én implementáció szempontjából pont ezt nevezem customnak, egy nem jó implementáció supportjára becsülni sem merem mennyi időt égetnénk el. A HMAC-nál a fejlesztőnek ha a szerver nem fogadja el az értéket mindig bele kell nézni a metódusba, hogy pontosan mi történik. Ezzel szemben a Keccak-ot csak behúzod aztán vagy fordul vagy nem, de ha megy akkor szinte biztos hogy az eredmény jó. És ha a HMAC nem jó, akkor nagyjából ugyan ott van ahol most is: más megoldást kell keresned a natív támogatás hiányában vagy az helyett.

Csak hogy kicsit még cizelláljuk a dolgot, a HMAC nem tartozik a NIST approved digest metódusok közé, az SHA3 viszont igen. https://csrc.nist.gov/projects/hash-functions

Értem az igényt ami miatt a HMAC-ot javasolod és sajnos a Microsoft is olyan amilyen. (az MS és a szabványkövetés lassan diszjunkt fogalom lesz) Viszont korát/érettségét nézve (20 év vs 10 év), a piaci penetrációt figyelembe véve (csak 1 példát említek, én több SHA3 online toolt találok mint HMAC-ot, ráadásul a HMAC-ra az első találat is bouncycastle implementáció) szerintem az SHA3 modernebb, időtállóbb és kevésbé kockázatos választás.

Első körben ezek a gondolataim, várom az észrevételeid!

@bachratyg

This comment has been minimized.

Copy link
Author

@bachratyg bachratyg commented Jan 22, 2020

Előre is bocsánat, ez hosszú lesz.

A módozat ahogy mi a MAC-et számítjuk nem attól lesz custom, hogy mi az hash függvény inputja. A hash függvény pont arra van hogy bármit etethetsz vele.

Általános esetben ez nem igaz. Pont a length extension attack az ellenpélda, hogy nem mindegy, hogy hogyan van felhasználva a hash függvény. Attól, hogy SHA3-nál nem tuduk ilyenről még nem lehetünk biztosak benne, hogy nincs is, mivel még viszonylag új.

A fejlesztőnek sem az a 2 darab append utasítás a baj, ami az input stringet összeállítja a hashelés előtt. Erről a témáról írtam egy évvel ezelőtt a 2019/3 dev diary bejegyzésben.
"Alapvetően 2 választási lehetőség áll előttünk, vagy definiálunk egy saját, HMAC algoritmust valamilyen salt használatával, vagy szabvány algoritmust választunk, ami a legtöbb mai programnyelvben függőségként behúzható. Vannak érvek egyik és másik megoldás mellett is, mi support oldalról nézve is célszerűbbnek látjuk, ha szabvány megoldás felé mozdulunk el."

Szabványos megoldásról van szó.
https://tools.ietf.org/html/rfc2104
https://csrc.nist.gov/publications/detail/fips/198/1/final
Lentebb mellékelek példákat, hogy a "legtöbb mai programnyelvben" hogyan lehet függőségként behúzni.

A fejlesztők egy meghatározó csoportja nem kriptográfus, ők legfeljebb alkalmazói a kriptográfiai funkcióknak. Ahhoz viszont hogy a HMAC implementáció - hiába írja le a FIPS-198 a szabvány módját - megfelelő legyen nagyon nem mindegy, hogy

hash (key || message) vagy
hash (message || key) vagy
hash (key || message || key) vagy
hash (key || hash (key || message))

És ha körülnézel az interneten sajnos mindegyikre találsz példát, hiába szabadna csak az utolsót használni.
Én implementáció szempontjából pont ezt nevezem customnak, egy nem jó implementáció supportjára becsülni sem merem mennyi időt égetnénk el. A HMAC-nál a fejlesztőnek ha a szerver nem fogadja el az értéket mindig bele kell nézni a metódusba, hogy pontosan mi történik. Ezzel szemben a Keccak-ot csak behúzod aztán vagy fordul vagy nem, de ha megy akkor szinte biztos hogy az eredmény jó.

Erre semmi szükség. Valamire való crypto lib out-of-the-box tartalmazza a HMAC szabvány implementációt. Semmi egyedit nem kell mókolni. Néhány példa alább. Bemenő paraméterek: byte[] key és byte[] msg. A jegyzettömb a compilerem és nem vagyok profi minden platformon, de a példa alapján a vonatkozó API remélem megtalálható.
Java natív

Mac hmac = Mac.getInstance("HmacSHA512");
hmac.init(new SecretKeySpec(key, "HmacSHA512"));
return hmac.doFinal(msg);

OpenSSL parancssor

openssl dgst -sha512 -mac hmac "`cat key.bin`" -binary < msg.bin > hash.bin

OpenSSL C

unsigned int result_len = 32;
HMAC_CTX ctx;
unsigned char* result = (unsigned char*)malloc(sizeof(char) * result_len);
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
HMAC_CTX_init(&ctx);
HMAC_Init_ex(&ctx, key, 32, EVP_sha512(), NULL);
HMAC_Update(&ctx, data, strlen(data));
HMAC_Final(&ctx, result, &result_len);
HMAC_CTX_cleanup(&ctx);
return result;

PHP (string inputokkal/outputokkal dolgozik)

return hash_hmac('sha512', $msg, $key);

C# Bouncy Castle - lehetne kompaktabb is

var hmac = new HMac(new Sha512Digest());
hmac.Init(new KeyParameter(key));
var result = new byte[hmac.GetMacSize()];
hmac.BlockUpdate(msg, 0, msg.Length);
hmac.DoFinal(result, 0);
return result;

C# natív - nincs SHA3 támogatás

return new HMACSHA512(key).ComputeHash(msg);

Win32 natív - a "szokásos" tömörséggel; itt sincs natív SHA3 támogatás

BCRYPT_ALG_HANDLE hAlg;
BCryptOpenAlgorithmProvider(&hAlg, BCRYPT_SHA512_ALGORITHM, NULL, BCRYPT_ALG_HANDLE_HMAC_FLAG);

DWORD cbHashObject;
BCryptGetProperty(hAlg, BCRYPT_OBJECT_LENGTH, (PBYTE)&cbHashObject, sizeof(DWORD), &cbHashObject, 0);
PBYTE pbHashObject = (PBYTE)HeapAlloc(GetProcessHeap(), 0, cbHashObject);

DWORD cbHash;
BCryptGetProperty(hAlg, BCRYPT_HASH_LENGTH, (PBYTE)&cbHash, sizeof(DWORD), &cbHash, 0);
PBYTE pbHash = (PBYTE)HeapAlloc(GetProcessHeap(), 0, cbHash);

BCRYPT_HASH_HANDLE hHash;
BCryptCreateHash(hAlg, &hHash, pbHashObject, cbHashObject, key, sizeof(key), 0);

BCryptHashData(hHash, msg, sizeof(msg), 0);

BCryptFinishHash(hHash, pbHash, cbHash, 0);

BCryptCloseAlgorithmProvider(hAlg, 0);
BCryptDestroyHash(hHash);
HeapFree(GetProcessHeap(), 0, pbHashObject);

return pbHash;

VBA (!!!) - semmilyen beépített crypto nincs, de OS API hívható. Ugyanígy le lehet tükrözni a Win32 natív implementációt is, de ezzel inkább nem kínzok senkit.

Set hash = CreateObject("System.Security.Cryptography.HMACSHA512")
hash.Key = key
Dim result() As Byte
result = enc.ComputeHash_2(msg)

Apple CommonCrypto - szintén nincs SHA3 támogatás

var result = [CUnsignedChar](count: 512, repeatedValue: 0)
CCHmac(CCHMacAlgorithm(kCCHmacAlgSHA512), key, strlen(key), msg, strlen(msg), &result)
return result;

Apple CryptoKit - szintén nincs SHA3 támogatás

return HMAC<SHA512>.authenticationCode(for: msg, using: key)

Természetesen a lista nem teljes, elfogadok ellenpéldát, de olyannal még nem találkoztam, hogy egy libben van SHA3 és nincs HMAC-SHA512.

Ráadásul az utóbbi időben nem szokás a HMAC-ot az első két passból kiszámolni, illik iterálni rajta egy tetszőlegesen nagy prímszámmal, de legalább 3-mal.

Ezt honnan veszed? Ha adatbázisban hosszú távon tárolsz jelszavat, azt igen, és még sózni is szokták. Itt teljesen más a felállás: a szignatúra csak egy rövid időablakban leshető el, a requestId sózásként működik (rainbow table támadás kizárt), maga a jelszó pedig generált, magas entrópiájú, nem pedig 12345 (dictionary attack kizárt).
Tegyük fel a hipotetikus támadó megszerzi az egész üzenetet és ebből szeretné az aláírókulcsot megszerezni. Ha a kliens értelmesen generálta a requestId-t, akkor - hacsak nem talál egy algoritmikus gyengeséget, de akkor az egész világ óriási szarban lenne - a fenti okfejtés miatt brute-force az egyetlen esély. A siker egyetlen korlátja az aláírókulcs bithossza (pontosabban entrópiája). Közönséges, széles körben elérhető hardveren a SHA3-512 kb. 3x lassabb, mint a SHA-512 (ld. https://en.wikipedia.org/wiki/SHA-3#Comparison_of_SHA_functions). Figyelembe véve, hogy a HMAC-ban 2db hash művelet van a szorzó 1.5x-re módosul. Ez nem egy nagyságrendi eltérés, tehát nincs sokkal könnyebb dolga HMAC esetén. De: az előbbi példában a SHA-512 hardvertámogatással megy, a SHA3 meg nem. Ha célhardvert is figyelembe veszünk (ld. https://keccak.team/2017/is_sha3_slow.html) akkor a SHA3 hirtelen nagyságrenddel gyorsabban számolható és máris a HMAC az ellenállóbb.

Csak hogy kicsit még cizelláljuk a dolgot, a HMAC nem tartozik a NIST approved digest metódusok közé, az SHA3 viszont igen. https://csrc.nist.gov/projects/hash-functions

Rossz helyen keresed. A HMAC nem digest metódus, hanem kriptográfiai konstrukció. Itt az approval: https://www.nist.gov/publications/recommendation-applications-using-approved-hash-algorithms

Értem az igényt ami miatt a HMAC-ot javasolod és sajnos a Microsoft is olyan amilyen. (az MS és a szabványkövetés lassan diszjunkt fogalom lesz)

MS és szabványkövetés témában tíz-tizenöt éve még talán igazat adtam volna, ma már kevésbé, de ebbe a vallásháborúba teljesen értelmetlen belemenni, mert ortogonális tényező. A Linux olyan amilyen, olyan desktop piaci részesedéssel, amilyennel, ennek ellenére lett AbevJava. Az OpenSSL olyan amilyen (ld. https://en.wikipedia.org/wiki/LibreSSL#History), ennek ellenére sokan használják. A BouncyCastle olyan amilyen (ld. https://www.bouncycastle.org/csharp/index.html, gyakorlatilag abandonware volt 2011-2015), ennek ellenére elterjedt. Az Intel olyan amilyen (ld. https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)), piacvezető. Az Oracle-nek több ügyvédje van, mint kompetens fejlesztője, jó magas licencárakkal, mégis piacvezető. Az ügyfelet nem érdekli, hogy mennyire szép, elegáns, modern, mennyire dagad a programozó melle a büszkeségtől, stb. Őt az érdekli, hogy működjön, biztonságosan, olcsón.

A jól bejáratott - jobb esetben csak pár tíz emberévnyi befektetésű - rendszereket nyilván nem fogjuk más platformra migrálni, főleg nem pár hónap alatt. Ennek megfelelően az opcióink most:
Külső lib

  • felhajtok egy megbízható 3rd party libet, amit hajlandó az ügyfél saját infrastruktúrájára beengedni
  • integrálom
  • szétbarmolom az évtizede bejáratott deploymentet, hogy ez is települjön
  • folyamatosan nyomon követem, hogy van-e sebezhetőség
  • szükség esetén release-t adok ki

Saját kód

  • legjobb meggyőződésem ellenére bevállalom, hogy kriptográfiai primitívet fogok implementálni
  • felhajtok egy megbízható forráskódot és beemelem a rendszerbe
  • szükség esetén a célplatformra/nyelvre alakítom. Minden egyes alkalmazáshoz külön.
  • csöndben imádkozom, hogy bárki valaha ránézett-e és ne legyen benne pl. side channel attack
  • folyamatosan nyomon követem a forrást, hogy van-e sebezhetőség
  • és amikor ez bekövetkezik release-t adok ki

Ráncolom a homlokom, mert több időt kell a rendszer supportálásával töltenem érdemi feature fejlesztés helyett. A kedves megbízó - akár KKV akár megacég - szintén ráncolja a homlokát, mert többet kell fizetnie egy olyan megkötés miatt, ami zéró, ismétlem zéró hozzáadott üzleti értéket jelent neki is és a NAV-nak is. Már így is háborog, hogy évente pénzt kell áldozni rá. Maga az adatszolgáltatás még csak-csak elfogadtatható, hiszen jogos gazdasági érdek fűződik hozzá, itt viszont egy szigorúan technikai követelményről van szó.

És az opció amit szeretnék: platform natív implementáció

  • nem kell keresgélni semmit, alapból elérhető
  • pár sorból megvan (ld. fent), minimális hibalehetőség
  • ha esetleg nem beépített, hanem OS, akkor is szinte biztosan lehet hívni bármilyen nyelvből (ld. VBA interop)
  • a deploymentet nem kell széttúrni
  • automatikusan frissül, semmit dolgom nincs vele

én több SHA3 online toolt találok mint HMAC-ot, ráadásul a HMAC-ra az első találat is bouncycastle implementáció

Nem tudom, mire kerestél rá, nálam sehol sincs a BC (https://www.google.hu/search?q=online+hmac+calculator&ie=&oe=). Első 5 találat:
https://www.freeformatter.com/hmac-generator.html
https://codebeautify.org/hmac-generator
https://www.liavaag.org/English/SHA-Generator/HMAC/
https://cryptii.com/pipes/hmac
http://beautifytools.com/hmac-generator.php
Mind ott van a HMAC-SHA512

De ettől függetlenül ugye nem azt javaslod, hogy üzleti-/adótitkot egy online toolra bízzak?

szerintem az SHA3 modernebb, időtállóbb és kevésbé kockázatos választás.

Modernebb: tény, de ez miért előny? Ld. Dual_EC_DRBG: modern, innovatív, élt 8 évet, kuka. Itanium2: a kutyának sem kellett, inkább toldozzuk-foltozzuk tovább az x86-t.

Időtállóbb: ez majd idővel derül ki. Viszont implementálni a jogi kötelezettség miatt most kell. A két nagy gyártóval (Microsoft+Apple) kapcsolatban semmilyen ráutaló magatartást nem találtam (szólj, ha te tudsz ilyenről), hogy belátható időn belül implementálni akarják. A NIST sem erőlteti a váltást.

Apropó, ha az időtállóság cél, akkor mindenképpen javaslom a sémába már most felvenni az alg. azonosítót (ahogy egyébként PKCS-nél bevett gyakorlat, ld. a korábbi kommentben), ugyanis ennek a segítségével verzióváltás nélkül, pusztán policy alapon lehet kivezetni a nem biztonságos és bevezetni az új algoritmusokat, egyszerre akár többet is. Ezzel a Kedves Adózó a saját ütemezésében és megfontolásai szerint tud egy régebbi algról egy újabbra átállni és nem kell mindenkinek egyszerre mozdulnia.

Remélem sikerült tételesen megcáfolnom az aggályaidat, jelezd ha elsiklottam valami fölött.

@NTCA-developer

This comment has been minimized.

Copy link
Contributor

@NTCA-developer NTCA-developer commented Jan 27, 2020

Szia!

Azt hiszem hogy elkezdtünk másról beszélni. Szerintem nem tételesen kellene cáfolni az érveinket hanem közelíteni egymás megértése felé. Az egy mellékes dolog, hogy - direkt vagy nem direkt - hozol be olyan érveket a vitába amik részrehajlók, bár ne szóljak semmit, mert én magam is beleestem ebbe a hibába korábban.

Nem javasoltam hogy online toolt használj. Nem azt mondtam, hogy a HMAC implementációja bonyolult - amire a forráskódos példákat írod - hanem azt hogy ha HMAC megoldás keresgélése közben sikerült behúzni mondjuk egy PBKDF1-2-t (ez az amit te említesz a DB-s jelszavaknál, tudom hogy más mint amiről mi beszélünk de én látom a beérkező support leveleket, hidd el lesz aki összetéveszti) vagy egy nem szabványos HMAC-ot akkor jön a support nightmare. Az SHA3-512 sem több 3 sornál mondjuk java 11 natívban sem BC-ben.

A baj nem az hogy amit javasolsz az nem élhető. A baj az, hogy amit javasolsz az egy downgrade és jelenleg nem érezzük a szükségét sem ennek, sem pedig párhuzamosan több másik authentikációs metódus támogatásának az interfészen. Az érveink ugyan azok, mint amiket fentebb elmondtam. Abban viszont biztos lehetsz, hogy pl a BouncyCastle-ben előbb lesz benne egy jövőbeni security exploitnak a javítása mint a hivatalos vendorok kódjában.

@bachratyg

This comment has been minimized.

Copy link
Author

@bachratyg bachratyg commented Jan 29, 2020

Bocs, megint hosszú.

Azt hiszem hogy elkezdtünk másról beszélni. Szerintem nem tételesen kellene cáfolni az érveinket hanem közelíteni egymás megértése felé.

Azt próbálom kideríteni, hogy miért van szükség egy olyan algoritmus használatára, ami habár valószínűleg elég biztonságos (ezt a részt ünnepélyesen elengedem annak ellenére, hogy a NIST ajánlás erre a use case-re a KMAC), nekem jelentősen növeli a költségeim. Ugyanakkor az általam javasolt alternatívával kapcsolatban ez a költség minimális, és egyébként az amerikai hadsereg legmagasabb, top secret minősítésű anyagainak kezelésére jóvá van hagyva, ami alapján úgy gondolom, hogy a magyar adóügyek védelmére is bőven alkalmas. Jelezd, ha nem így gondolod! Ha biztonsági szempontból teljesen elfogadható a HMAC-SHA512, akkor a témának ezen a részén javaslom lépjünk tovább.

Nem azt mondtam, hogy a HMAC implementációja bonyolult - amire a forráskódos példákat írod - hanem azt hogy ha HMAC megoldás keresgélése közben sikerült behúzni mondjuk egy PBKDF1-2-t (ez az amit te említesz a DB-s jelszavaknál, tudom hogy más mint amiről mi beszélünk de én látom a beérkező support leveleket, hidd el lesz aki összetéveszti) vagy egy nem szabványos HMAC-ot akkor jön a support nightmare.

Nem látom, hogy miért ne állna fenn ugyanez a veszély a SHA3 esetén is, mert pl. megtalálja helyette a SHA384-et. Az interfész rendesen, részletesen dokumentálva van, van demó alkalmazás, amit ki lehet próbálni, esetleg némi példakóddal lehetne még kiegészíteni. Ha nem olvassa el, azon az algoritmus megválasztása sem segít, legrosszabb esetben az első beküldéskor koppan. Remélhetőleg legalább egyszer kipróbálja éles üzem előtt.
Ugyanakkor ha nem platform natív libet használ, akkor nem csak az algoritmust kell eltalálnia, hanem azt is, hogy melyik libet használja, nem utolsó sorban hogy a lib rendesen legyen implementálva és helyes értéket adjon vissza. Tehát a tévesztés veszélye legalábbis ugyanakkora vagy magasabb. Szólj, ha nem értesz egyet.

Az SHA3-512 sem több 3 sornál mondjuk java 11 natívban sem BC-ben.

Igen. Ezen semmi kivetni valót nem látok. Az észrevételem az volt, hogy a HMAC implementálásához - korábbi "fő gondoddal" ellentétben - nem kell sem hosszabb, sem bonyolultabb kódot írni, sem ismerni a belső működését, sem belenézni a belső implementációba. Ha úgy gondolod, hogy a HMAC-et indokolt lenne iterálni, és ez egyedi kód, akkor sajnos az a helyzet, hogy a SHA3-at is, ugyanabból a biztonsági megfontolásból. És az pont ugyanennyire egyedi kód. A support igény ugyanaz: rámutatsz, hogy na ezt kell behúzni és ezt meghívni. Nem nagyobb az implementációs hibalehetőség. Ha egyetértesz, ezen is tovább léphetünk.

Széljegyzet: a java natív implementációhoz nem írtam oda, de Java 8-ban sincs SHA3. Support vége 2023. Az egyik rendszerünket kompatibilitási gondok miatt belátható időn belül nem lehet 11-re frissíteni. HMAC/SHA2 van.

A baj az, hogy amit javasolsz az egy downgrade

Szerettem volna korábban is és még mindig szeretném, hogy részletesen megindokold, hogy miért downgrade. Az eddig felmerült érvekre válaszoltam, hogy miért nem jók. Még ha el is fogadnám, hogy state-of-the-art és szupersokkaljobb a másiknál, ennek nettó hozadéka belátható időn belül ekkor sincs, implementációs és üzemeltetési oldalon viszont ugrik a költség. Nem akkor, amikor talán az alternatíva már nem lesz olyan biztonságos, hanem most. Hosszú távon a nagy vendorok is fel fognak zárkózni - mert épeszű vendor nem fogja hagyni, hogy csak aggályos algokat támogasson - és triviális lesz átállni. Akkor, amikor már látszik, hogy hamarosan lépni kell, nem most.

Abban viszont biztos lehetsz, hogy pl. a BouncyCastle-ben előbb lesz benne egy jövőbeni security exploitnak a javítása mint a hivatalos vendorok kódjában.

Ezzel két probléma van. A konkrét esetben az, hogy pont a BC-ben nem bízom, mert volt egy négy éves szünete, amikor nem lehetett tudni, hogy most akkor abandonware, vagy tényleg foglalkozik még vele valaki, és nem látom biztosítottnak, hogy ilyen nem fordul elő még egyszer.
Az általános esettel pedig az a problémám, hogy nem az számít, hogy a felfedezéstől mennyi időn belül javítják, hanem hogy a felfedezéstől mikor sikerül telepíteni a javítást. A natív komponensek esetén automatikus frissítési mechanizmussal, előre konfigurált policy-k szerint, emberi beavatkozás nélkül ez rövid idő alatt végbemegy. Ha saját libet vagy kódot használok, akkor ahhoz kézi beavatkozás kell, folyamatos külső monitorozás, a jóváhagyások függvényében akár hetekben mérhető átfutása is lehet. Ha egyáltalán észreveszi valaki, hogy gond van. Simán előfordul a nap végén, hogy rövidebb ideig vagyok sebezhető még akkor is, ha a vendornak egyébként jóval tovább tart javítani az exploitot.

jelenleg nem érezzük a szükségét sem ennek, sem pedig párhuzamosan több másik authentikációs metódus támogatásának az interfészen. Az érveink ugyan azok, mint amiket fentebb elmondtam.

Ezt sajnálattal hallom, ugyanis a SHA3-nak a NIST szándéka szerint pont az a célja, hogy alternatívát nyújtson. Hogy akár abban akár a SHA2-ben kritikus védhetetlen hibára lelnek, akkor pánikszerű átállás helyett (ld. SHA1-SHA2) egyszerűen az opciók közül a sebezhetőt ki lehet kapcsolni. Ugyanebből az okból sajnálom egyébként azt is, hogy a natív implementációk ott tartanak ahol. Azon a fronton is sokan gyakorolnak nyomást, a szándéknak viszont nyomát nem látom, úgyhogy nem tudok arra alapozni, hogy belátható időn belül lesz.

Azt a szándékot is megértem, hogy support költségeteket minimalizálni szeretnétek, egyet érteni viszont nem tudok vele, mert ebből kifolyólag nálam és a többi sorstárs adózónál csapódik le a költség, ráadásul tartósan. (Vagy olcsó rendszert csinálok, magára hagyom, a cég meg orosz rulettezik.) Gyanítom, hogy egy KKV ügyfélnek csöppet korlátozottabbak az erőforrásai, mint a NAV-nak (értsd: örül ha elő tudja teremteni a forrást, talál fejlesztőt aki megcsinálja az évtizedes rendszerét, mindezt határidőre).

Jelenleg ki van véve a lehetőség a kezemből, ugyanakkor a következményeket köteles vagyok viselni. Ezt a szituációt úgy látom, hogy a NAV oldalán sokkal könnyebben (és összességében hatékonyabban) lehet megoldani, különben ez az issue nem is létezne.

@NTCA-developer

This comment has been minimized.

Copy link
Contributor

@NTCA-developer NTCA-developer commented Feb 3, 2020

Szia @bachratyg

Szerettem volna korábban is és még mindig szeretném, hogy részletesen megindokold, hogy miért downgrade.

Íme egy rész a 2007-es kiírásból (https://www.federalregister.gov/documents/2007/11/02/E7-21581/announcing-request-for-candidate-algorithm-nominations-for-a-new-cryptographic-hash-algorithm-sha-3):

Recently, cryptanalysts have found collisions on the MD4, MD5, and SHA-0 algorithms; moreover, a method for finding SHA-1 collisions with less than the expected amount of work has been published, although at this time SHA-1 collisions have not yet been demonstrated. Although there is no specific reason to believe that a practical attack on any of the SHA-2 family of hash functions is imminent, a successful collision attack on an algorithm in the SHA-2 family could have catastrophic effects for digital signatures.

NIST has decided that it is prudent to develop a new hash algorithm to augment and revise FIPS 180-2. The new hash algorithm will be referred to as “SHA-3”, and will be developed through a public competition, much like the development of the Advanced Encryption Standard (AES). NIST intends that SHA-3 will specify an unclassified, publicly disclosed algorithm(s), which is available worldwide without royalties or other intellectual property restrictions, and is capable of protecting sensitive information for decades. Following the close of the submission period, NIST intends to make all “complete and proper” (as defined in section 3) submissions publicly available for review and comment.

NIST does not currently plan to withdraw SHA-2 or remove it from the revised Secure Hash Standard; however, it is intended that SHA-3 can be directly substituted for SHA-2 in current applications, and will significantly improve the robustness of NIST's overall hash algorithm toolkit. Therefore, the submitted algorithms for SHA-3 must provide message digests of 224, 256, 384 and 512 bits to allow substitution for the SHA-2 family. The 160-bit hash value produced by SHA-1 is becoming too small to use for digital signatures, therefore, a 160-bit replacement hash algorithm is not contemplated.

Tehát a cél: 'to augment and revise'. Márpedig ha valami feljavít valamit akkor annak az elhagyása egy downgrade.

Ugyan ezt tudom mondani arra az érvedre is, hogy

ugyanis a SHA3-nak a NIST szándéka szerint pont az a célja, hogy alternatívát nyújtson.

Ez így ferdítés. Azt pedig közvetlenül demagógiának gondolom, hogy pusztán SHA3 miatt miatt bárkinek is növekednének a költségei. A TLS átállással is ugyan ez volt a helyzet. Én is dolgoztam korábban olyan mainframen ahol az ezer éves SSL klienshez senki emberfia hozzá sem mert nyúlni (hiába BEAST, Hearthbleed, bármi), különben is, "jólvanazúgy". Ez a mentalitás a költségnövelő, nem pedig az, amikor elkommitálod magad egy security megoldás mellett és ennek során egy 10 éves algoritmust választasz a 20 éves helyett.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.