¿Cómo se garantiza la seguridad informática distribuida?

Obtener resultados falsos o sesgados del poder de la CPU aportado por el usuario es un problema real que no tiene una solución práctica conocida, pero hay varias estrategias de mitigación:

• Duplicación . Por cada trozo de trabajo dado, entréguelo a dos contribuyentes distintos y compare los resultados. Esto atrapará a la mayoría de los estafadores y también a los errores informáticos debido a una mala memoria RAM; desafortunadamente, esto también reduce a la mitad la potencia de cálculo disponible. Esta estrategia fue la utilizada por algunos de mis amigos que (brevemente) obtuvieron el récord mundial para el problema de las reinas N (es decir, contando todas las soluciones; lo calcularon para N = 23 en el siglo anterior).

• Muestreo . Esta es una variante de la solución anterior, en la que solo duplica algunos , por ejemplo. Uno de cada diez (elegido al azar). Esto atrapará a los estafadores que obtienen resultados del juego al menos ocasionalmente, mientras incurren en mucho menos gastos generales. Debe realizar un seguimiento de quién hizo qué parte, para que los valores sospechosos puedan eliminarse en masa .

• Incentivos . Si el trabajo se basa en la persuasión de encontrar una aguja en el pajar (como un esfuerzo de descifrado de claves distribuido), entonces puede anunciar un gran premio para quien lo encuentre. Esto inducirá a muchos tramposos a realizar los cálculos, ya que no hacerlos significa que no obtendrán el premio.

• Cifrado totalmente homomorfo . Esa es una solución genérica, pero el algoritmo más conocido para FHE tiene el inconveniente inconveniente de incurrir en una sobrecarga que se cuenta en miles de millones, es decir, incluso si toda Internet contribuyó al cómputo con FHE, no coincidiría con lo que podría lograr sin FHE en una sola PC.

• Oscuridad . El favorito de todos los tiempos de las estrategias contra el engaño: simplemente no muestres la fuente, mantén los protocolos en secreto y espera que nadie se moleste en ejecutar un depurador y hacer un poco de ingeniería inversa. En un escenario similar de computación distribuida, es decir, juegos en línea, no funciona bien .

• Suerte y confianza . Simplemente ore para que no haya demasiados estafadores y que la mayoría se procesen como deberían. Dependiendo del tipo de cálculo, esta puede ser una estrategia válida. Por ejemplo, puede funcionar para un esfuerzo de craqueo de claves, ya que algunos fragmentos omitidos no importarán (a menos que la clave esté en uno de ellos, lo que sería mala suerte pero improbable si la mayoría de los contribuyentes son honestos). No funcionaría para un conteo completo donde se agregan todos los resultados (cada valor incorrecto alterará el total).

Históricamente, distribuido.net encontró estos problemas en sus esfuerzos de craqueo DES / RC5. Algunas personas falsificarían los resultados, es decir, alterarían a sus clientes para que respondieran "trabajo hecho, no se encontró ninguna clave" sin hacer los cálculos ; Los clientes de juegos responderían más rápido que los clientes que realmente hacen el trabajo. Lo estaban haciendo solo para estar en una mejor posición en la lista de contribuyentes, ordenados por el poder de la CPU (retrospectivamente, era bastante obvio que el propietario de la computadora actuaría como lo hacen los propietarios de automóviles). Su respuesta fue un cliente oscuro sin fuente, que fue suficiente en ese caso (muy pocas personas hicieron ingeniería inversa para hacer trampa nuevamente).

También existe el problema dual , es decir, ¿cómo se asegura, como colaborador , de que el código de cliente que le envían es realmente benigno? Esta no es una pregunta fácil, y se hace más difícil con el código de cliente de código cerrado ...

Linux incluye una ingeniosa llamada al sistema llamada seccomp () que podría ser útil para eso. Y, al menos en teoría, este podría no ser suficiente para un aislamiento completo de un proceso potencialmente deshonesto, porque ese proceso compartirá cachés (caché L1, predicción de saltos ...) con otros procesos, y se ha demostrado que es utilizable ( en condiciones de laboratorio ) para recuperar un cifrado llave.

El software espía es fácil, la garantía de que los datos que regresan siguen un cierto formato y no ejecutan ninguna parte. No es diferente a cargar archivos JPG en GMail o Tumblr: lo que subas no se ejecutará de ninguna manera, por lo que está bien.

Con respecto a "falsificar los datos":

Por un lado, generalmente envían la misma información a más de un usuario. En segundo lugar, los indicios de un "evento interesante" obviamente serán revisados por un humano. Por supuesto, si "ocultas" tus hallazgos, no hay mucho que se pueda hacer, excepto verificar tu envío con otra persona.

Su sitio web actualmente no funciona, pero encontré esto en una copia de las preguntas frecuentes de SETI @ HOME :

  

¿Qué pasa si alguien falsifica un resultado para hacer que parezca que encontraron un   señal?

     

El personal de SETI @ home revisará los datos reales que produjeron el resultado y, si no encuentran los mismos resultados, descartarán la falsificación. Además, aunque no es imposible, podría ser más difícil de lo que piensas falsificar un archivo de resultados.

     

Dado que algunas unidades de trabajo se envían más de una vez, SETI @ home puede detectar errores comparando los resultados. Durante el tiempo del proyecto, el cielo será escaneado varias veces. Es muy poco probable que un tramposo obtenga una unidad de trabajo del mismo lugar en el cielo más de una vez.

Una buena lectura de esto sería este pdf ^{( doi )} , lo que explica una buena manera en que los sistemas pueden protegerse de los usuarios falsificando datos.

  

En este documento, primero proponemos un esquema llamado Prueba para combatir la colusión. La idea básica de Quiz es insertar tareas de prueba indistinguibles   con resultados verificables conocidos por el cliente dentro de un paquete que contiene   Varias tareas normales. El cliente puede entonces aceptar o rechazar lo normal.   Resultados de tareas basados en la corrección de los resultados de las pruebas.