Platby sú najcitlivejšia časť každého systému, kde sa pohybujú peniaze. Regulátor chce vedieť, kto čo zaplatil a kedy, zákazník chce istotu, že mu z účtu neodíde nič navyše, a prevádzkovateľ nesmie žiadnu transakciu stratiť ani zdvojiť. Článok je pre architektov a vedúcich vývoja, ktorí navrhujú alebo schvaľujú platobné rozhranie.

V rokoch 2017 – 2022 sme cez partnerskú spoločnosť ako súčasť vývojového tímu win2day Rakúskej lotérie navrhli a implementovali bezpečnosť platobných transakcií: digitálne podpisy požiadaviek, správu a rotáciu kľúčov, ochranu proti opakovaniu požiadaviek a integráciu do Java backendu a aplikácií pre web, Android, iOS a Huawei. Text nižšie tú implementáciu neopisuje. Je to všeobecný súhrn pravidiel, ktoré by sme dnes uplatnili pri každom podobnom systéme.

Čo HTTPS chráni a čo nie

TLS 1.3 (RFC 8446) dáva spojeniu tri vlastnosti: server je vždy overený (klient len voliteľne), údaje vidia iba koncové body a útočník ich nedokáže nepozorovane zmeniť. HTTPS teda chráni dôvernosť aj integritu prenosu. Sú to však vlastnosti kanála, nie transakcie. Ochrana končí tam, kde sa TLS ukončí, teda na vyvažovači záťaže, CDN alebo API bráne. RFC 9421 výslovne uvádza, že za takou bránou nemožno zaručiť integritu ani autenticitu správy medzi klientom a aplikáciou. TLS navyše nerieši, či odosielateľ smie operáciu vykonať, ani či nejde o opakovanie staršej požiadavky.

Pozor treba dať aj na skoré dáta (0-RTT) v TLS 1.3. Podľa RFC 8446 nemajú zaručenú ochranu proti opakovaniu medzi spojeniami a klient má takto posielať len to, čo je bezpečné zopakovať. Platobné volania medzi ne nepatria.

1. Podpisujte transakciu, nielen spojenie

Každá platobná požiadavka má niesť digitálny podpis na aplikačnej úrovni, ktorý server overí skôr, než čokoľvek zapíše. Podpis zostáva pri požiadavke aj za bránou, dá sa uložiť a overiť v audite aj po rokoch a pri spore je silným dôkazom toho, čo klient odoslal. Serverové záznamy a údaje platobnej brány tým nenahrádza, dopĺňa ich. Pre HTTP na to existuje štandard HTTP Message Signatures (RFC 9421, február 2024).

SHA256withRSA, s ktorým sme pracovali, je v Jave podpis RSASSA-PKCS1-v1_5 nad odtlačkom SHA-256. RFC 8017 proti tejto schéme neuvádza známy útok, pre nové aplikácie však vyžaduje RSASSA-PSS. Alternatívou s menšími kľúčmi je ECDSA. Algoritmus má byť súčasťou verzovaného kontraktu a overovateľ má pre daný kľúč prijímať len očakávaný algoritmus. Výmena algoritmu potom neznamená prepisovať systém, čo príde vhod aj pri prechode na postkvantové podpisy (NIST ich štandardizoval v roku 2024 vo FIPS 204 a 205).

Vzájomné TLS (mTLS), pri ktorom sa certifikátom preukazuje aj klient, je dobrá voľba pre kanál medzi dvoma servermi, napríklad s platobnou bránou alebo dodávateľom hier, a OAuth naň vie naviazať prístupové tokeny (RFC 8705). Autentifikuje účastníkov a chráni prenos vrátane integrity dát v rámci spojenia. Nevytvára však samostatný podpis správy overiteľný po ukončení spojenia, preto podpis nenahradí. Obe vrstvy sa dopĺňajú: mTLS chráni kanál s partnerom, podpis obsah transakcie.

2. Presný kontrakt: čo sa podpisuje, v akom poradí a kódovaní

