SPKI

La infraestructura de clave pública simple ( Infraestructura de clave pública simple rusa , SPKI, pronunciado spoo-key ) es una infraestructura de clave pública creada por el Grupo de trabajo de infraestructura de clave pública simple de IETF para abordar algunas de las deficiencias del estándar X.509 . Hay dos especificaciones de solicitud de comentarios de IETF : el grupo de trabajo IETF SPKI RFC 2692 y RFC 2693 .

Propósitos de la creación y características

SPKI es una infraestructura de clave pública diseñada para proporcionar mecanismos para respaldar la protección en una amplia gama de aplicaciones de Internet , incluidos los protocolos IPSEC , correo electrónico cifrado y documentos WWW , protocolos de pago y otras aplicaciones que solicitan el uso de certificados de clave pública y la capacidad de acceder a ellos. . [1] Se propuso SPKI para reemplazar X.509 debido a las deficiencias de este sistema. SPKI fue creado para resolver los problemas de autorización e identificación . Además, este sistema tiene la capacidad de delegar autoridad. SPKI no tiene una estructura de CA jerárquica global , sino que SPKI utiliza un enfoque de redistribución de confianza de abajo hacia arriba más granular similar a PGP . Para escribir certificados, se utilizan estructuras similares a LISP : expresiones S. Hay dos tipos de certificados SPKI: una tupla SPKI de cuatro objetos y una tupla SPKI de cinco objetos para autenticación y autorización, respectivamente. Con todo esto, SPKI no se usa mucho. [2]

Redistribución de la confianza

Para redistribuir la confianza, SPKI utiliza una red de confianza. Los propios usuarios gestionan las claves públicas de abajo hacia arriba. Cada usuario es una CA que firma las claves públicas de otros usuarios. Alice, firmando la clave pública de Bob, actúa como CA para Bob, luego Bob pasa el certificado firmado por Alice a Charlie. Si Charlie confía en Alice, entonces él estará seguro de que la clave pública dada, firmada por Alice, realmente pertenece a Bob. Debido a la constante conversación cruzada, esta red de confianza crece de arriba a abajo, de ahí el nombre. [2]

Delegación

Una de las ventajas del certificado de autorización SPKI es la delegación de autoridad de una persona a otra sin involucrar al propietario del recurso. Puede emitir un permiso simple (por ejemplo, leer algún archivo) o emitir un permiso para una mayor delegación. Cuando se considera la delegación de autoridad, surgen dos cuestiones: el deseo de limitar la profundidad de la delegación y la división de los delegantes potenciales entre los que pueden delegar y los que no. La regulación de estos procesos se lleva a cabo con la ayuda del control lógico (booleano). Su ventaja es que con el control booleano, puedes especificar la imposibilidad de delegar autoridad. Imagine que el Departamento de Comercio de EE. UU. tiene una clave que permite declarar exportable un módulo de software criptográfico y también delegarlo a otros. Tiene sentido suponer que el departamento de comercio no otorgará permiso para delegar más.

La capacidad de delegación del SPKI demuestra ser útil para las transacciones en Internet . Por ejemplo, cuando los gerentes individuales se van de vacaciones, pueden delegar su autoridad con respecto a ciertas acciones a sus subordinados. [3]

Certificados SPKI

Los certificados SPKI incluyen las claves públicas (o los valores hash de las mismas) de la autoridad que crea el certificado y el objeto del certificado. Los nombres no se incluyen en el certificado SPKI porque los autores del SPKI creen que solo importa la clave. Enfatizar las teclas significa que en este sistema se presta mucha atención a la funcionalidad. Hay dos tipos de certificados SPKI, una tupla SPKI de cuatro objetos y una tupla SPKI de cinco objetos, creados por claves de autenticación y autorización , respectivamente.

Una tupla SPKI de cuatro objetos

SPKI utiliza un SPKI de cuatro tuplas para asociar el nombre local y la clave pública de un usuario

(Creador, Nombre, Objeto, Periodo de validez)

En la práctica, el certificado consta de 5 objetos:

clave pública del creador
nombre del tema
clave pública del sujeto
validez
firma del creador del certificado en un triple (Nombre, Objeto, Periodo de validez)

Cualquier usuario puede crear dicho certificado y, como resultado, convertirse en una CA.

Un SPKI de cinco tuplas

El SPKI de cinco tuplas se utiliza para la autorización de claves y consta de:

(Creador, Objeto, Delegación, Autorización, Vigencia)

En realidad, el certificado tiene seis campos:

nombre del tema
clave pública del sujeto
delegación , es decir, un signo de "Sí" o "No" que indica si el sujeto puede delegar autoridad o no
autorización: lo que, de hecho, el sujeto puede delegar
período de validez de la autorización
firma del creador del certificado en cuatro (Objeto, Delegación, Autorización, Vigencia)

Combinación de certificados

Puede combinar certificados de autenticación y autorización para obtener un registro de auditoría. El certificado de autorización le permite realizar cualquier acción con la clave, pero no dice nada sobre el propietario de la clave. La vinculación de la clave se produce con la ayuda de un certificado de autenticación. Por lo tanto, existe la necesidad de utilizar su combinación.

La combinación de certificados se realiza utilizando la siguiente regla de reducción :

{\ estilo de visualización (I_{1},S_{1},D_{1},A_{1},V_{1})+(I_{2},S_{2},D_{2},A_{2} ,V_{2})=(I_{1},S_{2},D_{2},A_{2}\cap A_{1},V_{2}\cap V_{1})}

