Portfele z Passkey na Ethereum: ERC‑4337, EIP‑7212 i realne bezpieczeństwo WebAuthn w DeFi

Kategorie: Portfele (Wallets), Bezpieczeństwo, Ethereum (ETH) & Smart-contracty, DeFi, Web3 & DAO

Wstęp: Czy rok bez seedów już nadszedł?

Coraz więcej projektów Web3 testuje portfele bez fraz seed – oparte o passkeys (WebAuthn) i Account Abstraction (ERC‑4337). Czy to faktyczny koniec karteczek z 12 słowami i początek masowej adopcji DeFi? Jakie ryzyka niesie podpisywanie transakcji odciskiem palca lub kluczem sprzętowym FIDO2? Ten artykuł, pisany z perspektywy bezpieczeństwa i praktycznego wdrożenia, odpowiada na te pytania i pokazuje, jak zbudować dApp zgodną z EIP‑7212 (secp256r1) i EIP‑1271.

Co to jest Passkey w kontekście krypto?

Passkey to połączenie standardów FIDO2/WebAuthn i kryptografii krzywych eliptycznych, które pozwala potwierdzać tożsamość lokalnie (biometrią, PIN‑em) i wykonywać podpisy cyfrowe bez wpisywania haseł. W praktyce dla krypto oznacza to, że podpisywanie transakcji może odbywać się kluczem przechowywanym w bezpiecznym środowisku urządzenia (Secure Enclave/TPM) lub na zewnętrznym kluczu sprzętowym.

Dlaczego passkeys są przełomowe dla portfeli?

• Brak seeda – użytkownik nie widzi frazy; ryzyko phishingu na seed maleje.
• Silna kryptografia sprzętowa – prywatny klucz nigdy nie opuszcza bezpiecznego modułu.
• Lepszy UX – logowanie i podpis palcem, twarzą lub kluczem FIDO2.
• Wielourządzeniowość – synchronizowane passkeys (opcjonalnie) albo niezależne klucze per urządzenie.

ERC‑4337 + EIP‑1271: jak kontraktowy portfel rozumie podpisy WebAuthn

Kluczowy element układanki to Account Abstraction (ERC‑4337). Zamiast „EOA + seed”, mamy kontrakt‑konto z własną logiką weryfikacji podpisów, limitami, guardianami i płatnikiem opłat.

• EntryPoint i Bundler – transakcje typu UserOperation są łączone poza łańcuchem i wprowadzane on‑chain.
• EIP‑1271 – standard sprawdzania podpisu dla kontraktów. Pozwala kontraktowi zaakceptować podpis, który nie jest klasycznym ECDSA/secp256k1, np. WebAuthn (secp256r1) lub MPC.
• Paymaster – sponsoruje gas (np. opłaty w stablecoinie lub całkowity „gasless”).

W efekcie dApp może przyjąć podpis WebAuthn jako dowód autoryzacji operacji, a kontrakt portfela weryfikuje go przez isValidSignature (EIP‑1271).

EIP‑7212: secp256r1 dla passkeys na Ethereum

Tradycyjny Ethereum używa secp256k1. Passkeys na urządzeniach końcowych zwykle operują na secp256r1 (P‑256). EIP‑7212 proponuje prekompilację weryfikacji podpisów P‑256, by uczynić je tanimi i praktycznymi on‑chain. To otwiera drzwi do natywnego wsparcia passkeys w smart‑portfelach.

Konsekwencje dla projektantów portfeli

• Niższy koszt weryfikacji podpisów P‑256 na L1/L2.
• Spójność UX – jeden klucz/biometria działa w wielu dAppach.
• Kompatybilność EIP‑1271 – fallback na weryfikację kontraktową, gdy brak prekompilacji.

Architektury: WebAuthn, MPC i moduły guardians

Istnieje kilka wzorców budowy portfeli passkey‑ready:

• WebAuthn single‑signer – kontrakt portfela przyjmuje podpis wyłącznie z jednego klucza P‑256 (lokalny lub klucz sprzętowy FIDO2).
• MPC/Threshold – podpis powstaje z udziałem wielu części (np. urządzenie + serwer + hardware key), co redukuje ryzyko utraty jednego komponentu.
• Guardians & timelock – odzyskiwanie dostępu przez zaufane adresy/kontrakty (zwłaszcza przy utracie urządzenia), z opóźnieniem bezpieczeństwa.
• Session keys – krótkotrwałe klucze do mikro‑uprawnień w dApp (np. limit dzienny, whitelist funkcji), bez każdorazowego potwierdzania biometrią.

Gasless i paymasterzy: UX bez tarcia

Passkeys świecą pełnią blasku, gdy towarzyszy im gas sponsoring:

• Stablecoin gas – płacisz USDC/DAI, a paymaster rozlicza ETH w tle.
• Subskrypcje – miesięczny limit na koszty gas dla adresu, kontrolowany w kontrakcie.
• Reguły fraud – paymaster odrzuca podejrzane UO (np. nietypowe destynacje, zbyt duże allowance).

Ryzyka i jak je zminimalizować

