Como a Ciência da Computação Teórica se relaciona com a segurança?


11

Quando penso em software inseguro, acho que é "muito útil" e pode ser abusado por um invasor. Portanto, de certa forma, proteger software é o processo de tornar o software menos útil. Em Ciência da Computação Teórica, você não está trabalhando com o mundo real. Então, existem preocupações de segurança ao trabalhar com a teoria pura? Ou o outro lado da moeda, a Ciência da Computação Teórica afeta o mundo real das pessoas que são hackeadas? Em caso afirmativo, quais tópicos de segurança são considerados teóricos?


9
A perspectiva da Teoria de CS apresentada é subjetiva e muito discutível e também não é necessária para colocar a questão. A questão parece se concentrar especificamente no hacking, que é um assunto amplo em si mesmo (variando de técnicas de engenharia social) e não chega nem perto do que implica "estar seguro". Por essas razões, eu votei mal. No entanto, acho que a pergunta vem de um bom lugar e tem alguns aspectos interessantes, então respondi abaixo.
Ross Snider

Respostas:


20

Sua intuição de que "insegurança" é devida a software "muito útil" está correta, em certo sentido. Existe uma literatura teórica ampla e crescente sobre "privacidade diferencial" que formaliza sua intuição. Veja, por exemplo, aqui: research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

ϵeϵ

0


14

De várias maneiras:


Sinceramente, não acredito que você já tenha encontrado uma vulnerabilidade, corrigido um único pedaço de código ou tenha visto o funcionamento interno de uma vulnerabilidade no mundo real.
The Rook

8
Usando o OllyDbg, corrigi minha dll gdi para corrigir a (segunda) vulnerabilidade do cursor (obviamente sem código fonte) antes do patch da Microsoft na terça-feira. Novamente, usando o OllyDbg, eu remendei um emulador de código fechado para torná-lo à prova de trapaça (embaraçosamente) para uma competição de Pokémon. Encontrei um dia 0 em um projeto de webcam e obtive uma pontuação razoavelmente alta em um grande número de jogos de guerra (incluindo o Blacksun, que possui ASLR e PaX habilitado). Não vou mencionar algumas das coisas mais nefastas que já fiz ... Encolher de ombros; Por que importaria se eu tinha ou não? Por favor não chamas.
Ross Snider

13
@ The Rook: Se você acredita que a lista de Ross tem pouca conexão com a prática real de segurança de software, diga-o. Talvez até dar alguns exemplos seja útil, ou adicionar uma resposta própria detalhando o quão distante a pesquisa de segurança do TCS está da prática real de segurança (que eu acho que seria muito interessante de ler). Mas não há necessidade de humilhar Ross.
Joshua Grochow



8

Diferentemente das outras respostas, isso é mais parecido com "coisas com as quais devemos nos preocupar ao dizer que algo é 'comprovadamente seguro'", em oposição a lugares onde o TCS foi usado em segurança. Assim, ele aborda a primeira questão de preocupações de segurança ao trabalhar com a teoria.

Como dizem os hackers, os resultados teóricos costumam ser tangenciais à segurança do mundo real. Esse tipo de argumento foi tornado mais teórico, científico e preciso por Alfred Menezes e Neal Koblitz em sua série de artigos ' Another Look ' (aviso: o site parece um pouco conflituoso para mim, mas acho que a idéia básica de questionar suposições) é muito importante). Eles apontam fraquezas em suposições padrão em criptografia, mesmo em artigos seminais.

Alguns exemplos (citando / parafraseando alguns pontos do site):

  1. Um teorema da segurança é condicional - assume a intratabilidade de algum problema matemático.

  2. Freqüentemente, a suposição de intratabilidade é feita para um problema complicado e artificial: em alguns casos, o problema é trivialmente equivalente ao problema de análise de criptografia do protocolo cuja segurança está sendo "comprovada".

  3. Às vezes, uma prova tem uma grande lacuna de estanqueidade, mas os tamanhos dos parâmetros ainda são recomendados como se a prova tivesse sido estanque. Nesses casos, a prova geralmente fornece um limite inferior inútil no tempo de execução de um ataque bem-sucedido. Além disso, um resultado assintótico não fornece necessariamente nenhuma garantia de segurança para parâmetros no intervalo usado na prática.

  4. Um teorema de segurança usa um certo modelo de segurança. Certos ataques - especialmente ataques de canal lateral - são muito difíceis de modelar, e os modelos propostos são lamentavelmente inadequados.


6

Os provadores de teoremas foram utilizados até certo ponto para comprovar a correção de software, hardware e protocolos. Veja, por exemplo, aqui ou aqui .

O problema dos dados fluindo de formas indesejadas através de programas (causando um possível vazamento) foi modelado teoricamente usando a noção de (não) interferência; obtenha dicas aqui .


3

A decidibilidade é uma preocupação central na pesquisa em linguagem de programação. Ou seja, muito esforço está sendo investido na construção de linguagens de programação que aceitam apenas códigos que satisfazem certas propriedades. Linguagens estáticas típicas apenas fornecem garantias fracas, como rejeitar um programa se certos métodos não existirem, mas imagine se a linguagem também pudesse jogar fora programas que, por exemplo, usam indevidamente mutexes ou tentam ler além do fim das regiões de memória. É claro que os problemas de decisão ocorrem rapidamente (cenário mais simples: especifique que seu compilador deve aceitar apenas programas de encerramento) e, certamente, há preocupações de eficiência (o verificador de tipo ML tem casos duplamente exponenciais).

De qualquer forma, a comunidade de pesquisa do PL está muito interessada em segurança (você confia que seu navegador executa código estrangeiro arbitrário ?!), e suas perguntas levam a muitas questões clássicas da teoria do CS.


Qualquer linguagem adequada de alto nível (leia-se: diferente de C [++]) não fornece ao programador controle sobre o acesso à memória; portanto, eu consideraria esse problema resolvido.
Raphael

@ Rafael: Dado que uma grande quantidade de software ainda está escrita em C e C ++, esse problema não pode ser simplesmente considerado resolvido. Além disso, as técnicas para lidar com ataques de injeção de código no Javascript, por exemplo, ainda estão engatinhando. Há muito a ser feito.
Dave Clarke

1
O fato de certos ambientes ignorarem as soluções existentes (às vezes por boas razões) não torna o problema (aqui: acessar endereços de memória proibidos) menos resolvido. Algumas coisas difíceis de verificar podem ser facilmente contornadas por invariantes apropriados. Você pode, por exemplo, exigir prova formal de encerramento do seu programador (cf Isabelle / HOL).
Raphael
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.