# Autentyczność plików binarnych

Speedwave podpisuje swoje pliki binarne na desktopie na dwóch osobnych warstwach, a każdy z nich obejmuje inny moment: pierwszą instalację aplikacji i aktualizację aplikacji, którą już masz. Zobacz [Bezpieczeństwo](/pl/docs/security/), by sprawdzić, jak to się wpisuje w resztę modelu bezpieczeństwa.

## Podpisywanie kodu chroni pierwszą instalację

Na macOS Speedwave podpisuje każdy plik binarny w paczce `Speedwave.app` certyfikatem Speednet Developer ID Application, w tym dołączone Lima, Node.js, helpery w Swift i CLI napisane w Ruście. Każdy plik binarny korzysta z Hardened Runtime i ma znacznik czasu Apple. Speedwave przesyła całą paczkę do Apple Notary Service i doczepia do aplikacji uzyskany bilet notarialny, dzięki czemu Gatekeeper może zweryfikować ją offline.

Ta warstwa działa przy każdym pobraniu DMG i przy każdym późniejszym uruchomieniu aplikacji. Blokuje trzy rzeczy: plik binarny zmodyfikowany po drodze nie przejdzie weryfikacji podpisu w Gatekeeperze, tylko posiadacz prywatnego klucza Speednet może wyprodukować pliki binarne, które tę weryfikację przejdą, a Hardened Runtime blokuje typowe sposoby wstrzykiwania kodu do działającego procesu.
**Windows jeszcze bez podpisu:** To podpisywanie działa przez Gatekeeper, który jest dostępny tylko na macOS. Podpisywanie kodu dla Windows jeszcze nie zostało wdrożone, więc nie zakładaj takiej samej ochrony na Windows.

## Podpisane aktualizacje chronią zainstalowane aplikacje

Gdy Speedwave jest już zainstalowany, jego auto-updater sprawdza każdą pobraną aktualizację względem klucza publicznego Ed25519 osadzonego w aplikacji. Pasujący klucz prywatny znajduje się w CI, a nie na komputerze żadnego dewelopera. Atakujący, który przejął miejsce pobierania wydań, ale nie ten klucz CI, nie jest w stanie wypuścić aktualizacji: updater odmawia instalacji czegokolwiek niepodpisanego albo podpisanego niewłaściwym kluczem. Sposób pobierania i stosowania samej aktualizacji opisuje [Aktualizacje i odzyskiwanie](/pl/docs/under-the-hood/updates-and-recovery/).

## Dlaczego obie warstwy mają znaczenie

Świeża instalacja przechodzi wyłącznie przez podpisywanie kodu, bo nowa instalacja nigdy nie dotyka updatera. Aktualizacja automatyczna przechodzi przez obie warstwy: updater sprawdza podpis, a Gatekeeper i tak weryfikuje nową aplikację przy kolejnym uruchomieniu. Ta różnica ma znaczenie dla tego, co da się zrobić skradzionym kluczem. Ktoś, kto ma tylko klucz podpisu Apple, wciąż może nakłonić nowych użytkowników do zainstalowania złośliwej wersji z podmienionego miejsca pobierania, bo przy pierwszej instalacji weryfikacja updatera w ogóle nie działa. Ktoś, kto ma tylko klucz podpisu aktualizacji, może wypchnąć złą aktualizację, ale wtedy nie przejdzie ona przez Gatekeeper i aplikacja padnie przy uruchomieniu, co czyni atak widocznym zamiast cichym. Traktuj klucz Apple Developer ID jako ten, który najbardziej opłaca się chronić: podpis aktualizacji to druga warstwa, a nie jego zamiennik.