Zagrożenie	Opis	Mitigacja
Vendor lock‑in	Passkey powiązany z chmurą ekosystemu (synchronizacja multi‑device).	Używaj także klucza sprzętowego FIDO2 jako drugiego faktora/guardiana.
Phishing UI	Podszyte modale logowania/biometrii na stronach dApp.	Origin binding WebAuthn, podpisywanie structured data z widocznym łańcuchem i adresem kontraktu.
Utrata urządzenia	Brak dostępu do passkey i do środków.	Guardians + timelock, kopia zapasowa: drugi klucz FIDO2, recovery przez MPC.
Centralizacja bundlerów/paymasterów	Ryzyko cenzury transakcji lub wzrostu opłat.	Multi‑provider routing, własny bundler, polityki fallback.
Błędy implementacji EIP‑1271	Niewłaściwa walidacja podpisów/formatów WebAuthn.	Audyt, test vectors FIDO, fuzzing, formalne specyfikacje.

Porównanie krzywych i weryfikacji on‑chain

Mechanizm	Krzywa	Wsparcie on‑chain	Typowe użycie
EOA klasyczny	secp256k1	Nattywne	MetaMask, klucze seed
WebAuthn/Passkey	secp256r1 (P‑256)	EIP‑7212 / EIP‑1271	Biometria/klucz FIDO2
MPC	Różne (agregacja)	EIP‑1271 (kontrakt)	Korporacyjne custody, TSS

Case study: DAO bez seedów i z limitem ryzyka

• Kontekst: Małe DAO zarządza skarbcem DeFi (L2), onboarding non‑crypto zespołu.
• Rozwiązanie: Portfele AA z passkey + guardianami (3/5), paymaster pokrywa gas, session keys do rutynowych wypłat z ograniczeniami.
• Efekt:
  • Czas wdrożenia członka: ~5 minut (bez seed, jeden QR + biometria).
  • Spadek błędów operacyjnych: brak literówek/seeda w e‑mailach.
  • Bezpieczeństwo: wszystkie transfery > 5 000 USDC wymagają 2 guardianów + 24h timelock.

DIY dla deweloperów: jak dodać passkeys do dApp (high‑level)

Tip: Utrzymuj allow‑list metod kontraktów dla session keys i wymuszaj krótki TTL klucza sesyjnego.

Pro / Contra portfeli z passkeys

Aspekt	Pro	Contra
UX	Szybkie logowanie, brak seed	Komunikaty WebAuthn bywają nieintuicyjne
Bezpieczeństwo	Klucz w Secure Enclave/kluczu FIDO2	Ryzyko zależności od ekosystemu chmury
Koszty	EIP‑7212 obniża koszt weryfikacji	Dodatkowa złożoność AA (bundler, paymaster)
Adopcja	Znane UX z Web2	Nierówne wsparcie P‑256 na różnych L2

Bezpieczeństwo i prawo: na co uważać?

• RODO/zgody biometryczne: biometrii nie wolno wysyłać na serwer – WebAuthn jej nie udostępnia, ale polityka prywatności musi to jasno tłumaczyć.
• Regulamin recovery: transparentne zasady guardianów, opóźnień i odpowiedzialności.
• Środowiska zaufania: w firmach – polityki MDM, wymagane klucze FIDO2 dla transakcji powyżej progu.

Checklist wdrożeniowy (dApp/portfel)

• Origin‑bound WebAuthn (rpId = produkcyjna domena).
• EIP‑1271 pokryty testami i zgodny z EIP‑7212 (jeśli dostępny).
• Guardians + timelock domyślnie aktywne.
• Session keys z TTL, allow‑list i limitami kwotowymi.
• Paymaster z polityką anty‑fraud i opcją wyłączenia.
• Export urządzeń: instrukcje dodania drugiego klucza FIDO2 offline.

Najczęstsze pytania (FAQ)

Czy mogę używać passkey offline?

Tak, jeśli to klucz sprzętowy FIDO2. Passkeys synchronizowane chmurowo wymagają czasem połączenia dla pierwszej konfiguracji lub odzyskania.

Co gdy przestanę ufać dostawcy systemu/telefonu?

Dodaj niezależny klucz FIDO2 (air‑gapped) jako guardiana i przygotuj ścieżkę migracji (rotacja klucza w kontrakcie).

Czy passkeys działają na wszystkich L2?

Tak, przez EIP‑1271. Wydajność i koszt poprawia się tam, gdzie dostępne jest EIP‑7212 lub równoważne prekompilacje.

Wnioski i rekomendacje

Portfele z passkeys + ERC‑4337 znacząco podnoszą bezpieczeństwo i obniżają barierę wejścia do DeFi. Aby uniknąć nowych wektorów ryzyka, wdrażaj guardians, timelock, session keys i niezależny klucz FIDO2 jako plan B. Jeśli budujesz dApp, zaplanuj weryfikację podpisów przez EIP‑1271 oraz wsparcie EIP‑7212, a onboarding stanie się porównywalny z Web2 – bez kompromisów w kontroli środków.

CTA: Zespole produktowy – uruchom pilota na testnecie z paymasterem i session keys. Zadbaj o audyt EIP‑1271 i scenariusze recovery, zanim zaprosisz pierwszych użytkowników.