Descripción general de RPC segura

RPC segura (llamada de procedimiento remoto) protege los procedimientos remotos con un mecanismo de autenticación. El mecanismo de autenticación Diffie-Hellman autentica tanto el host como el usuario que realiza una solicitud para un servicio. El mecanismo de autenticación utiliza el cifrado Estándar de cifrado de datos (DES). Entre las aplicaciones que utilizan RPC segura se incluyen NFS y el servicio de nombres NIS.

Servicios NFS y RPC segura

NFS permite que varios hosts compartan archivos mediante la red. En el servicio NFS, un servidor contiene los datos y recursos para varios clientes. Los clientes tienen acceso a los sistemas de archivos que el servidor comparte con los clientes. Los usuarios conectados a los sistemas cliente pueden acceder a los sistemas de archivos mediante el montaje de sistemas de archivos del servidor. Para el usuario en el sistema cliente, los archivos se ven como locales para el cliente. Uno de los usos más comunes de NFS permite que los sistemas se instalen en oficinas mientras se almacenan todos los archivos de usuario en una ubicación central. Algunas de las funciones del servicio NFS, como la opción -nosuid para el comando mount, se pueden utilizar para prohibir la apertura de dispositivos y sistemas de archivos por parte de usuarios no autorizados.

El servicio NFS utiliza RPC segura para autenticar a los usuarios que realizan solicitudes a través de la red. Este proceso se conoce como NFS seguro. El mecanismo de autenticación Diffie-Hellman, AUTH_DH, usa cifrado DES para garantizar el acceso autorizado. El mecanismo AUTH_DH también se ha denominado AUTH_DES. Para obtener más información, consulte lo siguiente:

• Para configurar y administrar Secure NFS, consulte Administración de sistema NFS seguro de Gestión de sistemas de archivos de red en Oracle Solaris 11.1.

• Para una descripción de las transacciones implicadas en la autenticación RPC, consulte Implementación de autenticación Diffie-Hellman.

Autenticación Kerberos

Kerberos es un sistema de autenticación desarrollado en MIT. Algunos cifrados en Kerberos se basan en DES. El soporte de Kerberos V4 ya no se proporciona como parte de RPC segura. Sin embargo, una implementación por parte del cliente y por parte del servidor de Kerberos V5, que utiliza RPCSEC_GSS, se incluye con esta versión. Para obtener más información, consulte Cómo configurar servidores NFS con Kerberos.

Cifrado DES con NFS seguro

Las funciones de cifrado del Estándar de cifrado de datos (DES) utiliza una clave de 56 bits para cifrar los datos. Si dos principales o usuarios de credenciales conocen la misma clave DES, pueden comunicarse en privado mediante la clave para cifrar y descifrar texto. DES es un mecanismo de cifrado relativamente rápido.

El riesgo de usar sólo la clave DES es que un intruso puede recopilar suficientes mensajes de texto cifrado que se cifraron con la misma clave para poder descubrir la clave y descifrar los mensajes. Por este motivo, los sistemas de seguridad como NFS seguro necesitan cambiar las claves con frecuencia.

Autenticación Diffie-Hellman y RPC segura

El método de autenticación de un usuario Diffie-Hellman (DH) no es trivial para un intruso que quiere ingresar. El cliente y el servidor tienen sus propias claves privadas, las cuales se utilizan con la clave pública para crear una clave común. La clave privada también se conoce como clave secreta. El cliente y el servidor utilizan la clave común para comunicarse entre sí. La clave común se cifra con una función de cifrado acordada, como DES.

La autenticación se basa en la capacidad del sistema emisor de utilizar la clave común para cifrar la hora actual. A continuación, el sistema receptor puede descifrar y comprobar la hora actual. La hora en el cliente y el servidor debe estar sincronizada. Para obtener más información, consulte Gestión del protocolo de hora de red (tareas) de Introducción a los servicios de red de Oracle Solaris 11.

Las claves públicas y privadas se almacenan en una base de datos de NIS. NIS almacena las claves en el mapa publickey. Este archivo contiene la clave pública y la clave privada para todos los usuarios potenciales.

El administrador del sistema es responsable de configurar mapas NIS y de generar una clave pública y una clave privada para cada usuario. La clave privada se almacena en formato cifrado con la contraseña del usuario. Este proceso hace que sólo el usuario conozca la clave privada.

Implementación de autenticación Diffie-Hellman

En esta sección, se describe la serie de transacciones en una sesión cliente-servidor que utiliza autenticación Diffie-Hellman (AUTH_DH).

Generación de las claves públicas y las claves secretas para RPC segura

A veces, antes de una transacción, el administrador ejecuta el comando newkey o el comando nisaddcred para generar una clave pública y una clave secreta. Cada usuario tiene una clave pública y una clave secreta únicas. La clave pública se almacena en una base de datos pública. La clave secreta se almacena en formato cifrado en la misma base de datos. El comando chkey cambia el par de claves.

Ejecución del comando keylogin para RPC segura

Normalmente, la contraseña de inicio de sesión es idéntica a la contraseña de RPC segura. En este caso, el comando keylogin no es necesario. Sin embargo, si las contraseñas son distintas, los usuarios tienen que iniciar sesión y, a continuación, ejecutar el comando keylogin.

