Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign up[FEATURE] SHA-3 mellett HMAC-SHA512 támogatása #100
Comments
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
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
vagy
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
Ezt légy szíves fejtsd ki bővebben! |
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
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.
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."
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)
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
É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! |
This comment has been minimized.
This comment has been minimized.
|
Előre is bocsánat, ez hosszú lesz.
Á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.
Szabványos megoldásról van szó.
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ó. Mac hmac = Mac.getInstance("HmacSHA512");
hmac.init(new SecretKeySpec(key, "HmacSHA512"));
return hmac.doFinal(msg);OpenSSL parancssor
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.
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.
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).
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
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:
Saját kód
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 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: De ettől függetlenül ugye nem azt javaslod, hogy üzleti-/adótitkot egy online toolra bízzak?
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. |
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
Bocs, megint hosszú.
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 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.
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.
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.
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.
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. |
This comment has been minimized.
This comment has been minimized.
|
Szia @bachratyg
Í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):
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
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. |
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:
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 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?