Comunicación segura entre dos aplicaciones en el mismo sistema

8

Estoy escribiendo un software que se divide en dos piezas independientes separadas. Una es una aplicación similar a un servicio que maneja todas las lógicas, la otra es una aplicación GUI que solo funciona como front-end y está destinada a ser utilizada por el usuario final. El servicio escucharía un puerto y aceptaría solicitudes de la aplicación de cliente (GUI).

Dado que se intercambia cierta información confidencial entre el servicio y las aplicaciones de la GUI, es necesario cifrarlas antes de transferirlas. Una forma de proteger los datos es usar un cifrado basado en clave, pero las claves deben almacenarse en algún lugar del disco o incluso en el código fuente de la aplicación, pero prefieren evitar el uso de claves.

¿Cómo puedo manejar una conexión segura entre el servicio y la aplicación GUI sin usar un algoritmo de cifrado basado en clave?

    
pregunta sepisoad 27.02.2015 - 09:01
fuente

3 respuestas

13

Estos son la regla de oro de la seguridad de la computadora: "Es imposible ocultar algo a un usuario competente con privilegios de administrador del sistema" y "cualquier usuario competente con acceso físico al dispositivo siempre puede elevarse al administrador del sistema".

No puede ocultar ninguna información de alguien con control físico de la máquina. Si el secreto que intenta ocultar es realmente importante, nunca debe transferir los datos a la máquina y realizar el procesamiento en otro lugar en un lugar que controle.

Su programa se está ejecutando en la máquina de un usuario. No puedes proteger tus datos del usuario. Con eso en mente, ¿significa esto que estamos condenados? No necesariamente. El sistema operativo proporciona una gran cantidad de mecanismos para que los programas se comuniquen de forma privada con otro programa que no permita que otra aplicación sin privilegios lo intercepte. Por lo tanto, si bien no puede proteger los datos del propio usuario, puede proteger sus datos de otro programa sin privilegios. Proporcionar límites de seguridad entre programas no privilegiados es uno de los trabajos principales de los sistemas operativos.

Lo más simple de esto es una canalización anónima. Una tubería permite que un flujo de datos unidireccional se transporte entre programas. La canalización anónima está disponible en Windows, Linux, OSX y todos los sistemas similares a Unix. Canalización anónima más comúnmente reconocida como un par de canalización llamada stdin y stdout que permite que un proceso principal envíe y reciba un flujo de datos hacia y desde sus hijos. La canalización anónima solo se puede utilizar entre procesos que tienen una relación padre e hijo. También hay una canalización con nombre, pero se comportan de manera diferente en Windows y en sistemas similares a Linux / Unix, volveremos a esto más adelante.

Otro IPC que está disponible comúnmente es sockets. Sockets es como un tubo bidireccional. Hay muchas tomas diferentes, pero funcionan de manera similar. El más conocido es el socket TCP. El socket TCP está destinado principalmente para la conexión en red entre máquinas, pero también puede crear un socket TCP de bucle invertido que solo se puede utilizar dentro de la misma máquina. Un socket de bucle de retorno proporciona privacidad (solo el programa que se conecta y el programa que escucha pueden leer los datos que pasan a través del socket), sin embargo, en realidad no proporciona un mecanismo para restringir quién puede estar al otro lado del socket.

Otro tipo de socket disponible en Unix para la comunicación entre procesos en la misma máquina es Unix Domain Socket. Un socket de dominio Unix se expone a los programas como un "archivo especial" en el sistema de archivos, y el permiso del sistema de archivos unix se usa para controlar el acceso al socket. No se puede conectar un socket de dominio mediante programas que no tengan el permiso de acceso correcto para acceder al archivo socket. En sistemas similares a Unix, esto significa que su servicio y GUI deben ejecutarse como el mismo usuario y / o grupo que están reservados solo para su programa y usted establece el permiso del archivo de socket de manera apropiada.

Volvamos a la tubería con nombre. En sistemas similares a Linux / Unix, una canalización con nombre es muy parecida a stdin / stdout en que son unidireccionales. Sin embargo, en Windows, una canalización con nombre es en realidad bidireccional y es más o menos el equivalente del socket de dominio Unix en Windows. Como muchas otras cosas en Windows, la canalización con nombre está protegida con ACL.

Con iOS las cosas se vuelven un poco peludas. Un iOS sin jailbreak solo permite un muy conjunto limitado de comunicación entre procesos, y ninguno le dará un socket. Pero si jugamos con la definición, en la aplicación iOS, el programa de servicio y el programa GUI probablemente será la misma aplicación y, por lo tanto, simplemente puede crear una secuencia directamente entre los diferentes componentes de la aplicación. Esto también es seguro ya que solo se puede acceder a la transmisión dentro de la aplicación.

Android ofrece más opciones para IPC, incluida la capacidad de crear socket de dominio. La API es diferente pero son conceptualmente similares con Linux regular. De forma alternativa, puede utilizar el mismo enfoque que en iOS y empaquetar su servicio y su GUI en la misma aplicación y solo usar las secuencias en proceso.

    
respondido por el Lie Ryan 27.02.2015 - 18:19
fuente
1

Supongo que usted es el único root / administrador en la máquina.

Puedes usar una de esas dos opciones:

  1. No permitir a otros usuarios en esa máquina en absoluto
  2. Deje que el proceso se ejecute como un usuario especial y use un mecanismo de comunicación que solo sea accesible (lectura + escritura) para ese usuario (canalización con nombre, socket de dominio Unix, etc.)

Cualquiera de estas dos opciones hará que no sea necesario cifrar sus datos en tránsito.

Nota: si hay otro administrador (suficientemente capacitado) en la máquina, no puedes ocultar nada (incluidas las claves de cifrado).

    
respondido por el fex 27.02.2015 - 16:09
fuente
0

Básicamente, la seguridad suele estar en la clave, no en el algoritmo. Así que estás haciendo una tarea tonta aquí. Según lo establecido por el principio de Kerckhoff: "Un sistema criptográfico debe ser seguro incluso si todo sobre el sistema, excepto la clave, es de conocimiento público", o como lo reformuló Shannon: "el enemigo conoce el sistema". Por lo tanto, realmente no se puede tener un sistema de cifrado que no use una clave de alguna forma y que esté realmente protegido.

Ya que mencionó en su lista de etiquetas, permítame recordarle cómo este trabajo en principio.

La idea de SSL / TLS (https) es negociar una clave de cifrado simétrica para usarla en una sesión de comunicación entre un cliente y un servidor. El cliente se conecta al servidor y solicita su clave pública (criptografía asimétrica). La clave viene como parte de un certificado, que puede validarse utilizando la cadena de certificación del certificado. Con esa clave pública y una correcta validación del certificado, el cliente sabe con quién está hablando. Para que pueda transmitir información de forma segura.

El cliente puede usar la clave pública para negociar una clave simétrica para comunicarse entre sí durante esta sesión. La clave no puede ser derivada para nadie fuera de la comunicación (consulte las explicaciones más detalladas si es necesario enlace )

Con el uso de TLS, se garantiza la confidencialidad entre los dos socios y el cliente también puede autenticar el servidor mediante la cadena de certificación. Si es necesario autenticar a los clientes, TLS también admite el certificado de clientes.

    
respondido por el M'vy 27.02.2015 - 09:38
fuente

Lea otras preguntas en las etiquetas