Luuletko, että nonce-ohjelmien toteuttaminen on yksinkertaista? Mieti uudelleen. Olitpa rakentamassa onchain-protokollia tai offchain-infrastruktuuria, oikea nonce-toteutus on yksi kryptografisen turvallisuuden hankalimmista osista. Sukellaan siihen, miksi toistosuojaus on vaikeampaa kuin miltä se näyttää 👇

2/ Ensin ymmärretään digitaaliset allekirjoitukset. Julkisen avaimen kryptossa (kuten BLS:ssä) sinulla on yksityinen avain, joka allekirjoittaa viestit, ja julkinen avain, joka vahvistaa ne. Ethereumissa: osoite = julkisen avaimen hajautusarvo viesti = tapahtuman hajautusarvo Allekirjoitus = 64 tavua salaustodistusta

3/ Tässä on ongelma: useimpien julkisen avaimen salausprotokollien matematiikka ei rajoita sitä, kuinka monta kertaa allekirjoitus voidaan tarkistaa samaa viestiä vastaan. Kun sinulla on kelvollinen allekirjoitus, voit toistaa sen loputtomiin. Tämä avaa oven hyökkäysten toistamiseen.

4/ Syötä nonce: "kerran käytetty numero", joka estää uusintahyökkäykset. Kun kuluttaja saa viestin, jossa on nonce, se tarkistaa, onko noncea käytetty aiemmin. Jos kyllä, → hylkää. Ethereum-transaktiot käyttävät tätä mallia.

5/ Mutta nonce-toteutus on petollisen monimutkaista. Keskeiset vaatimukset: - Noncet eivät saa KOSKAAN olla uudelleenkäytettäviä (tässä ketjussa tai muissa) - On estettävä uusintahyökkäykset pysyvästi - Tarvitaan mekanismeja varaston kasvun käsittelemiseksi - On kestettävä etuhyökkäyksiä vastaan

6/ Naiivi ratkaisu: tallenna kaikki noncet tietokantaan ikuisesti. Tässä on kaksi suurta ongelmaa: a) Rajoittamaton tallennustilan kasvu (erityisesti roskapostihyökkäyksissä) b) Alttius etuhyökkäyksille Ongelma (a) on helpompi ratkaista kuin (b). Käsitellään ensin varastointia...

7/ Aikaleimapohjaiset noncet ratkaisevat tallennustilan kasvun! Käytä aikaleimaa + vanhenemisaikaa. Yli 5 minuuttia vanhat noncet poistetaan tietokannasta. Mutta entä samanaikaiset viestit samalta tililtä? Niillä on yhteinen aikaleima. Ratkaisu: aikaleima + random_bytes rakeiseen ainutlaatuisuuteen.

8/ Etujuoksu on hankala osa. Haitalliset toimijat voivat siepata kelvollisia allekirjoituksia, suorittaa ne etukäteen merkitäkseen noncet käytetyiksi, jolloin laillisen käyttäjän kutsu hylätään. Tämä on ongelmallista onchainissa erätoiminnoissa, jos yksi virheellinen allekirjoitus hylkää koko erän. Offchain: käytä TLS-salausta! Älä anna kenenkään pahantahtoisen toimijan koskaan nähdä noncea tai allekirjoitusta.

9/ Älä unohda sinnikkyyttä! Jos nonce-välimuisti on vain muistissa, hyökkääjät voivat toistaa vanhat noncet uudelleen järjestelmän uudelleenkäynnistyksen jälkeen. Säilytä aina nonce-tila pysyvässä tallennustilassa ja lataa uudelleen käynnistyksen yhteydessä. Vain muistin välimuistit = toiston haavoittuvuusikkuna.

10/ Ainutlaatuiset noncet kuluttajaa kohden! Kun lähetät useille käyttäjille, jokaisen pitäisi saada erilainen viesti/allekirjoitus. Muuten olet alttiina Man-in-the-Middle-hyökkäyksille, joissa yksi vastaanottaja välittää viestin edelleen ja esiintyy alkuperäisenä lähettäjänä.

11/ Inkrementaalisilla nonceilla (kuten Ethereum, nonce = prev nonce + 1) on paikkansa, mutta ole varovainen! Ne luovat valtavia haasteita ketjun ulkopuoliselle infrastruktuurille: epäjärjestyksessä olevia viestejä, synkronointiongelmia ja monimutkaisia palautusskenaarioita. Käytä vain, jos olet varma, että viestit saapuvat (tai niiden täytyy) saapua peräkkäin.

Yhteenveto - Noncen käyttöönoton tarkistuslista: ✅ Käytä nonceja uusintahyökkäysten estämiseen ✅ Säilytä nonce-tila uudelleenkäynnistysten välillä ✅ Ota käyttöön vanhenemismekanismit (aikaleima + puhdistus) ✅ Tee nonceista ainutlaatuisia vastaanotinta kohden ✅ Suojaa etuajolta salatuilla kanavilla ✅ Vältä inkrementaalisia nonceja, ellei järjestystä taata Turvallisuus on yksityiskohdissa! 🛡️