Väčšina chýb pri podpisoch nevzniká v kryptografii. Vznikajú tým, že klient a server zostavia podpisovaný obsah inak. Ak si web, Android, iOS a Huawei implementujú podpis každý po svojom, vzniknú štyri bezpečnostné modely a štyri sady chýb. Riešením je jeden písomný kontrakt a referenčná implementácia s testovacími vektormi (vstup, očakávaný podpisovaný reťazec, výsledok overenia), voči ktorým sa každý klient overuje v automatických testoch. Kontrakt určuje:

  • Čo sa podpisuje: všetko, čo mení význam operácie, teda suma, mena, účet či príjemca, typ operácie, identifikátor požiadavky, čas, identifikátor kľúča a verzia kontraktu, ako aj metóda a cesta, aby sa podpis jednej operácie nedal použiť na inú.
  • Poradie: JSON nezaručuje poradie kľúčov, preto buď podpisujte presné bajty tela spolu s odtlačkom (pole Content-Digest podľa RFC 9530, ktoré odporúča aj RFC 9421), alebo použite definovanú kanonizáciu, napríklad JSON Canonicalization Scheme (informatívne RFC 8785).
  • Kódovanie: UTF-8, jednoznačný formát času a súm (celé číslo v najmenšej jednotke meny alebo desatinný reťazec, nie číslo s plávajúcou desatinnou čiarkou).
  • Spracovanie: server pracuje presne s tým, čo overil. Ak overí jedno vyjadrenie údajov a spracuje iné (iný parser, hodnotu z nepodpísanej hlavičky), podpis nechráni nič.

3. Každá požiadavka platí raz: čas, nonce a idempotencia

Podpísanú požiadavku možno odchytiť a poslať znova a podpis bude stále platný. RFC 9421 to výslovne uvádza a ako protiopatrenie ponúka jedinečnú hodnotu (nonce) a čas vytvorenia a expirácie podpisu. Server odmietne požiadavku mimo krátkeho okna platnosti (s rezervou na nepresné hodiny mobilov) a nonce si pamätá len počas tohto okna, takže úložisko nerastie donekonečna. Kontrola a zápis nonce musia byť atomické, napríklad cez jedinečné obmedzenie v databáze, inak dve súbežné kópie prejdú obe.

Bežnejším problémom je dvojklik na slabom pripojení alebo klient, ktorý po výpadku pošle tú istú platbu znova s novým nonce. Ten rieši až idempotentný kľúč, ktorý identifikuje obchodnú operáciu, nie správu. POST podľa RFC 9110 idempotentný nie je, takže rozhranie potrebuje vlastný mechanizmus. IETF ho pripravuje ako hlavičku Idempotency-Key (k októbru 2026 stále návrh, nie RFC). Opakovanie s rovnakým kľúčom dostane odpoveď zodpovedajúcu pôvodnej operácii, rovnaký kľúč s iným obsahom je chyba a súbežná požiadavka s kľúčom, ktorý sa ešte spracúva, je konflikt. Kľúč a výsledok ukladajte v tej istej databázovej transakcii ako zaúčtovanie.

4. Serverový súkromný kľúč neopúšťa server

Častá chyba, ktorú v návrhoch vidíme, je podpisový kľúč v mobilnej aplikácii alebo v JavaScripte. Čokoľvek je v balíku aplikácie alebo v kóde prehliadača, sa dá vytiahnuť. Testovacia príručka OWASP pre mobilné aplikácie (MASTG) má na napevno zapísané kľúče samostatné testy. Ak má klient podpisovať, tak len vlastným kľúčom vygenerovaným v zariadení: v Android Keystore, kde môže byť viazaný na bezpečný hardvér a nedá sa vyexportovať, alebo v Secure Enclave na zariadeniach Apple. Secure Enclave podporuje len eliptické kľúče NIST P-256, s čím treba počítať pri voľbe algoritmu spoločného kontraktu. Kľúč zariadenia dokazuje „túto inštaláciu“, nie používateľa, autentifikáciu teda nenahrádza.

Serverový kľúč patrí do hardvérového bezpečnostného modulu (HSM) alebo cloudovej služby na správu kľúčov (KMS), kde sa podpisuje vo vnútri a aplikácia kľúčový materiál nevidí. Nepatrí do repozitára ani do konfigurácie nasadzovanej s aplikáciou. Každé prostredie a účel má mať samostatný kľúč. PCI DSS od poskytovateľov služieb vyžaduje, aby ich dokumentovaná kryptografická architektúra bránila použitiu rovnakých kľúčov v produkcii a v teste.

Rotácia sa navrhuje od začiatku. NIST SP 800-57 rozlišuje obdobie, keď sa kľúčom smie podpisovať, a obdobie, keď sa ešte smú overovať ním vytvorené podpisy. Z toho vyplýva postup bez výpadku: požiadavka nesie identifikátor kľúča, nový verejný kľúč sa zverejní vopred, overovatelia istý čas prijímajú oba (prekryv), potom sa starým prestane podpisovať a jeho verejná časť ostane na overovanie archívu. Pripravená musí byť aj revokácia pri kompromitácii: okamžité zablokovanie kľúča, vydanie nového a vopred vyskúšaný postup.

5. Výsledok od tretej strany sa overuje, nie preberá

