Jak informatyka teoretyczna odnosi się do bezpieczeństwa?

11

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?

Wieżowiec
źródło
9
Perspektywa przedstawionej teorii CS jest subiektywna i bardzo dyskusyjna, a także nie jest wymagana do postawienia pytania. Wydaje się, że pytanie koncentruje się w szczególności na hakowaniu, które jest obszernym tematem samym w sobie (od technik inżynierii społecznej) i nie zbliża się do tego, co oznacza „bycie bezpiecznym”. Z tych powodów przegłosowałem. Jednak wydaje mi się, że pytanie pochodzi z dobrego miejsca i ma kilka interesujących aspektów, więc odpowiedziałem poniżej.
Ross Snider

Odpowiedzi:

20

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

ϵeϵ

0

Aaron Roth
źródło
14

Na wiele sposobów:

Ross Snider
źródło
Szczerze mówiąc, nie sądzę, abyś kiedykolwiek odkrył lukę, załatał jeden fragment kodu, a nawet nie widział wewnętrznego działania tej luki w świecie rzeczywistym.
Wieżowiec
8
Za pomocą OllyDbg załatałem bibliotekę dll gdi, aby naprawić (drugą) lukę kursora (oczywiście bez kodu źródłowego) przed poprawką Microsoftu we wtorek. Ponownie używając OllyDbg załatałem emulator zamkniętego źródła, aby był oszustem (zawstydzająco) dla konkurencji Pokemon. Znalazłem 0day w projekcie kamery internetowej i uzyskałem dość wysokie wyniki w dużej liczbie gier wojennych (w tym Blacksun, w których włączono ASLR i PaX). Nie wspomnę o niektórych bardziej nikczemnych rzeczach, które zrobiłem… Wzruszenie; Dlaczego miałoby to mieć znaczenie, gdybym miał czy nie? Proszę, nie płomień.
Ross Snider
13
@ The Rook: Jeśli uważasz, że lista Rossa ma niewielki związek z faktyczną praktyką bezpieczeństwa oprogramowania, powiedz tak. Może nawet podanie kilku przykładów byłoby pomocne lub dodanie odpowiedzi na temat tego, jak daleko badania bezpieczeństwa TCS od rzeczywistej praktyki bezpieczeństwa (które moim zdaniem byłyby bardzo interesujące do przeczytania). Ale nie ma potrzeby poniżania Rossa.
Joshua Grochow
10

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

Joshua Brody
źródło
8

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.

Artem Kaznatcheev
źródło
6

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 .

Raphael
źródło
3

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.

matus
źródło
Jakikolwiek właściwy język wysokiego poziomu (czytaj: inny niż C [++]) nie daje programiście kontroli nad dostępem do pamięci, więc uważam ten problem za rozwiązany.
Raphael
@Raphael: Biorąc pod uwagę, że znaczna część oprogramowania jest nadal napisana w C i C ++, tego problemu nie można po prostu uznać za rozwiązany. Ponadto, na przykład, techniki radzenia sobie z atakami polegającymi na wstrzykiwaniu kodu w Javascript są wciąż w powijakach. Jest wiele do zrobienia.
Dave Clarke
1
Fakt, że niektóre środowiska ignorują istniejące rozwiązania (czasami z dobrych powodów), nie sprawia, że ​​problem (tutaj: dostęp do zabronionych adresów pamięci) jest mniej rozwiązany. Niektóre rzeczy, które trudno sprawdzić, można łatwo obejść za pomocą odpowiednich niezmienników. Możesz na przykład zażądać od programisty formalnego dowodu wypowiedzenia (por. Isabelle / HOL).
Raphael