Czy otwarty kod jest bezpieczniejszy

„Jeśli nikt nie widzi, jak to działa, nikt tego nie złamie". Słyszałem wersje tego zdania od ludzi sprzedających produkty bezpieczeństwa i przeżywa ono, bo brzmi jak zdrowy rozsądek. Jest też tą jedną myślą, na której burzenie ostatnie dwadzieścia lat badań nad bezpieczeństwem wydało większość energii, a warto to burzenie rozumieć, bo rozumowanie przenosi się daleko poza oprogramowanie.

Zasada, którą to narusza, jest starsza niż komputery

W dziewiętnastym wieku holenderski kryptograf sformułował regułę o szyfrach wojskowych, która broni się do dziś: system powinien pozostać bezpieczny nawet wtedy, gdy wszystko poza kluczem jest publicznie znane.

Uzasadnienie jest praktyczne, a nie filozoficzne. Sekrety o tym, jak system działa, zna wiele osób, są spisane w dokumentacji, wbudowane w urządzenia, które można przejąć, i znane byłym pracownikom. Te sekrety wyciekają, w końcu, zawsze. Klucz da się zmienić w jedno popołudnie; projektu nie. Budujesz więc bezpieczeństwo na rzeczy wymienialnej, a nie na niewymienialnej.

Dlatego każdy standard szyfrowania używany przez banki, rządy i Twój telefon jest publiczny. Algorytmy są opublikowane, analizowane przez wrogich ekspertów przez lata i standaryzowane dopiero po przeżyciu tego. Nikt nie trzyma projektu w tajemnicy, bo projekt, który musi pozostać tajny, żeby działać, już powiedział Ci, gdzie ma słabość.

Co dowody naprawdę mówią o otwartym kodzie

Tu rozstaję się z entuzjastyczną wersją tego argumentu, bo zapis nie wspiera mocniejszego twierdzenia.

W 2014 roku luka w otwartej bibliotece szyfrującej wystawiła sporą część serwerów internetu na dwa lata, zanim ktokolwiek zauważył. Kod był przez cały ten czas publiczny. „Przy dostatecznej liczbie oczu wszystkie błędy są płytkie" okazało się dość mocno zależeć od tego, żeby te oczy faktycznie tam były, a w tamtym przypadku ich nie było — komponent był krytyczną infrastrukturą utrzymywaną przez bardzo niewielu ludzi.

Otwartość nie produkuje więc automatycznie kontroli. Kto twierdzi inaczej, argumentuje hasłem, a nie tym, co się wydarzyło.

Ale zobacz, co stało się potem, bo to jest część, którą hasło trafia z niewłaściwego powodu. Lukę znaleźli zewnętrzni badacze, opublikowano ją w całości, przeanalizowano publicznie w ciągu godzin i załatano globalnie w kilka dni. Każdy administrator mógł ustalić, czy go dotyczy, czytając kod. A incydent wyprodukował trwałą zmianę strukturalną: programy finansowania krytycznej infrastruktury, formalne audyty komponentów, od których zależą wszyscy, cały ten aparat, który istnieje dziś, bo tamta porażka była na tyle widoczna, żeby zawstydzić branżę do jego zbudowania.

Porównanie, które naprawdę ma znaczenie

Nie „które ma mniej błędów" — oba mają mnóstwo, a liczby nie są porównywalne, bo jedno publikuje, a drugie nie. Użyteczne porównanie dotyczy tego, co dzieje się między istnieniem błędu a jego naprawą.

W otwartym kodzie: każdy może go znaleźć, każdy może zweryfikować poprawkę, każdy może sprawdzić, czy jego system jest dotknięty, a cała sekwencja dzieje się publicznie, w harmonogramie, którego nikt nie kontroluje.

W zamkniętym kodzie: dostawca go znajduje albo zgłasza mu go ktoś z zewnątrz, dostawca decyduje o wadze, dostawca decyduje, kiedy naprawić, dostawca decyduje, co Ci powiedzieć i kiedy. To są cztery decyzje podejmowane przez stronę, do której interesów należy niewypadanie źle. Często zachowują się porządnie. Rzecz w tym, że na tym polegasz.

Jest też asymetria, którą ludzie pomijają. Ukrywanie nie zatrzymuje napastnika, tylko go spowalnia — i spowalnia tych niewłaściwych. Poważny przeciwnik rozkłada produkt na części, co jest standardową praktyką i całkowicie wykonalne. Ukrywanie zapobiega faktycznie badaniu przez badaczy, klientów i konkurencję: przez tych, którzy by Ci powiedzieli. To filtr blokujący Twoich sojuszników skuteczniej niż przeciwników.

Gdzie ukrywanie ma zastosowanie

Zastrzeżenie, bo absolutna wersja tego stanowiska też jest błędna.

Nierozgłaszanie zbędnych szczegółów jest rozsądne. Nie publikuj układu swojej sieci wewnętrznej, nie wypisuj wersji oprogramowania na publicznej stronie, nie ułatwiaj opisania celu bardziej, niż musisz. To jest higiena i warto ją stosować.

Błędem jest traktowanie higieny jako obrony. Przeniesienie usługi na nietypowy port zmniejsza szum w logach; nie chroni przed niczym, bo przeskanowanie wszystkich portów zajmuje sekundy. Test jest prosty i wart zastosowania do każdego środka bezpieczeństwa: gdyby napastnik poznał ten szczegół, czy nadal byłbym bezpieczny? Jeśli tak, to higiena i możesz ją zachować. Jeśli nie, to nigdy nie było bezpieczeństwo — to był sekret, a sekrety mają termin przydatności.

Co sprowadza rzecz z powrotem do punktu wyjścia. Buduj na rzeczach, które przeżywają bycie znanymi. Dlatego szyfrowanie jest publiczne, dlatego wolę oprogramowanie, którego kod może przeczytać mój klient, i dlatego uczciwą odpowiedzią na „skąd mam wiedzieć, że to bezpieczne" nigdy nie jest „bo nie widzi pan, co jest w środku".