Actualizando las aplicaciones de seguridad / privacidad [cerrado]

2

Digamos que tenemos un cliente de chat p2p de código abierto descentralizado destinado a la comunicación segura. El principal vector de ataque parece ser el mecanismo de actualización (centralizado). Qué métodos y / o técnicas se pueden usar para minimizar los ataques durante el proceso de actualización. Al final, un desarrollador malicioso siempre puede introducir un código malicioso, por lo que lo mejor que podemos hacer es minimizar esas posibilidades.

Algunos temas en los que he estado pensando simplemente para hacer rodar la pelota (pero no me siento obligado a responderlos o limitarme a ellos):

  • ¿Se deben utilizar las actualizaciones automáticas? ¿Y deberían aplicarse instantáneamente o vale la pena esperar un tiempo fijo que permita que se retire en el caso de un hackeo (debido al costo de los bugs de seguridad que están abiertos durante x días)?
  • ¿Basta con una conexión https simple (con certificado anclado) para evitar ataques MITM en el archivo de descarga o si se deben verificar otras cosas como una suma de comprobación descargada desde un servidor diferente?
  • ¿Se pueden tomar medidas contra, por ejemplo, que el gobierno (la única parte que puede hacerlo legalmente) tome el servidor y cargue una nueva versión? (Estaba pensando en algún tipo de sistema en el que el archivo debe estar alojado en diferentes jurisdicciones o algo así)
  • ¿Existen formas de requerir al menos n de m parties (desarrolladores) para firmar la nueva versión?
pregunta David Mulder 16.04.2015 - 19:47
fuente

1 respuesta

1

Sea cual sea su estrategia, creo que el primer paso es firmar sus parches. No importa la cantidad de MITM que haya, si los usuarios pueden verificar su firma de una forma en la que confían que ya proporcionará una gran cantidad de certeza.

HTTPS es bueno, pero realmente no hace tanto como la firma en su parche, HTTPS hará que MITM sea más difícil, pero no imposible.

Si abre actualizaciones automáticas (configurables, por supuesto), eso significa que también abre un vector de ataque. Dependiendo de su filosofía, puede elegir minimizar los vectores de ataque para aumentar la certeza, o puede sentir que obtener actualizaciones de seguridad en sus parches de forma amplia y rápida justifica el aumento de la complejidad.

También puede buscar formas de proporcionar sumas de comprobación fuera de banda, por ejemplo. en dominios externos o sobre SMS. MITM es mucho más difícil para su dominio y su número de módem que para MITM solo su dominio. Los usuarios que quieren certeza podrían usar estas sumas de comprobación para ver si el programa que están ejecutando es el correcto o si el parche que están aceptando es válido. Si alguna de las sumas de verificación no está de acuerdo con otra, es una señal de que algo sospechoso está sucediendo.

En cuanto a la protección de los parches dentro de su servidor, si está lo suficientemente lejos, realmente está tratando de protegerse contra las intrusiones "autorizadas" y desea que los usuarios puedan verificar esta protección. Esto es una cosa bastante difícil de hacer.

Si su proyecto es de código abierto, puede buscar construcciones deterministas, lo que Tor intenta hacer. De esta manera, un usuario puede inspeccionar el código (pero nadie lo hace) y comparar su compilación con la suya. Podría ser mucho trabajo y / o incompatible con su plataforma actual.

Si continúa utilizando múltiples llaves o servidores, podría terminar con el chin-deep en tolerancia de fallas bizantina , que usted y sus usuarios pueden encontrar un esfuerzo agradable, o puede resultarle difícil y tedioso trabajar con él.

Lo que sea que elijas hacer aquí, solo trata de hacerlo simple. Según la ley de AviD:

  

La seguridad a expensas de la usabilidad viene a expensas de la seguridad.

    
respondido por el Up Here 16.04.2015 - 21:38
fuente

Lea otras preguntas en las etiquetas