Výsledok hry od externého výrobcu znamená pohyb na účte hráča, potvrdenie od platobnej brány mení stav platby. Volanie partnera má mať overený pôvod (podpis alebo mTLS) a časovú známku. Potom sa overuje obsah: transakcia u nás existuje, suma a mena sedia s tým, čo sme odoslali, prechod stavu je povolený (zamietnutá platba sa nezmení na úspešnú) a výsledok hry zodpovedá pravidlám a limitom. Duplicitné notifikácie sú bežné, preto musí byť spracovanie idempotentné. Ak partner ponúka dotaz na stav, rozhodujúce potvrdenie si vyžiadajte sami. Nezrovnalosť sa zastaví pred zaúčtovaním, nie po ňom. Dôvera v partnera nie je bezpečnostný mechanizmus.

Podobný princíp pozná PSD2. Pri silnej autentifikácii klienta pri platbách na diaľku vyžaduje delegované nariadenie (EÚ) 2018/389 dynamické prepojenie, teda autentifikačný kód viazaný na sumu a príjemcu, ktorý každá ich zmena zneplatní. Táto povinnosť zaväzuje poskytovateľov platobných služieb, nie obchodníka. Obchodník dostane od brány výsledok a ten treba overiť.

6. Audit je produkt, citlivé údaje doň nepatria

Regulátor chce vedieť, či viete rýchlo zrekonštruovať konkrétnu transakciu, samotné logy na to nestačia. Záznam preto obsahuje identifikátor požiadavky, idempotentný kľúč, identifikátor kľúča, výsledok overenia podpisu, čas servera a stav pred operáciou a po nej. Logy majú byť chránené proti úprave a mazaniu a prístup k nim evidovaný, ako odporúča aj OWASP. Taký záznam je zároveň najlepší nástroj podpory pri reklamáciách.

OWASP radí medzi údaje, ktoré do logov priamo nepatria, prístupové tokeny, heslá, kľúče a údaje o platobných kartách a bankových účtoch. Pre kartové údaje je záväzný PCI DSS (aktuálne v4.0.1, verzia 4.0 bola vyradená koncom roka 2024). Číslo karty sa pri zobrazení maskuje najviac na BIN a posledné štyri číslice a pri uložení musí byť nečitateľné, a to skrátením, tokenizáciou, silným šifrovaním alebo hashom celého čísla. Od 31. marca 2025 musí ísť o kľúčovaný hash (napríklad HMAC), lebo obyčajný hash čísla s nízkou entropiou sa dá dohľadať hrubou silou. Rovnaká logika platí pre IBAN, hoci pod PCI DSS nespadá.

Kontrolný zoznam pre návrh

  • Vieme, kde sa ukončuje TLS, a platobné volania neprijímajú 0-RTT.
  • Verzovaný kontrakt podpisu určuje polia, poradie, kódovanie a algoritmus. Každá platforma má testy voči spoločným testovacím vektorom a server spracúva presne to, čo overil.
  • Každá požiadavka má čas a nonce s atomickou kontrolou opakovania, každá platobná operácia idempotentný kľúč uložený spolu so zaúčtovaním.
  • Serverový kľúč je v HSM alebo KMS, oddelený podľa prostredia a účelu. V klientovi nie je žiadny kľúč servera.
  • Rotácia s prekryvom aj revokácia pri kompromitácii sú opísané a vyskúšané.
  • Pri výsledku od tretej strany overujeme pôvod, čas, existenciu transakcie, sumu, menu a prechod stavu.
  • Transakcia sa dá zrekonštruovať z auditu, hoci logy neobsahujú tokeny, heslá, kľúče ani čitateľné čísla kariet a účtov.

Kedy to celé nerobiť a čo z toho vyplýva

Nie každý systém potrebuje vlastný podpis klientskych požiadaviek. Ak e-shop presmeruje zákazníka na platobnú stránku brány a údaje karty sám nespracúva, väčšinu ťarchy nesie brána. Overovanie jej notifikácií, idempotencia a audit však ostávajú. Vlastná podpisová vrstva sa oplatí tam, kde klient priamo hýbe peniazmi na účte, ktorý vediete vy: herné a stávkové účty, peňaženky, interné platobné príkazy.

Bezpečnosť platieb je súčasť architektúry, nie modul doplnený pred spustením. Kontrakt podpisu, idempotencia a rotácia kľúčov sa navrhujú spolu s dátovým modelom a rozpočet má počítať s referenčnou implementáciou, testovacími vektormi a nácvikom revokácie. Idempotencia a audit sa oplatia aj mimo bezpečnosti, lebo znamenajú menej duplicitných platieb a rýchlejšie reklamácie. Jadro pravidiel pochádza z online hazardu, rovnako však platí pre e-shop či fintech.