Recientemente un cliente nos comentó lo siguiente:  

 “Como parte de nuestro proyecto de migración a Windows 7 desde Windows XP hemos estado evaluando el funcionamiento de EFS.  

·       Hemos descubierto que en Windows 7, si compartes una carpeta y un usuario cifra un archivo en local (equipo destino), el mismo usuario puede acceder al archivo y descifrarlo remotamente (desde otro equipo) sin que la maquina donde reside el archivo este configurado para que se confíe en ella para la delegación (de credenciales kerberos)

·         Si el usuario cierra sesión en el equipo destino, deja de poder descifrar el archivo desde un equipo remoto, recibiéndose el mensaje “Acceso denegado”. Si vuelve a iniciar sesión en el equipo destino y abre cualquier archivo cifrado con su (el mismo) certificado EFS, vuelve a poder descifrar y abrir el archivo original desde el equipo remoto 

·         Tenemos dudas de si se trata de un comportamiento erróneo o de un fallo de seguridad en Windows 7, puesto que en estas pruebas (realizadas con notepad y archivos de texto cifrados) no se observa el mismo comportamiento si el equipo destino donde reside el archivo cifrado es Windows XP

·         Puesto que los equipos destino no están marcados para que se confíe en ellos para la delegación, entendemos que lo observado en Windows 7 es contrario a lo descrito en el siguiente artículo:  

Using Encrypting File System (Remote Decryption on File Shares) “   

Tras investigar el comportamiento, determinamos lo siguiente:

  •  EFS intenta cargar un “mini-perfil” en el equipo destino y utilizarlo para llevar a cabo el descifrado – si el usuario ya tiene una sesión iniciada en el equipo destino, no es necesario cargar un perfil
  •  Mientras el mismo usuario mantenga un “handle” abierto a un archivo cifrado, se puede descifrar el archivo en remoto a pesar de que no se confíe en el equipo destino para la delegación. Esto ocurre porque el “handle” cachea la clave privada utilizada para la operación de descifrado, y utilizar esta clave privada desde la caché no requiere delegación a diferencia de cargarla desde el disco
  • A partir de Windows Vista SP2, se introdujeron nuevas opciones para el cacheo de claves privadas (por instancia de CSP) – sin embargo no estaban habilitadas por defecto
  • La funcionalidad de cacheo por instancia de CSP (Proveedor de Servicios Criptográficos) se configura mediante los valores DWORD CachePrivateKeys y PrivateKeyLifetimeSeconds debajo de la clave de registro HKLM\Software\Policies\Microsoft\Cryptography.

En realidad, la posibilidad de descifrar archivos EFS en remoto sin que el equipo destino este configurado para la delegación también existe en Windows XP: siempre que existe un “handle” abierto localmente al archivo EFS y el mismo usuario tiene una sesión iniciada en el equipo destino.  

 

(Las pruebas realizadas en este escenario se hicieron con Notepad, pero Notepad cierra el handle al archivo EFS en cuanto termina de descifrarlo, por tanto los resultados observados no son predecibles, y en la mayoría de los casos dará el resultado de que no se puede descifrar el archivo de texto en remoto. Si tenemos la suerte de acceder al archivo en remoto e intentar abrirlo mientras la clave aún está cargada por el “handle”  que notepad tiene al archivo, logramos descifrarlo con éxito. Como ejemplo, en Windows XP un archivo zip mantiene abierto el “handle” durante más tiempo)  

 

En resumen:

  • El cacheo de las claves privadas es posible en Windows XP, 2003, Vista, 2008, 2008R2 y Windows 7 – este cacheo permite la posibilidad de descifrar archivos EFS en remoto sin delegación únicamente si el mismo usuario ya tiene una sesión iniciada y ha descifrado (abierto) el archivo en el equipo destino
  • En Windows 7, la funcionalidad adicional del cacheo por instancia de CSP hace que esto sea más “visible” porque la nueva funcionalidad (introducida a partir de Vista SP2) está habilitada por defecto, permitiendo que el CSP mantenga la clave en cache a pesar de que ya se haya cerrado el “handle” al archivo cifrado.  

Información adicional:

  

Tolu Igbon

Ingeniero de Soporte de Microsoft