Si su modelo de amenaza incluye "procesos maliciosos que se ejecutan como el mismo usuario que el proceso legítimo que necesita la clave", debe volver al tablero de dibujo y volver a diseñar. No es posible protegerse contra eso. Los procesos dentro de una única sesión de usuario no son, y no se debe esperar que estén seguros entre sí.
La preocupación que expresa sobre las tuberías, por ejemplo, se extiende a cualquier otro tipo de mecanismo de IPC. TLS sockets con autenticación mutua? Cualquier proceso que pueda conectarse al socket también puede ser suplantado por otro proceso en el mismo contexto del usuario, leyendo los mismos datos clave y falsificando el proceso legítimo. Incluso si pudiera establecer el IPC de forma segura, eso no es garantía de que los datos estén seguros. Por ejemplo, algunos sistemas operativos (Windows notablemente, pero creo que también algunos Me gusta de Unix) permiten que cualquier proceso que se ejecute bajo un uso dado pueda depurar cualquier otro proceso bajo el mismo usuario, por lo que el proceso malintencionado podría simplemente leer el secreto de inmediato. Espacio de direcciones del proceso legítimo.
Bien, hablemos de escenarios en los que no asuma que otro proceso en el mismo contexto de usuario es malicioso. Tal vez sea porque usted (re) diseñó todo para que se ejecute en un contexto de usuario especial utilizado solo para el propósito específico de su software. Tal vez sea porque estás trabajando en un dispositivo integrado donde controlas todo el código que se ejecuta. Tal vez solo porque aceptaste que tratar de defenderse contra el código malicioso con los mismos privilegios que tienes es inútil e inútil (si los malos están ejecutando código en tu contexto de usuario, ya se acabó el juego, hombre).
No ha especificado el sistema operativo en el que debe ejecutarse su software. Sin embargo, en general, hay algunas opciones decentes aquí para el secreto que nunca querrás comprometer con el almacenamiento persistente.
En sistemas similares a Unix:
- sockets de dominio (local) Unix. Rápido y bastante sencillo. Apoyar la comunicación bidireccional, si eso importa. Para estar seguro, solo tiene que crearlos en una ubicación que no sea legible ni escribible por ningún otro usuario (algo bajo el perfil de usuario es una opción popular). Por otro lado, dijiste que no puedes alojar una toma de escucha en el Master (¿por qué no?), Por lo que es posible que esto no funcione.
- Una tubería con nombre, también llamada FIFO. Rápido y directo, pero solo unidireccional (si desea bidireccional, necesita crear un par de canalizaciones). Al igual que con el socket local, asegúrese de que se cree FIFO donde ningún otro usuario pueda acceder.
En Windows:
- Una tubería con nombre. A diferencia de las canalizaciones con nombre de Unix, las tuberías de Windows no entran en el sistema de archivos estándar; hay un "sistema de archivos de tuberías con nombre" especial para ellos. Esto significa que debe asegurarse de crear la tubería con la lista de control de acceso (ACL) correcta. Una vez creado, sin embargo, el uso de la tubería es rápido y simple.
- Una asignación de memoria con nombre. La API
CreateFileMapping se puede utilizar para cree una asignación de memoria que no esté respaldada por ningún archivo normal, sino por el archivo de paginación del sistema. Si bien el archivo de paginación está respaldado por datos persistentes y, por lo tanto, podría hacer que el secreto se almacene en el disco, eso es un riesgo en cualquier proceso; no puede garantizar que el secreto nunca se pagará de la memoria de trabajo a menos que su plataforma ofrezca (y usted use) algún tipo de búfer protegido por el núcleo. Mientras tanto, un atacante no sabría dónde buscar el secreto en el archivo de paginación, por lo que probablemente esté seguro. Las asignaciones de memoria con nombre, como las tuberías con nombre, deben ser seguras utilizando una ACL que impide que los procesos que se ejecutan bajo otros usuarios abran la asignación. Una vez que ambas partes han abierto el mapeo, sin embargo, es muy rápido.
- Acceso directo a la memoria (lectura, más probable) entre procesos. El proceso del cliente simplemente lee el secreto del espacio de direcciones virtuales del padre. Esto requiere una forma de pasar la dirección relevante al otro proceso, pero está bien si esa dirección está expuesta; otros usuarios no pueden acceder a la memoria del proceso incluso si saben dónde buscar, porque los procesos siempre tienen una ACL que impide que otros usuarios lean su memoria.