Adatintegritásról beszélve gyakran egymás helyett használjuk a checksum, hash, HMAC és digitális aláírás szavakat. Mindegyik rövid ellenőrző értéket kapcsolhat egy üzenethez, de más támadási modellre válaszol. Egy CRC kiválóan észlelhet véletlen bithibát, miközben egy támadó könnyen újraszámolja módosított adathoz. Egy digitális aláírás eredetet igazolhat, de csak akkor, ha a publikus kulcs valóban a feltételezett félhez tartozik. A megfelelő eszköz kiválasztása a bizonyítandó állítással kezdődik.

A checksum átviteli és tárolási hibát keres

Egyszerű összeg, CRC vagy más hibadetektáló kód arra optimalizálható, hogy zaj, sérült blokk vagy felcserélt bitek ne maradjanak észrevétlenek. Gyorsan számítható hardverben és szoftverben, ezért hálózati frame-ekben, archívumokban és tárolóformátumokban hatékony.

Nem feltételez aktív ellenfelet. Aki meg tudja változtatni a payloadot, rendszerint az új checksumot is kiszámítja. Ezért egy sikeres CRC nem bizonyítja, hogy az adat megbízható szervertől jött vagy nem manipulálták szándékosan.

A kriptográfiai hash támadóval szembeni tulajdonságokat ad

SHA-256 vagy más modern hash esetén nehéz adott lenyomathoz bemenetet, illetve azonos hash-ű két tartalmat találni. Ez erősebb, mint a véletlen hibadetektálás, és lehetővé teszi tartalomcímzett objektumok, Merkle-fák és reprodukálható build-artifactok ellenőrzését.

A függvény nyilvános és kulcs nélküli. Támadó is számíthat hash-t a módosított fájlhoz. A várt lenyomatnak ezért hitelesített forrásból kell érkeznie, különben csak belső konzisztenciát bizonyít.

A HMAC közös titokhoz köti az üzenetet

A Hash-based Message Authentication Code kriptográfiai hash-t és titkos kulcsot kombinál szabványos konstrukcióban. Csak az tud érvényes tag-et készíteni, aki ismeri a kulcsot. API webhook, belső szolgáltatásközi üzenet vagy cookie hitelessége így ellenőrizhető.

Nem helyes egyszerűen a titkot az üzenet elé vagy mögé fűzni és hash-elni. Egyes hash-konstrukcióknál length-extension és más protokollhibák jelentkezhetnek. A standard HMAC könyvtár ezeket kezeli, és pontosan definiálja a kulcs feldolgozását.

A HMAC mindkét felet aláíróvá teszi

Mivel a küldő és fogadó ugyanazt a titkot ismeri, bármelyikük készíthet érvényes MAC-et. Ez jó két fél közötti hitelesítéshez, de nem alkalmas arra, hogy később független bírónak bizonyítsuk, pontosan melyik fél állította elő az üzenetet.

Minél több szolgáltatás osztozik ugyanazon a kulcson, annál gyengébb az attribúció és nagyobb a kompromittálódási felület. Célszerű partnerenként, környezetenként és célonként külön kulcsot használni, verzióval és rotációs lehetőséggel.

A digitális aláírás aszimmetrikus kulcsokat használ

Az aláíró privát kulccsal készít aláírást, a fogadók pedig publikus kulccsal ellenőrzik. A verifier nem kap képességet új érvényes üzenetek előállítására. Ez szoftverkiadásnál, dokumentum-jóváhagyásnál és sok résztvevős protokollnál alapvető előny.

Az aláírás gyakorlati implementációja rendszerint az üzenet megfelelően kódolt hash-én működik, de a könyvtárnak kell kezelnie a paddinget, görbét és domain separationt. „Titkosítsuk a hash-t privát kulccsal” nem elég pontos vagy minden algoritmusra helyes modell.

A publikus kulcs identitása külön bizalmi probléma

Egy matematikailag érvényes aláírás csak azt bizonyítja, hogy a megfelelő privát kulcs készült vele. Ha a támadó saját publikus kulcsát csempészi a konfigurációba, a verifikáció továbbra is sikeres lesz. Tanúsítvány, pinned key, megbízható key directory vagy más elosztási lánc köti a kulcsot a névhez.

A kulcs lejárata, visszavonása és kompromittálódása része az ellenőrzésnek. Hosszú távú dokumentumnál időbélyegzés és archiválási policy kellhet, hogy évekkel később is megállapítható legyen az aláírás akkori érvényessége.

A pontos üzenethatár minden konstrukciónál kritikus

Ha két mezőt elválasztó vagy hosszjelölés nélkül fűzünk össze, például ab + c és a + bc, ugyanaz a bájtsor keletkezhet. Az aláírás vagy HMAC ekkor nem tudja, melyik strukturált jelentés volt szándékolt.

