Closed bachratyg closed 4 years ago
kabelnet2
commented
4 years ago 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
commented
4 years ago 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!
NTCA-developer
commented
4 years ago 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
commented
4 years ago 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
É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
commented
4 years ago 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.binOpenSSL 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
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ó
é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
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago 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.
bachratyg
commented
4 years ago Íme egy rész a 2007-es kiírásból:
NIST has decided that it is prudent to develop a new hash algorithm to augment and revise FIPS 180-2.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.Tehát a cél: 'to augment and revise'. Márpedig ha valami feljavít valamit akkor annak az elhagyása egy downgrade.
Augment: nagyobbít, kibővít; revise: felülvizsgál. A valami aminek a kiegészítése történik, az a FIPS 180-2. A felülvizsgálat megtörtént, ebből lett a FIPS 180-4 és a FIPS 202. Mindkettőnek az applicability szakaszában le van írva, hogy akár az akár a másik használható kormányzati alkalmazásra. Feljavításról itt az egész hash eszközkészlet vonatkozásában van szó, pontosan abban az értelemben, amit korábban írtam: ha valamelyik kompromittálódik, akkor ott van a tartalékmegoldás.
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.
Miért is? Az eredményhirdetést press release-ben szóról szóra ez van írva: https://www.nist.gov/news-events/news/2015/08/nist-releases-sha-3-cryptographic-hash-standard
"SHA-3 is very different from SHA-2 in design," says NIST's Shu-jen Chang. "It doesn't replace SHA-2, which has not shown any problem, but offers a backup."
Továbbá:
According to Chang, the two standards will complement each other and offer more options to designers of both hardware and software.
Vagyis egymást egészítik ki. Ami a te logikád szerint azt jelenti, hogy ha az egyiket elhagyom a kettőből, az bizony downgrade.
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.
Kifejtettem az előzőekben, hogy ez a költség mi miatt keletkezik. Érdemben cáfold légy szíves! Ha mutatsz nekem egy olyan alternatívát, ami emberi beavatkozás nélkül, konfigurálható ütemezéssel/policyval telepíthető/frissíthető, széles körben elterjedt, stabil support van mögötte (adott esetben paid support), fenntarthatónak látszik (ld. a szakma negatív megjegyzéseit az OpenSSL kódbázisra), nem utolsó sorban igen nagy a hangsúly a visszafelé kompatibilitáson, akkor a probléma meg van oldva, a költség minimálissá válik. Ezek az alapvető elvárásaim egy mission critical rendszer valamely komponensével kapcsolatban. Az ettől eltérés vagy fenntartási emberóra vagy kockázat (veszteség) formájában költségként realizálódik, ennek megfelelően csak akkor szándékozom eltérni tőle, ha a költség előnnyel van ellensúlyozva. Értékelhető előnyt pedig még mindig nem látok.
A TLS átállással is ugyan ez volt a helyzet.
Az összehasonlítás akkor lenne helytálló, ha csak a TLS 1.3-at támogatnátok és azt is csak pl. ed25519 kulccserével. Ha a SHA-3-nak is olyan szintű lenne az adoption-ja (ami finoman szólva langyos), mint a jelenlegi TLS 1.2 elvárásoknak (amit a piaci szereplők elsöprő többsége már egy ideje implementál), ez az issue nem jött volna létre. Az átállással fél sort kellett átbillenteni.
É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, hogy egy algoritmus mennyire öreg önmagában semmit nem ront a minőségén. Ha mégis így lenne, akkor a TLS-ből nyugodtan kidobhatnátok az összes DHE protokollt, ami a 40-es éveiben járó Diffie-Helmannra épül.
Arról pedig szó nincs, hogy senki ne merne hozzányúlni a rendszereinkhez. Minden egyes upgrade-nél mérlegeljük, hogy annak költsége (értsd fejlesztés+hibák miatti fennakadás+nem kiforrott technológia miatti kockázat) milyen viszonyban van a status quo költségével (értsd: kompromittálódás valószínűsége * okozott veszteség). Ha tényleg senki nem merne hozzányúlni, az masszívan növelné az utóbbi súlyát és SHA-3-tól függetlenül már rég megtörtént volna az upgrade. Számba vannak véve az előnyök meg a hátrányok, a döntéshozó ez alapján meggyőzhető. Most viszont az van, hogy ránk van erőltetve egy olyan követelmény, amit az alacson TCO-ra belőtt, minden komponensében még hosszú-hosszú évekre garantáltan supportált rendszeren is csak úgy lehet implementálni, hogy az visszalépéssel jár. Értékelhető előnyt még mindig nem látok, ami ezt a hátrányt kompenzálná.
NTCA-developer
commented
4 years ago Szia!
Még nem fulladtunk ki az érvekből, de azt hiszem ezen a ponton volna értelme abbahagyni. Ha ennyi idő alatt sem győztük meg egymást, akkor érdemi változást remélni a folytatástól felesleges.
A lehetőséget és a diskurzust minden esetre köszönöm, remélem megtalálod a számodra legjobb megoldást az implementációhoz! Sajnálom hogy nem tudunk segíteni, máshogy látjuk a dolgokat. Van ilyen.
aldaris
commented
4 years ago @NTCA-developer Mielőtt még ez az egész diskurzus kárba veszne szeretném megjegyezni, hogy érdemes lenne megfontolni az algoritmus felvitelét az XML-be. Ha csak maga az aláírás szerepel az XML-ben, nehezebb lesz a jövőben lecserélni az algoritmust amikor az SHA3-512 kevésbé biztonságossá válik.
bsibsi
commented
4 years ago Véleményem szerint is hasznos lenne alternatívát biztosítani a SHA3-512-hez, legalább a korábban javasolt szinten, hogy opcionláisan tagelhető lenne a requestSignature, amit a schema visszamenőleges kompatibilitásával együtt is meg lehetne tenni például úgy, hogy amennyiben az algoritmus nincs megadva, akkor a default SHA3-512-t használja. Bármikor felmerülhet, hogy biztonsági okból cserélni szükséges ezt az algoritmust és szerencsétlen volna, ha emaitt schemat kellene változtatni.
Ugyan személy szerint sem a SHA3-512-vel, sem a HMAC-SHA512-vel nincs fenntartásom, a fenti okokból én is támogatom a felvetést, hogy további választható algoritmusok is bekerüljenek az SHA3-512 mellé. Nyilván szerencsésebb lett volna, ha hamarabb felmerül ez az igény, de amennyiben még van rá lehetőség hogy hozzányúljatok a kódbázis ezen részéhez, nem lenne haszontalan, hiszen így sokkal időtállóbb és elegánsabb lehetne a design.
hontvari
commented
4 years ago Ubuntu 16.04 LTS még bőven supportolt, Java 8 van benne, abban meg SHA3 nincs. Én is beemeltem inkább egy githubon talált SHA3 forrást, mert az alternatíva oprendszer upgrade lenne több gépen.
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. https://github.com/nav-gov-hu/Online-Invoice/issues/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 https://github.com/nav-gov-hu/Online-Invoice/issues/6#issuecomment-488807893 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?