Przejdź do zawartości

Security through obscurity

Z Wikipedii, wolnej encyklopedii

Security through obscurity lub security by obscurity (z ang. „bezpieczeństwo przez niejawność”) − przykład praktyk stosowanych w bezpieczeństwie teleinformatycznym, którego istotą jest ukrywanie detali dotyczących implementacji, formatów i protokołów przed potencjalnymi adwersarzami. Osoby stosujące tę technikę zakładają, że nawet jeśli system posiada luki, nieznajomość błędów utrudnia przeprowadzenie ataku. W środowiskach kryptograficznych i bezpieczeństwa security through obscurity jest powszechnie uważane za podejście błędne, które obniża, zamiast podwyższać, bezpieczeństwo systemu.

Przykłady

[edytuj | edytuj kod]

Oyster Card

[edytuj | edytuj kod]

Oyster Card to bezdotykowa karta elektroniczna w standardzie Mifare wydawana przez Transport for London – firmę zarządzającą londyńskim systemem transportu miejskiego. Grupa naukowców z Uniwersytetu w Nijmegen pokazała, że jej zabezpieczenie jest łatwe do przełamania[1]. Producent procesora – firma NXP Semiconductors – nazwał ujawnienie tej informacji „nieodpowiedzialnym” i wystąpił do sądu o wydanie zakazu publikacji[2], aby w ten sposób ochronić interesy swoich klientów. Wniosek ten został odrzucony, a The Guardian opublikował artykuł Bruce'a Schneiera sugerujący, że ujawnienie metody ataku przyniesie długofalowe korzyści dla bezpieczeństwa publicznego[3].

Fetchmail

[edytuj | edytuj kod]

Eric Raymond, w eseju The Cathedral and the Bazaar, opisał security by obscurity na przykładzie jednego z programów swojego autorstwa. Fetchmail jest narzędziem, które automatyzuje proces pobierania poczty elektronicznej ze zdalnych serwerów POP3 lub IMAP. Dane konta pocztowego podane są w pliku konfiguracyjnym. Użytkownicy programu wielokrotnie prosili o dodanie możliwości szyfrowania hasła, aby osoba mająca dostęp do pliku konfiguracyjnego nie mogła odczytać hasła. Eric argumentował, że właściwą metodą ochrony hasła jest uniemożliwienie dostępu do pliku konfiguracyjnego (poprzez odebranie prawa do odczytu pozostałym użytkownikom) i odmówił implementacji złudnego zabezpieczenia[4].

Krytyka

[edytuj | edytuj kod]

Najczęściej stosowanym argumentem krytyków security through obscurity jest (sformułowana w 1883) zasada Kerckhoffsa. Mówi ona, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy wszystkie szczegóły jego działania – oprócz klucza – są znane. Na tę zasadę powołał się Ross Anderson w podręczniku Security Engineering, dyskutując kwestię otwartości w systemie zarządzania nuklearnego:

Korzyści wynikające z redukcji zagrożenia przypadkowej wojny przeważyły potencjalne korzyści wynikające z utrzymania tajemnicy. Jest to nowoczesna reinkarnacja doktryny Kerckhoffsa sformułowanej w XIX wieku, wymagającej aby bezpieczeństwo systemu zależało od klucza, a nie od niejawności konstrukcji systemu.

Ross Anderson, Security Engineering

Claude Shannon sparafrazował tę zasadę jako „wróg zna system”, a Bruce Schneier we wstępie do swojego podręcznika Applied Cryptography stawia pojęcie niejawności w opozycji do bezpieczeństwa:

Jeśli wezmę list, zamknę go w sejfie, ukryję sejf gdzieś w Nowym Jorku i każę ci go przeczytać, to nie jest bezpieczeństwo. To niejawność. Z drugiej strony, jeśli wezmę list, zamknę go w sejfie, a następnie przekażę ci ten sejf wraz z jego specyfikacją techniczną oraz setką identycznych sejfów z ich kodami, abyś razem z najlepszymi włamywaczami świata mógł przestudiować jego zabezpieczenia – a Ty nadal nie będziesz go mógł otworzyć i przeczytać listu – to właśnie jest bezpieczeństwo.

Bruce Schneier, Applied Cryptography

Kontrargumenty

[edytuj | edytuj kod]

Choć poleganie wyłącznie na niejawności nie gwarantuje bezpieczeństwa, utrzymanie konstrukcji systemu w tajemnicy może być rozsądną taktyką realizującą jedną z warstw strategii wielopoziomowych zabezpieczeń (z ang. defense in depth) i może zmniejszyć groźbę wykorzystania luk systemu.

Taktyka niejawności może również służyć do stworzenia pułapki (honeypot), który przyciągnie uwagę atakującego do nieistotnych części systemu oraz umożliwi poznanie taktyki i strategii ataków.

Zobacz też

[edytuj | edytuj kod]

Przypisy

[edytuj | edytuj kod]