Jak informatyka teoretyczna odnosi się do bezpieczeństwa?

Kiedy myślę o oprogramowaniu, które nie jest bezpieczne, myślę, że jest ono „zbyt przydatne” i może zostać wykorzystane przez napastnika. W pewnym sensie zabezpieczenie oprogramowania to proces zmniejszania jego użyteczności. W informatyce teoretycznej nie pracujesz w prawdziwym świecie. Czy są jakieś obawy związane z bezpieczeństwem podczas pracy z czystą teorią? A może po drugiej stronie medalu, czy teoretyczna informatyka wpływa na rzeczywisty świat hakerów? Jeśli tak, jakie tematy dotyczące bezpieczeństwa są uważane za teoretyczne?

Twoja intuicja, że ​​„brak bezpieczeństwa” wynika z oprogramowania, które jest „zbyt przydatne”, jest w pewnym sensie słuszna. Istnieje duża i rosnąca literatura teoretyczna na temat „zróżnicowanej prywatności”, która formalizuje twoją intuicję. Zobacz na przykład tutaj: research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

$\epsilon$$e^\epsilon$

$0$

Na wiele sposobów:

• Kryptografia (niezwykle szerokie uogólnienie bezpieczeństwa informacji, od prywatności po szyfrowanie)
• Formalna weryfikacja kodu (patrz także projekt seL4 )
• Tolerancja błędów i korekcja błędów
• Teoretyczne sposoby zapobiegania złośliwemu oprogramowaniu ( inne ), w tym podpisywanie kodu
• Sprzęt odporny na manipulacje
• Punktowe zaciemnianie (teoretyczne podejście do teoretycznie bezpiecznego ukrywania kodu)
• Uczenie maszynowe pomaga zapobiegać próbom włamań i ostrzegać o nich w czasie rzeczywistym (pomyśl o Aktywnych strażnikach i filtrowaniu spamu ).
• O wiele wiele więcej.

Rozważ przykład Wired Equivalent Privacy , który w rzeczywistości nie jest czymś takim: ze względu na zawstydzająco podstawowy nadzór teoretyczny (pdf), WEP można złamać w ciągu kilku minut.

W „Dlaczego komputery są niebezpieczne” - żartuje Bruce Schneier

Inżynieria bezpieczeństwa obejmuje programowanie komputera szatana.

A komputer szatana jest trudny do przetestowania.

Istnieje wiele rzeczywistych motywacji do badania algorytmów przesyłania strumieniowego, które pochodzą z wykrywania włamań do sieci. Poniższy artykuł wykorzystuje algorytmy strumieniowe dla empirycznej entropii do wykrywania anomolii w ruchu sieciowym.

Yu Gu, Andrew McCallum i Don Towsley. Wykrywanie anomalii w ruchu sieciowym przy użyciu oszacowania maksymalnej entropii. W IMC '05: Materiały z 5. konferencji ACM SIGCOMM nt. Pomiarów internetowych, strony 1–6, 2005

W przeciwieństwie do innych odpowiedzi, jest to bardziej zgodne z „rzeczami, o które powinniśmy się martwić, mówiąc, że coś jest„ możliwe do udowodnienia ””, w przeciwieństwie do miejsc, w których TCS był używany w bezpieczeństwie. W ten sposób rozwiązuje pierwsze pytanie dotyczące bezpieczeństwa podczas pracy z teorią.

Jak mówią hakerzy, teoretyczne wyniki są często styczne do rzeczywistego bezpieczeństwa. Ten rodzaj argumentacji został bardziej teoretyczny, naukowy i precyzyjny przez Alfreda Menezesa i Neala Koblicza w serii artykułów „ Another Look ” (ostrzeżenie: strona wydaje mi się trochę konfrontacyjna, ale myślę, że podstawowa idea kwestionowania założeń to bardzo ważne). Wskazują na słabości standardowych założeń w kryptografii, nawet w najważniejszych artykułach.

Kilka przykładów (cytowanie / parafrazowanie kilku punktów z ich strony):

1. Twierdzenie o bezpieczeństwie jest warunkowe - zakłada trudność jakiegoś problemu matematycznego.

2. Często zakłada się trudność w przypadku skomplikowanego i wymyślonego problemu: w niektórych przypadkach problem jest trywialnie równoważny z problemem kryptoanalizy dla protokołu, którego bezpieczeństwo jest „sprawdzane”.

3. Czasami dowód ma dużą lukę szczelności, ale rozmiary parametrów są nadal zalecane, jakby dowód był szczelny. W takich przypadkach dowód zwykle określa bezużyteczną dolną granicę czasu trwania udanego ataku. Ponadto wynik asymptotyczny niekoniecznie zapewnia jakiekolwiek bezpieczeństwo parametrów w zakresie stosowanym w praktyce.

4. Twierdzenie o bezpieczeństwie wykorzystuje pewien model bezpieczeństwa. Niektóre ataki - szczególnie ataki z boku kanału - są bardzo trudne do modelowania, a zaproponowane modele są żałośnie nieodpowiednie.

Dowody twierdzeń zostały w pewnym stopniu wykorzystane do udowodnienia poprawności oprogramowania, sprzętu i protokołów. Zobacz na przykład tutaj lub tutaj .

Problem przepływu danych w niepożądany sposób przez programy (powodując w ten sposób potencjalny wyciek) został teoretycznie modelowany przy użyciu pojęcia (nie) zakłóceń; zdobądź wskazówki tutaj .

Zdolność rozstrzygania stanowi główny problem w badaniach nad językiem programowania. Oznacza to, że włożono wiele wysiłku w budowę języków programowania, które akceptują tylko kod spełniający określone właściwości. Typowe języki statyczne dają słabe gwarancje, takie jak odrzucenie programu, jeśli pewne metody nie istnieją, ale wyobraź sobie, że język może również wyrzucać programy, które na przykład niewłaściwie używają muteksów lub próbują czytać poza końcem obszarów pamięci. Oczywiste jest, że problemy rozstrzygalności pojawiają się szybko (najprostszy scenariusz: określ, że twój kompilator powinien akceptować tylko programy kończące), a na pewno istnieją obawy dotyczące wydajności (moduł sprawdzania typu ML ma przypadki podwójnie wykładnicze).

W każdym razie społeczność badawcza PL bardzo interesuje się bezpieczeństwem (czy ufasz przeglądarce, że uruchamia dowolny obcy kod ?!), a ich pytania prowadzą do wielu klasycznych pytań z teorii CS.