Szabványos serializáció, hosszprefix, típusjelölés és domain separation teszi egyértelművé a bemenetet. A verziószám is legyen része a hitelesített adatnak, hogy egy régi üzenet ne legyen más protokollkörnyezetben újraértelmezhető.

A webhook-aláírás időt és replay-védelmet igényel

Egy helyes HMAC bizonyítja, hogy a payloadot a kulcs ismerője hitelesítette, de ugyanaz a kérés korlátlanul újraküldhető. Timestamp, eseményazonosító és elfogadott időablak segít a replay felismerésében. A feldolgozó emellett idempotensen tárolja a már látott eseményeket.

A timestamp is a hitelesített üzenet része legyen, ne csak külön fejléc, amelyet támadó módosíthat. A verifier először parse-olja a nyers requestet, constant-time módon ellenőrzi a MAC-et, majd alkalmazza az idő- és duplikációs szabályt.

A nyers request body és a feldolgozott objektum eltérhet

JSON webhooknál a küldő gyakran a pontos HTTP body bájtjait írja alá. Ha a fogadó előbb parse-olja, majd újraserializálja az objektumot, megváltozhat whitespace, kulcssorrend vagy számformátum, és az ellenőrzés hibásan elbukik.

A framework middleware-nek meg kell őriznie a nyers bodyt a verifikációig. Ha a protokoll logikai struktúrát akar aláírni, közösen definiált kanonizálást kell használnia. A két modell nem keverhető véletlenszerűen.

A fájlmanifest több objektumot kapcsol össze

Egy release minden fájljához tartalmazhat SHA-256 hash-t, majd a teljes manifest kaphat digitális aláírást. Így nem kell külön minden nagy fájlt aláírni, és a csomag tartalma, neve, verziója egyetlen hitelesített struktúrában rögzíthető.

A verifier először ellenőrzi a manifest aláírását, majd minden letöltött artifact hash-ét. A fájlnév, méret és platform is legyen a manifest része, különben egy helyes tartalmat rossz célhoz lehet hozzárendelni.

A Merkle-fa nagy adathalmaz részleges bizonyítását adja

A levelek hash-eit páronként újra hash-elve egyetlen gyökérérték képviselhet sok objektumot. Egy elemhez rövid bizonyítás mutatja, hogy része volt a gyökérrel rögzített készletnek, anélkül hogy az összes többi adatot átadnánk.

A Merkle root továbbra is hitelesített publikációt igényel. Ha támadó a gyökeret is lecseréli, saját fát építhet. A struktúra hatékony integritási bizonyítást ad, nem automatikus bizalmat vagy konszenzust.

A kulcskezelés gyakran fontosabb, mint az algoritmus

Erős HMAC vagy aláírási algoritmus sem segít, ha a kulcs repositoryban, logban vagy minden fejlesztő laptopján megtalálható. A titkok kulcskezelőben éljenek, legkisebb jogosultsággal, auditált hozzáféréssel és rendszeres rotációval.

A verifier fogadhat több aktív key ID-t az átmenet alatt. A key ID nem lehet tetszőleges URL vagy fájlútvonal a támadó bemenetéből; csak előre megbízható kulcskészlet indexe. Kompromittált kulcs gyors kivonását gyakorolni kell.

Az összehasonlításnak constant-time módon kell történnie

HMAC és más titokfüggő tag esetén a normál string equality az első eltérő bájtnál visszatérhet. Sok mérésből ez időzítési információt adhat. A kriptográfiai könyvtár biztonságos compare függvénye azonos hosszúságú értékeket időfüggetlenebb módon vizsgál.

Az encodingot előtte szigorúan parse-olni kell. Hex és Base64 formátum ne legyen keverhető, hibás padding vagy eltérő hossz pedig egyértelmű elutasítás. A részletes belső hiba ne szivárogjon vissza úgy, hogy oracle-ként segítse a támadót.

A megfelelő primitív a fenyegetési modellből következik

Véletlen lemez- vagy hálózati hibára checksum elég és gyors. Tartalomazonossághoz modern hash kell. Két, közös titkot biztonságosan kezelő szolgáltatás között HMAC ad hitelességet. Sok verifier vagy harmadik félnek bizonyítható kiadás esetén digitális aláírás célszerű.

Ezek egymásra is épülhetnek, de nem helyettesítik egymást. A jó tervezés egy mondatban megnevezi, mit akar bizonyítani, ki lehet támadó, ki birtokol kulcsot és hogyan jut el a várt ellenőrző érték a fogadóhoz. Ezután az algoritmusválasztás már konkrét mérnöki döntés, nem terminológiai találgatás.