El comando keylogin le solicita al usuario una contraseña de RPC segura. El comando utiliza la contraseña para descifrar la clave secreta. El comando keylogin pasa la clave secreta descifrada al programa servidor de claves. El servidor de claves es un servicio RPC con una instancia local en cada equipo. El servidor de claves guarda la clave secreta descifrada y espera a que el usuario inicie una transacción RPC segura con un servidor.

Si la contraseña de inicio de sesión y la contraseña de RPC son iguales, el proceso de inicio de sesión pasa la clave secreta al servidor de claves. Si las contraseñas deben ser diferentes, el usuario debe ejecutar siempre el comando keylogin. Cuando el comando keylogin se incluye en el archivo de configuración del entorno del usuario, como el archivo ~/.login, ~/.cshrc o ~/.profile, el comando keylogin se ejecuta automáticamente siempre que el usuario inicia sesión.

Generación de clave de conversación para RPC segura

Cuando el usuario inicia una transacción con un servidor, ocurre lo siguiente:

1. El servidor de claves genera aleatoriamente una clave de conversación.

2. El núcleo usa la clave de conversación junto con otros materiales para cifrar la indicación de hora del cliente.

3. El servidor de claves busca la clave pública del servidor en la base de datos de claves públicas. Para obtener más información, consulte la página del comando man publickey(4).

4. El servidor de claves utiliza la clave secreta del cliente y la clave pública del servidor para crear una clave común.

5. El servidor de claves cifra la clave de conversación con la clave común.

Ponerse en contacto inicialmente con el servidor en RPC segura

La transmisión, que incluye la indicación de hora cifrada y la clave de conversación cifrada, se envía al servidor. La transmisión incluye una credencial y un verificador. La credencial contiene tres componentes:

• El nombre de red del cliente

• La clave de conversación, que se cifra con la clave común

• Una "ventana", que se cifra con la clave de conversación

La ventana es la diferencia en tiempo que el cliente afirma que se debe permitir entre el reloj del servidor y la indicación de hora del cliente. Si la diferencia entre el reloj del servidor y la indicación de hora es mayor que la ventana, el servidor rechaza la solicitud del cliente. En circunstancias normales, este rechazo no se produce porque el cliente primero se sincroniza con el servidor antes de iniciar la sesión RPC.

El verificador del cliente contiene lo siguiente:

• La indicación de hora cifrada

• Un verificador cifrado de la ventana especificada, que se reduce a 1

El verificador de ventana es necesario en caso de que alguien desee asumir la personalidad de un usuario. El imitador puede escribir un programa que, en lugar de completar los campos cifrados de la credencial y el verificador, sólo inserte bits de manera aleatoria. El servidor descifra la clave de conversación en alguna clave aleatoria. El servidor utiliza la clave para intentar descifrar la ventana y la indicación de hora. El resultado son números aleatorios. Después de miles de intentos, sin embargo, el par ventana/indicación de hora aleatorio podría pasar el sistema de autenticación. El verificador de ventana disminuye la posibilidad de que una credencial falsa se pueda autenticar.

Descifrado de la clave de conversación en RPC segura

Cuando el servidor recibe la transmisión del cliente, se produce lo siguiente:

1. El servidor de claves local del servidor busca la clave pública del cliente en la base de datos de claves públicas.

2. El servidor de claves utiliza la clave pública del cliente y la clave secreta del servidor para deducir la clave común. La clave común es la misma clave común que el cliente procesa. Sólo el servidor y el cliente pueden calcular la clave común porque el cálculo requiere que se conozca una de las claves secretas.

3. El núcleo usa la clave común para descifrar la clave de conversación.

4. El núcleo llama al servidor de claves para descifrar la indicación de hora del cliente con la clave de conversación descifrada.

Almacenamiento de información en el servidor en RPC segura

Después de que el servidor descifra la indicación de hora del cliente, el servidor almacena cuatro elementos de información en una tabla de credenciales:

• El nombre de equipo del cliente

• La clave de conversación

• La ventana

• La indicación de hora del cliente

El servidor almacena los primeros tres elementos para su uso futuro. El servidor almacena la indicación de hora del cliente para evitar que se realicen reproducciones. El servidor acepta sólo indicaciones de hora que son cronológicamente mayores que la última indicación de hora vista. Como resultado, cualquier transacción reproducida seguramente sea rechazada.

Devolución del verificador al cliente en RPC segura

El servidor devuelve un verificador al cliente, que incluye lo siguiente:

• El ID de índice, que el servidor registra en su caché de credenciales

• La indicación de hora del cliente menos 1, que se cifra mediante la clave de conversación

El motivo para sustraer 1 de la indicación de hora del cliente es para asegurarse de que la indicación de hora esté desactualizada. Una indicación de hora desactualizada no puede volver a utilizarse como un verificador de cliente.

Autenticación del servidor en RPC segura

El cliente recibe el verificador y autentica el servidor. El cliente sabe que sólo el servidor pudo haber enviado el verificador ya que sólo el servidor conoce la indicación de hora que el cliente envió.

Manejo de transacciones en RPC segura

Con cada transacción después de la primera transacción, el cliente devuelve el ID de índice al servidor en su siguiente transacción. El cliente también envía otra indicación de hora cifrada. El servidor envía de vuelta la indicación de hora del cliente menos 1, que se cifra mediante la clave de conversación.