Donde es el creador, es el objeto, es la delegación, es la autorización, es la caducidad. $yo_yo$ $Si}$ $D_{yo}$ $Ai}$ $V_i$

La igualdad se logra si y sólo si y = Sí. ${\ estilo de visualización S_ {1} = I_ {2}}$ $D_{1}$

Delegación de autoridad con una combinación de dos tuplas

Detalles del certificado de Alicia:

$yo_1$ = Alicia
$S_{1}$ = Bob
$D_{1}$ = Sí
$A_{1}$ = Retirar 100 euros de la cuenta de Alicia
$V_{1}$ = Ilimitado

Esto significa que Alice le permite a Bob retirar 100 euros de la cuenta y permite delegar esta acción a cualquier persona que Bob considere necesaria.

Detalles del certificado de Bob:

$yo_{2}$ = Bob
$S_{2}$ = charlie
$D_{2}$ = no
$A_{2}$ = Retirar de la cuenta de Alice una cantidad de 50 euros a 100 euros.
$V_{2}$ = hasta mañana

Esto significa que Charlie puede retirar una cantidad en el rango de 50 euros a 100 euros de la cuenta de Alice durante el día de hoy.

Acoplamiento de dos certificados utilizando la regla de reducción:

$yo_3$ = Alicia
$S_{3}$ = charlie
$D_{3}$ = no
$A_{3}$ = Retirar de la cuenta de Alice una cantidad de 50 euros a 100 euros.
$V_{3}$ = hasta mañana

Por lo tanto, Alice permitió que Bob delegara autoridad y, como resultado, permitió que Charlie retirara dinero de su cuenta hasta mañana por la mañana. [2]

Período de validez y CRL

Un certificado SPKI, al igual que otros certificados , debe tener un período de validez: el período durante el cual es válido. También existe una verificación de validez en línea, que se logra a través de una lista de revocación de certificados - CRL . La CRL mínima contiene una lista de certificados revocados, un número de serie y una firma . Si se encuentra que un determinado certificado está en esta lista, ese certificado se destruye. Si encuentra una CRL anterior , elimina la CRL anterior. Tales CRL conducen a un comportamiento de programa no determinista. Como resultado, el proceso de autorización depende del tiempo, lo cual es una vulnerabilidad . Es decir, da lugar a la posibilidad de protección de revocación de certificados al impedir la entrega de nuevas CRL. Esto no satisface los requisitos criptográficos . SPKI ha eliminado este enfoque para sus certificados y ha hecho que el proceso sea determinista con CRL temporales que obedecen a tres reglas:

El certificado debe contener la clave (o su valor hash ) por la que se firma la CRL y puede indicar uno o más lugares donde se puede recuperar esa CRL.
La CRL debe contener una fecha de caducidad.
Los rangos de caducidad de CRL no deben superponerse. Es decir, una nueva CRL no puede surtir efecto hasta que caduque la CRL actual.

Según estas reglas, los certificados que utilizan una CRL no se pueden procesar sin una CRL válida. [3]

X.509 y SPKI

Campos básicos de un certificado X.509

Para mayor claridad, se muestran los campos principales del certificado X.509 .

número de serie del certificado - número de serie único
identificador de algoritmo de firma: tipo de firma digital utilizada por el creador del certificado
nombre del originador: nombre distinguido ( formato X.500 ) de un tercero de confianza
período de validez - especificando las fechas de inicio y finalización del período de validez del certificado
clave pública del sujeto
nombre del sujeto del certificado - nombre distinguido del sujeto

Diferencias entre SPKI y X.509

El problema con X.509 es que los nombres son globales (lo cual no es cierto) y se usan para identificar certificados. Por lo tanto, para autorizar al propietario de la clave, es necesario autenticarlo. Por lo tanto, la autorización sin autenticación en el estándar X.509 es imposible, lo que, en particular, significa que este estándar no admite la autorización anónima. En SPKI, estos problemas se resuelven por el hecho de que las claves, que son únicas en sí mismas, son identificadores (lo que permite la autorización anónima). Debido a que las claves son difíciles de interpretar para los humanos, SPKI proporciona nombres locales. Un nombre local es un nombre en algún espacio de nombres. De esto se deduce que el campo "Nombre del sujeto" tiene valores radicalmente diferentes. Otra diferencia entre SPKI y X.509 es el campo Delegación, que falta en X.509. Los campos similares entre sí en ambos certificados son los campos "Clave pública", "Nombre del creador" y "Período de vigencia".

Además, las diferencias entre SPKI y X.509 son que no hay una jerarquía de CA en SPKI , y en lugar del lenguaje ASN.1 utilizado para escribir certificados X.509, las expresiones S se usan para escribir certificados SPKI , que son ligeros. y fácil de entender, a diferencia de los certificados X.509 al análisis informático. También se proporciona una interfaz para facilitar la percepción de las expresiones S. [3] [2]

Véase también

Notas

↑ Requisitos de SPKI, 1999 .
↑ 1 2 3 4 Inteligente, 2005 .
↑ 1 2 3 Teoría del certificado SPKI, 1999 .

Literatura

C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. Teoría del certificado SPKI // IETF: artículo. — 1999.
C. Ellison. Requisitos SPKI // IETF: artículo. - 1999. Archivado el 1 de agosto de 2015.
Smart, N. Criptografía. - Tecnosfera, 2005. - 528 p.
C. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian M. Thomas, Tatu Ylonen. Certificado de clave pública simple // IETF: artículo. — 1999.