SPKM ( inglés The Simple Public-Key GSS-API Mechanism - un mecanismo simple [1] GSS-API basado en una infraestructura de clave pública ) es un protocolo de red que tiene una infraestructura de clave pública, no una clave simétrica . El protocolo se utiliza para autenticación , generación de claves, integridad de datos y confidencialidad.
En septiembre de 1993 se publica la primera versión del GSS-API [2] [3] , y al mismo tiempo aparece el mecanismo Kerberos V5 [4] . Pero aunque Kerberos 5 se ha convertido en un protocolo establecido ampliamente utilizado en muchos sistemas, algunas aplicaciones han necesitado tener una GSS-API integrada en una infraestructura de clave pública en lugar de una infraestructura de clave simétrica. Esto llevó a la creación del protocolo SPKM (sus dos primeras variantes) en octubre de 1996 por Carlisle Adams . Sin embargo, cuando se creó NFSv4 en el año 2000, surgió el problema de la autenticación mutua y la creación de un canal seguro entre un usuario anónimo y el servidor, lo que llevó a la aparición de SPKM-3.
De las propiedades anteriores, se deduce que SPKM tiene flexibilidad y funcionalidad, sin complejidad innecesaria ni sobrecarga de implementación. Dado que SPKM se ajusta a GSS-API, puede ser utilizado por una aplicación como un protocolo de seguridad de red alternativo (por ejemplo, en lugar de Kerberos) [6] .
La descripción de la Interfaz de Programación de Servicios de Seguridad General (GSS-API), según se puede dividir en 2 partes [2] :
SPKM es un ejemplo del último tipo de documento y, por lo tanto, se denomina "mecanismo GSS-API". Este mecanismo proporciona autenticación, generación de claves, integridad de datos y confidencialidad de datos en aplicaciones distribuidas en línea utilizando una infraestructura de clave pública. SPKM se puede usar como reemplazo de cualquier otra aplicación que use servicios de seguridad a través de llamadas GSS-API (por ejemplo, una aplicación que ya usa Kerberos GSS-API). El uso de una infraestructura de clave pública permite el uso de firmas electrónicas para mantener el no repudio de autoría en la mensajería, y además brinda otros beneficios como la escalabilidad a grandes grupos de usuarios.
Los tokens definidos en SPKM están destinados a ser utilizados por programas de aplicación de acuerdo con el paradigma operativo GSS-API [2] . Funciona de la siguiente manera. Por lo general, un protocolo de red (o una aplicación que lo usa) llama al GSS-API para asegurar una conexión con servicios de autenticación, confidencialidad y/o integridad de datos. Al llamar a GSS-API, el protocolo (aplicación) acepta los tokens que le proporciona su implementación (local) de GSS-API (es decir, el mecanismo de GSS-API) y pasa los tokens al sistema remoto, en en el otro extremo, se recibe el token y su procesamiento posterior ya se realiza mediante su propio mecanismo GSS-API. Por lo tanto, el GSS-API en sí mismo no proporciona servicios de seguridad, sino que proporciona una interfaz entre las aplicaciones y las implementaciones (mecanismos) del GSS-API. Y ellos, a su vez, proporcionan una interfaz compatible con GSS-API, lo que le permite crear aplicaciones que pueden funcionar con diferentes mecanismos de seguridad; permitiendo reemplazar mecanismos sin necesidad de reescribir aplicaciones.
Para garantizar al menos una compatibilidad mínima entre las diferentes implementaciones de SPKM, uno de los algoritmos de integridad se hizo obligatorio (OBLIGATORIO), y todos los demás algoritmos y ejemplos son compatibles opcionalmente con varias implementaciones, algunos algoritmos también están marcados como recomendados (RECOMENDADO), esto se hace para aumentar la compatibilidad [6] .
El protocolo SPKM utiliza los siguientes algoritmos:
Se utiliza para garantizar que los datos no han sido modificados por un tercero. Dependiendo del algoritmo, también puede asegurar la fiabilidad y la imposibilidad de negar la autoría del mensaje.
Los siguientes algoritmos se pueden usar como ejemplos (los identificadores de algoritmo se dan a continuación):
md5WithRSAEncryption IDENTIFICADOR DE OBJETO ::= { iso (1) cuerpo miembro (2) EE. UU. (840) rsadsi (113549) pkcs (1) pkcs-1(1) 4 //prestado de PKCS#1 }Este algoritmo es obligatorio (OBLIGATORIO) para SPKM. Garantiza la integridad, la autenticidad y el no repudio de los datos mediante el cálculo de una firma electrónica RSA basada en una función hash MD5 . Dado que este algoritmo es actualmente el único algoritmo de integridad y autenticación requerido, para la interoperabilidad también se proporcionó que md5WithRSA sea el algoritmo de firma para todos los tokens de conexión, en el que la integridad se verifica mediante una firma y no se basa en MAC. Quizás en el futuro haya otros algoritmos obligatorios, y luego esta condición impuesta a los marcadores desaparezca [6] .
IDENTIFICADOR DE OBJETO DES-MAC ::= { iso(1) organización-identificada(3) oiw(14) secsig(3) //almacena la longitud MAC en bits como un número entero, algoritmo(2) 10 //limitado a múltiplos de 8, de 16 a 64 }Este algoritmo es RECOMENDADO y la integridad se aplica mediante el uso de MAC basado en DES.
md5-DES-CBC IDENTIFICADOR DE OBJETO ::= { iso(1) organización-identificada(3) dod(6) internet(1) seguridad(5) integridad(3) md5-DES-CBC(1) }Aquí, la integridad de los datos está garantizada por el cifrado basado en DES - CBC y hash MD5 "mixto". Esto es más rápido en la práctica que el cálculo DES-MAC si los datos de entrada son pequeños (del orden de unos pocos bytes). Tenga en cuenta que sin amasar, la integridad del mecanismo es como máximo o igual a la fuerza de DES contra un ataque de texto sin formato conocido.
sum64-DES-CBC IDENTIFICADOR DE OBJETO ::= { iso(1) organización-identificada(3) dod(6) internet(1) seguridad(5) integridad(3) sum64-DES-CBC(2) }Este algoritmo garantiza la integridad de los datos mediante el cifrado mediante DES CBC. La concatenación de los datos "mixtos" y la suma de todos los bloques de datos de entrada (la suma se calcula utilizando módulo 2 64 - 1 suma ). Así, en este algoritmo, el cifrado es una condición necesaria para garantizar la integridad de los datos [6] .
Estos algoritmos simétricos se utilizan para cifrar datos para llamadas GSS-API: gss_seal() / gss_wrap() .
Ejemplo:
IDENTIFICADOR DE OBJETO DES-CBC ::= { iso(1) organización-identificada(3) oiw(14) secsig(3) algoritmo(2) 7 }Este algoritmo es RECOMENDADO.
Se utiliza para crear una clave simétrica utilizada por los nodos durante una conexión. Además, las subclaves para los algoritmos de integridad y confidencialidad se crean a partir de esta clave. La generación de claves tiene lugar durante el intercambio de autenticación X.509, de modo que se autentica la clave simétrica resultante.
Ejemplos:
IDENTIFICADOR DE OBJETO RSAEncryption ::= { iso (1) cuerpo miembro (2) EE. UU. (840) rsadsi (113549) pkcs (1) pkcs-1(1) 1 // tomado de PKCS#1 y RFC-1423 }En este algoritmo OBLIGATORIO, el iniciador crea la clave de conexión utilizando la clave pública RSA del objetivo y se la envía. El objetivo, a su vez, no tiene que ser respondido para que se genere la clave.
IDENTIFICADOR DE OBJETO dhKeyAgreement ::= { iso (1) cuerpo miembro (2) EE. UU. (840) rsadsi (113549) pkcs (1) pkcs-3(3) 1 }En este ejemplo, la clave es generada por ambos nodos utilizando el algoritmo Diffie-Hellman . Por lo tanto, el objetivo debe responder al iniciador para establecer una conexión (por lo tanto, este algoritmo no se puede usar con la autenticación unidireccional en SPKM-2).
Al generar una clave de unión mediante K-ALG, los nodos deben obtener un conjunto de subclaves para los algoritmos de confidencialidad e integridad. Para ello se utilizan funciones unidireccionales . Deje que la lista de algoritmos de privacidad aceptados se numere secuencialmente, es decir, al primer algoritmo (el algoritmo predeterminado) se le asigna el número 0, al segundo, el número 1, y así sucesivamente. Deje que la lista de algoritmos de integridad se numere de la misma manera. Finalmente, permita que la clave de unión sea una cadena binaria de longitud arbitraria M , sujeta a restricciones:
L ≤ METRO ≤ ULa longitud en bits de la clave de combinación debe ser mayor que la longitud en bits más grande de las subclaves (C-ALG o I-ALG) y, al mismo tiempo, está limitada desde arriba por los parámetros de entrada del algoritmo de derivación de claves ( K-ALG).
Por ejemplo, al usar DES y 3-DES en los algoritmos de privacidad y DES-MAC en el algoritmo de integridad, la clave de combinación debe tener al menos 112 bits. Y cuando se usa RSA de 512 bits, la longitud posible es de 424 bits (el parámetro de entrada RSAEncryption más grande permitido, descrito en PKCS#1). Por otro lado, al utilizar el algoritmo dhKeyAgreement, la clave de conexión se calcula mediante el algoritmo Diffie-Hellman (excepto el byte alto, que se descarta por seguridad), por lo que su longitud será 8 bits menor que el módulo p, que es de aproximadamente 1000 bits [6] .
El algoritmo para obtener una subclave de k bits se define de la siguiente manera:
rightmost_k_bits (OWF (context_key || x || n || s || context_key)) donde:context_key - clave de conexión;
x - Carácter ASCII "C" (0x43) al crear una subclave para el algoritmo de confidencialidad, carácter ASCII "I" (0x49) al crear una subclave para el algoritmo de integridad;
n es el número del algoritmo en la lista permitida correspondiente (carácter ASCII "0" (0x30), "1" (0x31), etc.);
s - "etapa" de procesamiento - siempre es igual al carácter ASCII "0" (0x30), si "k" no es mayor que el tamaño de salida de la función unidireccional (OWF), en cuyo caso la función unidireccional es recalculada con un incremento en el valor de la "etapa" (cada valor de salida de la OWF anexado al final de las anteriores), hasta formar "k" bits;
|| - operación de concatenación;
OWF es la función unidireccional correspondiente.
Ejemplos:
MD5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5 }Este algoritmo es obligatorio (OBLIGATORIO).
SHA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 }Las funciones hash existentes no coinciden con todas las propiedades de las funciones unidireccionales. Por lo tanto, durante el proceso de establecimiento de la conexión, se aplica la negociación del algoritmo de derivación de subclave, lo que permite negociar futuras mejoras de la función unidireccional con versiones anteriores.
En el proceso de establecer una conexión en SPKM, el iniciador propone una serie de posibles algoritmos de confidencialidad e integridad de datos (incluidos los algoritmos de firma electrónica). El receptor elige qué algoritmos se utilizarán en la conexión establecida y envía una lista corregida de algoritmos admitidos. Cada mensaje transmitido a través de una conexión establecida puede usar cualquier algoritmo de confidencialidad e integridad, siendo los algoritmos que aparecen primero en la lista los predeterminados. Los algoritmos de confidencialidad e integridad adoptados para una determinada conexión determinan los valores del parámetro de calidad de protección ( Q uality O f Protection ) utilizado por las funciones gss_getMIC () y gss_wrap() , que calculan los códigos de integridad del mensaje criptográfico y lo adjuntan a el mensaje. Si no se espera respuesta del receptor (autenticación unidireccional en SPKM-2), entonces se utilizarán los algoritmos ofrecidos por la fuente en el proceso de transmisión del mensaje. Si el receptor no es compatible con los algoritmos aplicados, envía un token de finalización de conexión (token de eliminación) a la fuente y la conexión finaliza.
Además, en el primer token de establecimiento de conexión, el origen propone una serie de posibles algoritmos de generación de claves (K_ALG) junto con una clave (o la mitad de la clave) correspondiente al primer algoritmo de la lista. Si este algoritmo no es aceptable, entonces el receptor debe elegir uno de los restantes en la lista y enviar su elección junto con la clave (media) correspondiente al algoritmo seleccionado. Si la lista enviada al receptor no contiene un algoritmo compatible, envía un marcador de desconexión a la fuente. Si es necesario (si el receptor elige un algoritmo de generación de claves bidireccional, como es el caso del algoritmo Diffie-Hellman), la fuente devolverá su mitad de la clave al receptor. Finalmente, en el primer token de establecimiento de conexión, la fuente ofrece una cantidad de algoritmos de generación de subclaves permitidos, pero si se usa la autenticación unidireccional, solo se ofrece un algoritmo. El algoritmo (el único) elegido por el receptor se convierte en el algoritmo de obtención de la subclave en la conexión establecida [6] .
Para comprender cómo funcionan los tokens utilizados en SPKM, veamos un ejemplo de establecimiento de una conexión basada en números aleatorios. No cubriremos todos los tokens y funciones disponibles, para familiarizarse con la lista completa y ver su descripción e implementación, es mejor consultar RFC 2025 .
En el diagrama que se muestra, el iniciador de la conexión llama a la función gss_init_sec_context() , que devuelve un token SPKM_REQ , que luego se envía al receptor utilizando el protocolo de red en uso. El receptor, al recibir este token, lo pasa a gss_accept_sec_context() , que devuelve como resultado SPKM_REP_TI . Su receptor lo devuelve al iniciador. Eso, a su vez, usa este marcador como parámetro de entrada durante la segunda llamada a gss_init_sec_context() . Si el iniciador usó autenticación unidireccional, entonces el establecimiento de la conexión termina aquí. De lo contrario (por ejemplo, si inicialmente se requiere autenticación mutua), gss_init_sec_context() devuelve SPKM_REP_IT , que se envía al receptor. Utiliza este token durante la segunda llamada a gss_accept_sec_context() y, por lo tanto, completa la configuración de la conexión. Después de eso, las partes pueden intercambiar tokens SPKM_MIC y SPKM_WRAP hasta que una de las partes envíe SPKM_DEL para finalizar la conexión [5] .
El marcador SPKM_REQ contiene, entre otros campos de datos, los siguientes elementos:
La integridad de estos datos está protegida, y además está firmada con la firma electrónica del iniciador de la conexión. Si desea permanecer en el anonimato, en este caso, la integridad está protegida mediante MAC. Opcionalmente, en este token se puede enviar información sobre certificados digitales .
El marcador SPKM_REP_TI contiene:
La integridad de estos datos está protegida, y además están firmados con la firma electrónica del receptor. Tenga en cuenta que el número aleatorio del iniciador firmado por el receptor le da una garantía de que el receptor está "vivo" y confiable. La información sobre los certificados digitales se puede enviar en este token si lo solicita el iniciador en SPKM_REQ .
Si se ha seleccionado la autenticación mutua, se utiliza el token SPKM_REP_IT , que contiene los siguientes campos:
La integridad de estos datos está protegida, y además están firmados con la firma electrónica del iniciador. Tenga en cuenta que el número aleatorio del receptor firmado por el iniciador le da una garantía de que el iniciador está "vivo" y confiable.
Una vez que se completa el establecimiento de la conexión de número aleatorio, ambas partes se autentican (sin el uso de marcas de tiempo confiables), la clave de conexión se ha establecido de forma segura, los dos conjuntos de algoritmos (confidencialidad e integridad) se acuerdan para ser utilizados en la conexión por el Operaciones MIC y WRAP . Cada marcador SPKM_MIC , SPKM_WRAP y SPKM_DEL puede especificar explícitamente el algoritmo adecuado de la lista negociada que se usará para los datos asociados con el marcador, o usar los algoritmos "predeterminados" (es decir, los primeros algoritmos en cada una de las listas).
SPKM_MIC : utilizado para firmar y verificar la integridad de los datos (gss_sign() / gss_getMIC())
SPKM_WRAP : se utiliza para el cifrado (descifrado) y la protección de la privacidad de los datos (gss_seal() / gss_wrap())
SPKM_DEL - para terminar la conexión (gss_delete_sec_context()).
Por lo tanto, los marcadores contienen la siguiente información:
Este formato de token brinda más flexibilidad al llamar a las aplicaciones para seleccionar la calidad de protección (QOP) adecuada para los datos protegidos dentro de la conexión establecida [5] .
Originalmente se describieron dos tipos de SPKM: SPKM-1 y SPKM-2, la principal diferencia es que SPKM-2 requiere marcas de tiempo confiables para el redescubrimiento durante el establecimiento de la conexión, mientras que SPKM-1 no. Esto proporciona más flexibilidad para las aplicaciones, ya que no siempre es posible utilizar marcas de tiempo confiables en el sistema. Cuando se creó el protocolo NFSv4 en el año 2000, surgió la necesidad de un mecanismo que prevea la creación de un canal seguro con autenticación mutua, donde:
Así apareció el SPKM-3 que, mediante el complemento LIPKEY, sustenta el funcionamiento de los sistemas de archivos de red [8] [9] . En primer lugar, se creó para simplificar el procedimiento de autenticación. Consideremos este mecanismo con más detalle.
Cliente:
Así, se establece una conexión segura entre el cliente y el servidor, como se puede ver aquí se utiliza el algoritmo Diffie-Hellman. El cliente puede proporcionar su nombre de usuario y contraseña para la autenticación (o certificados), sin embargo, esto no es obligatorio, es decir, el cliente puede permanecer en el anonimato.
Como puede ver, el mecanismo de autenticación utilizado es similar a TLS, pero junto con la simplicidad y la conveniencia, también heredó el principal inconveniente: la posibilidad de un ataque de intermediario [10] .
GSS-API ( Servicio de seguridad genérico - Interfaz de programación de aplicaciones - Servicio de seguridad genérico - Interfaz de programación de aplicaciones ) permite que una aplicación autentique a un usuario correspondiente a otra aplicación para otorgarle derechos y aplicar servicios de seguridad de confidencialidad e integridad de datos para cada mensaje.
Hay 4 pasos para usar GSS-API:
| Protocolos de autenticación e intercambio de claves | |
|---|---|
| Con algoritmos simétricos | |
| Con algoritmos simétricos y asimétricos | |
| Protocolos y servicios utilizados en Internet | |