¿Cómo se relaciona la informática teórica con la seguridad?

Cuando pienso en un software inseguro, creo que es "demasiado útil" y que un atacante puede abusar de él. Entonces, en cierto sentido, asegurar el software es el proceso de hacer que el software sea menos útil. En informática teórica no estás trabajando con el mundo real. Entonces, ¿hay problemas de seguridad al trabajar con teoría pura? O la otra cara de la moneda, ¿afecta la informática teórica al mundo real de las personas que son hackeadas? Si es así, ¿qué temas de seguridad se consideran teóricos?

Su intuición de que la "inseguridad" se debe a un software que es "demasiado útil" es correcta, en cierto sentido. Existe una amplia y creciente literatura teórica sobre "privacidad diferencial" que formaliza su intuición. Ver, por ejemplo, aquí: research.microsoft.com/en-us/projects/databaseprivacy/dwork.pdf

$\epsilon$$e^\epsilon$

Por supuesto, hacer que un algoritmo sea privado lo hace menos útil: un algoritmo diferencialmente privado produce salidas que ni siquiera son una función de las entradas. Pero resulta que puede intentar equilibrar cuidadosamente el equilibrio entre la privacidad y la utilidad, y puede obtener algoritmos muy privados que, sin embargo, no son trivialmente útiles.$0$

De muchas maneras:

• Criptografía (una generalización enormemente amplia de la seguridad de la información que abarca desde la privacidad hasta el cifrado)
• Verificación formal del código (ver también el proyecto seL4 )
• Tolerancia a fallos y corrección de errores
• Formas teóricas para prevenir el malware ( otro ), incluida la firma de código
• Hardware a prueba de manipulaciones
• Ofuscación puntual (un enfoque teórico de la información teóricamente segura para la ofuscación del código)
• El aprendizaje automático ayuda a prevenir y alertar los intentos de pirateo en tiempo real (piense en los Guardianes Activos y el Filtro de Spam ).
• Mucho mucho mas.

Considere el ejemplo de Privacidad equivalente por cable , que en realidad no existe: debido a descuidos teóricos vergonzosamente básicos (pdf), WEP se puede descifrar en minutos.

En "Por qué las computadoras son inseguras", bromeó Bruce Schneier

La ingeniería de seguridad implica programar la computadora de Satanás.

Y la computadora de Satanás es difícil de probar.

Hay mucha motivación en el mundo real para el estudio de algoritmos de transmisión que proviene de la detección de intrusiones en la red. El siguiente documento utiliza algoritmos de transmisión para la entropía empírica para detectar anomolias en el tráfico de su red.

Yu Gu, Andrew McCallum y Don Towsley. Detección de anomalías en el tráfico de red utilizando la estimación de entropía máxima. En IMC '05: Actas de la 5ª conferencia ACM SIGCOMM sobre medición de Internet, páginas 1–6, 2005

A diferencia de las otras respuestas, esto está más en la línea de "cosas de las que deberíamos preocuparnos cuando decimos que algo es 'demostrablemente seguro'" en comparación con los lugares donde se ha utilizado TCS en seguridad. Por lo tanto, aborda la primera cuestión de las preocupaciones de seguridad cuando se trabaja con la teoría.

Como dicen los hackers, los resultados teóricos suelen ser tangenciales para la seguridad del mundo real. Este tipo de argumento se ha hecho más teórico, científico y preciso por Alfred Menezes y Neal Koblitz en su serie de documentos ' Otra mirada ' (advertencia: el sitio me parece un poco conflictivo, pero creo que la idea básica de cuestionar suposiciones es muy importante). Señalan debilidades en los supuestos estándar de la criptografía, incluso en documentos seminales.

Algunos ejemplos (citando / parafraseando algunos puntos de su sitio):

1. Un teorema de seguridad es condicional: supone la intratabilidad de algún problema matemático.

2. A menudo, la suposición de intractabilidad se hace para un problema complicado y artificial: en algunos casos, el problema es trivialmente equivalente al problema de criptoanálisis para el protocolo cuya seguridad se está "probando".

3. A veces, una prueba tiene una gran brecha de estanqueidad, pero los tamaños de los parámetros todavía se recomiendan como si la prueba hubiera sido ajustada. En tales casos, la prueba generalmente proporciona un límite inferior inútil en el tiempo de ejecución de un ataque exitoso. Además, un resultado asintótico no necesariamente proporciona ninguna garantía de seguridad para los parámetros en el rango utilizado en la práctica.

4. Un teorema de seguridad utiliza un cierto modelo de seguridad. Ciertos ataques, especialmente los ataques de canal lateral, son muy difíciles de modelar, y los modelos que se han propuesto son lamentablemente inadecuados.

Los probadores de teoremas se han utilizado hasta cierto punto para demostrar la corrección del software, hardware y protocolos. Ver, por ejemplo, aquí o aquí .

El problema de los datos que fluyen de manera no deseada a través de programas (lo que causa una fuga potencial) se ha modelado teóricamente utilizando la noción de (no) interferencia; obtener punteros aquí .

La capacidad de decisión es una preocupación central en la investigación del lenguaje de programación. Es decir, se está invirtiendo mucho esfuerzo en construir lenguajes de programación que solo acepten código que satisfaga ciertas propiedades. Los lenguajes estáticos típicos solo ofrecen garantías débiles, como rechazar un programa si no existen ciertos métodos, pero imagínense si el lenguaje también podría arrojar programas que, por ejemplo, usan mutexes incorrectamente o intentan leer más allá del final de las regiones de memoria. Está claro que los problemas de capacidad de decisión llegan rápidamente (escenario más simple: especifique que su compilador solo debe aceptar programas de terminación), y ciertamente, existen problemas de eficiencia (el verificador de tipos de ML tiene casos doblemente exponenciales).

En cualquier caso, la comunidad de investigación de PL está muy interesada en la seguridad (¿confías en que tu navegador ejecute código extranjero arbitrario?), Y sus preguntas conducen a muchas preguntas clásicas de teoría CS.