AI a kontrakty Meyera: chytáme kryptobugy před produkcí

# Jak AI agenti a kontrakty Meyera odhalují kryptografické chyby před nasazením do produkce

AI agenti mění pravidla hry ve vývoji zabezpečených systémů: místo ručního psaní kódu a testů generují implementaci na základě formálních kontraktů. To eliminuje hlavní příčinu selhání Design by Contract – dvojitou práci. V projektu s hardwarovým TRNG a PKI byly dvě kritické zranitelnosti objeveny právě díky kontraktovým testům, které by běžné unit testy přehlédly.

Proč testy nechytí logické chyby v kryptografii

Testy kontrolují jen to, co programátor předvídal. Pokud nevěděl o potřebě kontrolovat padding v RSA nebo kvalitu entropie před podáním do DRBG – test to nenapsal. Právě tak prošly miliony automatických kontrol 27letá chyba v OpenBSD a 16letá zranitelnost ve FFmpeg. Kompilátory a statické analyzátory jsou proti logickým chybám bezmocné: špatný režim šifrování, absence kontroly odvolání certifikátu, použití zastaralých standardů – to všechno jim unikne.

Klíčový problém: testy reagují na implementaci, ne na záměr. Kontrakty naopak fixují záměr ještě před psaním kódu. Definují hranice: co systém musí splnit (postpodmínky), co mu je zakázáno (invarianty) a za jakých podmínek ho lze volat (předpodmínky). Není to jen dokumentace – je to spustitelná specifikace.

Tohle odlišuje kontraktový přístup:

• Formálnost: PRE/POST/INV se zapisují strojově čitelně, ne do komentářů.
• Raná kontrola: porušení kontraktu selže hned, ne v produkci.
• Zaměření na záruky: místo „jak to funguje“ – „co je zaručeno“.
• Zdroj pravdy: kontrakt se nemění během vývoje, mění se jen při změně požadavků.

Jak AI agent přebírá druhou polovinu práce

Design by Contract selhal v mainstreame kvůli dvojí zátěži: nejdřív kontrakt, pak kód, pak testy. Pod tlakem termínu se kontrakty vyhazovaly první. Dnes AI agent přebírá implementaci a generování testů, člověku zůstane jen formulace kontraktu. To mění ekonomiku: jedna řádka kontraktu nahradí stovky řádků kódu a testů.

Proces vypadá takto:

• Člověk napíše invariant: padding == RSA-PSS | RSA-OAEP; PKCS#1 v1.5 == FORBIDDEN.
• Agent vygeneruje modul CryptoEngine, který používá jen povolené paddingy.
• Paralelně agent vytvoří contract-test, který zkusí PKCS#1 v1.5 a očekává výjimku.
• Pokud test selže – agent opraví implementaci, kontrakt nelze.
• Člověk kontroluje jen 10 řádků kontraktu, ne 1000 řádků kódu.

Výhody:

• Rychlost: 11 dní aktivní práce na fullstack embedded projekt místo měsíců.
• Spolehlivost: kontrakt je ohnisko, chyby v něm jsou snazší hledat než v kódu.
• Škálovatelnost: jeden člověk řídí agenty v různých rolích (koder, tester, architekt).

Reálný případ: PKI s hardwarovým TRNG a kontraktovými testy

Projekt pki-on-box zahrnuje pět modulů: STM32G431 (hardwarový TRNG), Python démon (DRBG podle NIST SP 800-90A), CryptoEngine (generace klíčů), KeyStorage (AES-256-GCM), CA služba (podpis X.509). Každý modul má formální kontrakt na rozhraní. Dvě kritické zranitelnosti byly nalezeny před nasazením:

• Špatný padding: implementace náhodně použila PKCS#1 v1.5 místo RSA-PSS. Bleichenbacherův útok umožňuje obnovit plaintext přes padding oracle – kontraktový test selhal okamžitě.
• Špatný AES režim: místo GCM byl zvolen ECB. Kontrakt vyžadoval authenticated encryption – test znovu selhal.

Metriky projektu:

• 131 komitů
• 62 contract-testů + 15 HW testů
• 3 MCU desky (STM32G474, G431, H750)
• Cílová platforma: RK3328 ARM64
• Náklady na AI: 1780₽ za 30 sezení
• Otevřený repozitář: github.com/vasilievsv/hw.pki-on-box

Kontrakty na rozhraních: kde vznikají kritické chyby

Logické chyby vznikají na hranicích modulů. DRBG vydává bajty – CryptoEngine musí vědět, jak je použít. Bez kontraktu – někdo zvolí padding podle StackOverflow. Zde jsou dva klíčové kontrakty z projektu:

contract: key_generation
  PRE:
    - DRBG.seeded == true
    - algorithm ∈ {RSA-2048, ECDSA-P384}
  POST:
    - private_key.encrypted(AES-256-GCM)
    - public_key = derive(private_key)
  INV:
    - padding == RSA-PSS | RSA-OAEP
    - PKCS#1 v1.5 == FORBIDDEN

contract: certificate_issuance
  PRE:
    - issuer_ca.valid() && !revoked()
    - csr.signature.verify() == true
  POST:
    - cert.serial.unique()
    - cert.signature.verify(issuer_ca.public_key) == true
  INV:
    - root_ca.offline == true
    - cert_chain.depth <= max_path_length

Kontraktový test pro padding:

def test_rejects_pkcs1v15_padding(self, crypto):
    priv, pub = crypto.generate_rsa_keypair(bits=2048)
    data = b"invariant check"
    sig = crypto.sign_data(priv, data)
    # PSS musí fungovat
    pub.verify(sig, data, padding.PSS(...))
    # PKCS1v15 musí selhat
    with pytest.raises(Exception):
        pub.verify(sig, data, padding.PKCS1v15(), hashes.SHA256())

Test nekontroluje funkcionalitu – kontroluje dodržení invariantu. Pokud se padding změní – test selže, i když podpis technicky „funguje“.

Co je důležité

• Kontrakty > testy: testy kontrolují implementaci, kontrakty záměr. Logické chyby chytí jen formální záruky.
• AI eliminuje dvojí práci: agent generuje kód a testy z kontraktu, člověk se soustředí na specifikaci.
• Kritické chyby na hranicích: padding, režimy šifrování, kontrola odvolání – vše řídí invarianty na rozhraních modulů.
• Otevřená verifikace: projekt s hardwarovým TRNG a kontraktovými testy je dostupný v otevřeném repozitáři k auditu.
• Ekonomika času: 11 dní na fullstack embedded systém místo měsíců – díky rolovému rozdělení a autogeneraci.

— Editorial Team