El problema que está describiendo aún no se ha resuelto por completo. Se condensa en gran medida a auditabilidad del software su método de distribución y diseño de protocolo .
Diseño de protocolo
Ya mencionó que el cifrado debe realizarse en el lado del cliente. Esto es ofrecido por un montón de software de hoy ya. Las compañías que venden un protocolo de encriptación del lado del cliente no pueden construir fácilmente su modelo de ingresos de la venta de datos del cliente sin que esto se haga público.
Auditabilidad del software
Incluso con un protocolo bien diseñado, es posible que el cliente no lo siga. Para verificar que el cliente hace lo que dice el protocolo, el software debe ser auditado por el público. Esto funciona más fácilmente cuando el software es accesible en un formato que los humanos pueden entender mejor: en el código fuente. Un software verificable no tiene que ser código abierto , o tener su código fuente disponible públicamente como Truecrypt, pero es un punto muy fuerte.
Cuando se ha auditado el código fuente, surge el problema confianza de confianza : alguien debe verificar que El binario coincide con el código fuente. Esto se puede resolver con compilaciones deterministas , que es un método nuevo y actualmente muy inestable.
Se ha utilizado para garantizar la integridad del software que se considera importante, como el Tor Browser Bundle o varios clientes de Bitcoin. Debian ha iniciado un esfuerzo para que todo el repositorio de aplicaciones se construya de manera determinista (último enlace).
La cantidad de software que debe verificarse puede reducirse siguiendo un modelo similar a DRM: una parte del software es de código cerrado y no es de confianza, y otra parte que realiza el cifrado es de código abierto y se audita. De extremo a extremo ( repositorio , artículo de blog ) en combinación con el cliente gmail js, o el addon publicado por Mega son un buen ejemplo para esto.
Esos enfoques hacen que sea difícil ocultar el cifrado de todos , pero es fácil ocultar el cifrado de one .
Método de distribución
Hay varias formas de distribuir software hoy. tiendas de aplicaciones como Google Play store o apt , la descarga HTTP habitual y, en la web , la solución HTTP / javascript.
El peor método es HTTP / js: cada vez que visita la página, básicamente descarga el software una vez más. El servidor puede proporcionarle un contenido malicioso, y la próxima vez que visite la página, se eliminarán todos los rastros. La mejor manera de proteger una página web es el método similar a DRM que he descrito anteriormente.
Las descargas HTTP también tienen muchos problemas. Confía en todos los proveedores de descargas que no le sirven software malicioso. Android tiene una casilla de verificación de "fuentes no confiables" que está desactivada de forma predeterminada para evitar que instale dicho software. También estoy incluyendo PPA en esto, sin embargo, no sé de cualquier contenido malicioso servido sobre PPAs. Mejor es que solo confíes en una entidad, a través de los repositorios de paquetes.
Incluso los repositorios de paquetes le brindan una entidad en la que tiene que confiar: el responsable del repositorio, ya sea google, debian o alguien más. El software puede ser auditable y usa un buen protocolo, pero la versión particular que le dio su mantenedor tiene una puerta trasera.
El problema es similar al problema de distribución de certificados: garantizar que todas las personas vean lo mismo, por lo que se aplican soluciones similares. Podría pensar en un protocolo de chismes como el descrito en en la wiki de extremo a extremo , o incluso más descentralizados como Namecoin , sin embargo, puede argumentar qué tan descentralizado es Namecoin, cuando el hashing se centraliza.
Para protegerlo del malvado habitual, en la actualidad basta con confiar en un confiable representante de repo, ya que la mayoría de las personas aún caen en la trampa de descarga de HTTP, y pueden hacer negocios allí.