miércoles, 13 de septiembre de 2006

La revocación de certificados centralizada

Si una organización decide utilizar certificados x509v3 emitidos por un proveedor de servicios de certificación (PSC) para uso interno de sus empleados y colaboradores, normalmente existie un mecanismo por el cual, dicho organismo puede comprobar si alguno de estos certificados ha sido revocado. Esto es especialmente importante cuando lo que se emplean son certificados personales y se delega en las personas la responsabilidad de notificar al tercero si existe o se sospecha que existe una situación que pueda comprometer la clave privada del certificado.

Normalmente, el propio certificado continene la información necesaria para comprobar dicha revocación a través de Internet y mediante el uso de protocolos ampliamente aceptados pa la consulta o descarga de CRLs (Certificate Revocation List), una especie de lista negra que contiene habitualmente los números de serie de los certificados revocados por la entidad de certificación.

La complejidad se acentúa cuando el crece el número de certificados de diferentes PSC que la organización acepta. Aumenta con esto el número de protocolos de acceso a las CRL, algunos de ellos no estan implementados de serie en el sistema operativo o las aplicaciones y requieren adquirir software especial para ello como por ejemplo OCSP (Online Certificate Status Protocol) que se utiliza para validar el DNIe.

Con esta complejidad añadida a la necesidad que todos los puestos de la organización deban disponer de los protocolos y de acceso a Internet, no parece un escenario idoneo para una organización. No existe una auditoría centralizada de los accesos a la comprobación de revocación de certificados, no se puede revocar localmente un certificado, no podemos disponer con facilidad de un cache corporativo de CRLs descargadas que reduzca el tiempo de acceso, y un largo etc.

En Smart Access conscientes de esta situación, estamos actualmente desarrollando SmartID Revoke, que instalado en uno o varios servidores (depende de si la configuración es o no en alta disponibilidad) permite que los agentes de los puestos envíen todas sus peticiones a dichos servidores centrales en la organización y son estos los responsables de implementar todos los protocolos, acceder y registrar los accesos a las autoridades de validación o información de revocación de entidades de certificación, realizar un cache corporativo de la descarga de CRLs e incluso decidir revocar ciertos certificados solo para el ámbito de mi organización.

Este servicio puede instalarse en servidores de una organización o bien prestarse por un prestador de servicios como una autoridad de validación para aplicaciones del sistema (correo, navegador, etc) y para aplicaciones comerciales, al estilo que realizan para la Administración el Ministerio de Administraciones Públicas con la plataforma @firma.

Cualquier sugerencia, petición o comentario al respecto será bienvenido, asi como si hay empresas u organismos interesadas en participar en la fase de pruebas del producto. Esperamos disponer de una versión preliminar para el mes de Noviembre y una versión definitiva en el primer trimestre del proximo año.

Rames.

jueves, 7 de septiembre de 2006

Conferencia anual de la SmartCardAlliance

Del proximo 3 al 6 de Octubre se celebra la conferencia anual de la SmartCardAlliance en San Diego. Durante estos días los conferenciantes destacarán las nuevas adopciones y las innovaciones en el campo de las SmartCard, asi como las nuevas tendencias y tecnologías en este campo. Una de las novedades es la fusión de la tecnología SmartCard con RFID que abre nuevas e interesantes posibilidades de uso de las tarjetas inteligentes.

domingo, 20 de agosto de 2006

El imparable ascenso de la Biometria

Según la compañía Endpoint Technologies Associates, el número de PCs con lectores de huella dactilar aumentará en los próximos 5 años hasta multiplicar el número actual por 15, desde los actuales 15 millones de unidades en 2006 a los 228 millones de unidades en el año 2011. Este enorme crecimiento puede ser atribuido a la reducción de precios de estos dispositivios, a su creciente aceptación por parte del público en general y a las nuevas potenciales aplicaciones que estan apareciendo para esta tecnología.

Los lectores de huella (fingerprint scanners) es la más práctica de las tecnologías biometricas cuando hablamos de PCs. Se integran en cualquier pequeño espacio no empleado del teclado y solo requieren un pequeño gesto del usuario para permitir el acceso. La inclusión de estos dispositivos en PCs fue realizada por primera vez por IBM en el año 2004 que incluia lectores de huella en sus portatiles ThinkPad. Desde entonces, la mayor parte de los grandes fabricantes de PC ofrecen esta posibilidad a los usuarios. Compañías como AuthenTec y UPEK fabricantes ambos de lectores de huella, mantienen crecimientos de sus ingresos alrededor de un 200% anualmente.

El precio de un lector de huella para su integración en un ordenador portatil era inicialmente de unos $26 por unidad - precios que ahora estan alrededor de $5 por unidad. Tambien existen teclados con lectores incorporados de diversos fabricantes disponibles para ordenadores de sobremesa y servidores.

Además, es frecuente ver que se combina la tecnología de recocimiento de huella dactilar con tarjetas inteligentes, integrandose tambien dispositivos lectores de tarjetas tanto en portatiles com en ordenadores de sobremesa.

Rames.

viernes, 18 de agosto de 2006

Iniciar sesión en Windows con una smartcard (incluido el DNI Electrónico) ya es posible

Hoy, todas las organizaciones se plantean dejar de usar en algún momento las passwords para pasar a lo que denominan una autenticación fuerte . Y la salida del DNIe no ha hecho más que incrementar este tipo de necesidad.

Lo que sucede, no es que Windows no pueda implementar un logon con smartcards. Esta funcionalidad está presente desde que apareció Windows 2000 hace ya 6 años sino lo que dificulta su uso son los requisitos, que provienen de la aplicación de la especificación PKINIT basada en Kerberos. Estos requisitos se detallan en el articulo de soporte de Microsoft del caso Q281245 y puede consultarse en: http://support.microsoft.com/kb/281245/es

Con respecto a los requisitos, algunos son de configuración y son más o menos faciles de cumplir, mientras otros son relativos a la estructura y contenido del certificado o certificados x509v3 contenidos en la tarjeta intelegente (smartcard).

Windows requier requiera que el certificado contenga:

  • La ubicación del Punto de distribución de CRL (CDP), donde CRL es la Lista de revocación de certificados, debe estar llena, en conexión y disponible. Por ejemplo:[1]Punto de distribución CRLNombre del punto de distribución:Nombre completo:URL=http://server1.name.com/CertEnroll/caname.crl
  • Uso de claves = firma digital
  • Restricciones básicas [Tipo de asunto=Entidad final, Restricción de longitud de ruta=Ninguna] (Opcional)
  • Uso mejorado de claves = Autenticación del cliente (1.3.6.1.5.5.7.3.2)(El OID de autenticación del cliente sólo es necesario si se utiliza un certificado para la autenticación SSL.)
  • Inicio de sesión de tarjeta inteligente (1.3.6.1.4.1.311.20.2.2)
  • Nombre alternativo del sujeto = Otro nombre: Nombre principal= (UPN). Por ejemplo:UPN = usuario1@nombre.com, El OID OtherName UPN es: "1.3.6.1.4.1.311.20.2.3" y el valor OtherName UPN: debe ser una cadena UTF8 codificada en ASN1
  • Asunto = Nombre completo del usuario. Este campo es una extensión obligatoria, pero es opcional rellenarlo.
Si el certificado ha sido emitido por la PKI incluida en Windows 2000 o Windows Server 2003, probablemente se cumplirán. Lamentablemente no hay muchas autoridades de certificación en españa que utilicen la PKI de Windows.

El mayor obstaculo, en mi opinión, son los atributos que he marcado en rojo y en especial el segundo que obliga a establecer la relación entre el certificado y el usuario en el mismo momento de la emisión del certificado.

Esto tiene algunas implicaciones, tanto técnicas como operativas, y es que si se trata de un certificado personal se esta vinculando datos laborales de la persona (usuario del Directorio Activo que corresponde a la persona de la empresa en la que trabaja cuando se emite el certificado), si por cualquier razón esa persona cambia de trabajo necesitaría revocar dicho certificado y solicitar uno nuevo.

Si nos planteamos utilizar en nuestra empresa alguno de los certificados personales que se emiten por la administración como los certificados CERES o el propio DNI electrónico, veremos que ninguno cumple estos requisitos y no pueden solicitarse como requiere Windows.

Y es que Windows no puede configurarse en este aspecto y tiene configurado que la relación entre el certificado y el usuario debe ser siempre a través del contenido del atributo "Nombre alternativo del asunto" (Subject Alternative Name) y que el certificado debe tener el proposito de "Inicio de sesión de tarjeta inteligente" (Smartcard logon) y una dirección (URL) válida para la comprobacion de revocación.j

Adicionalmente es obligatorio en el logon comprobar siempre la revocación de certificados no pudiendo desactivarse por el administrador este comportamiento al igual que se hace en otras aplicaciones. Esto lo hace más seguro, pero en ciertos casos añade más segundos de demora al proceso de inicio de sesión.

Si falla cualquiera de estas requisitos, Windows determina que el certificado no es válido para el logon y no progresa la petición, con el consiguiente mensaje al usuario.

La realidad es, que desde hace ya algunos años, y en especial desde el lanzamiento del DNI Electrónico (DNIe) la mayoría de los organismos públicos y empresas estan planteandose evolucionar desde el inicio basado en usuario y contraseña a una autenticación más segura basada en varios factores (algo que tiene el usuario o algo que és, además de lo que sabe).

Lamentablemente, Microsoft no ha publicado planes para cambiar este comportamiento en Windows y las implementaciones que resuelven esta problemática por parte de empresas de software, optan por el método tradicional de reescribir el proceso que gobierna el logon de Windows (comúnmente denominado GINA de Graphical Identification aNd Authentication library)

Todo esto nos ha llevado en Smart Access a desarrollar una familia de productos (denominada SmartID) que facilita y promueve el uso de smartcards, certificados y opcionalmente reconocimiento biométrico para un incio de sesión más seguro en Windows. Estos productos ya se comercializan desde Abril de 2006 y proporcionan la flexibilidad a las organizaciones de utilizar cualquier certificado propio o emitido por terceros para el inicio de sesión en Windows utlizando smartcards de forma segura.

Rames.

Algoritomos criptográficos Suite-B. ¿Porque se debe cambiar?

Realmente no se trata de una suite de hotel, ni de un conjunto de productos de segunda categoría.

Suite B, es lo último en algoritmos criptografícos. Aunque algunos existen desde hace más de dos décadas, es ahora cuando comienzan a aparecer productos comerciales que los implementan y clientes que los demandan.

La situación hoy de los algoritmos criptográficos es la siguiente:

  • La criptografía de 40-bits que tradicionalmente esta sujeta al control de exportación de EEUU, se considera trivial de romper.
  • La criptografía de 56-bits se consiguió romper hace algunos años por menos de 300.000€
    Un hash 128-bit MD4, es equivalente a un algoritmo de clave simétrica de 64-bits y ya ha sido roto.
  • El 128-bit MD5 ha sido roto por un equipo chino.

Hoy es muy frecuente ver que se aplica la criptografía de 80-bit, pero incluso esta tiene un tiempo de vida limitado.

  • SHA-1 tiene solo una fortaleza de 2^80, asumiendo que el atacante pueda obtener 2^40 pares de cifrado.
  • RSA-1024 se considera equivalente a una fortaleza de 2^80
  • El NIST (National Institute de Standards and Technology de Estados Unidos - Agencia federal dedicada a definir standares y tecnología especialmente en el área de seguridad y criptografía) recomienda al resto de agencias federales de EEUU dejar de utilizar la criptografía de 80-bits como muy tarde en el año 2010.

¿Cual es entonces la solución?, parece que los algoritmos empleados en los últimos años han dejado o dejarán en breve de ser seguros.

El siguiente escalón lo representan el manejo de claves RSA de 2048, como las implementadas en el nuevo DNI Electrónico. El algoritmo RSA-2048 es equivalente en fortaleza a un algoritmo de clave simétrica de 112-bits pero requiere mucho más potencia de cálculo.

Aún, así el NIST vuelve a recomendar que se dejen de emplear la criptografía de 112-bit como muy tarde en el año 2030, aunque claro es solo una estimación.

La progresión de uso de los algoritmos de RSA con claves cada vez mayores, no parece sostenible. El tiempo (y potencia de calculo) requerido a medida que crecen la longitud de las claves crece rapidamente. El tiempo requerido para firmar es proporcional a la longitud de la clave elevada al cubo. Como ejemplo:

  • Las operaciones RSA-2048 requiere 8 veces más tiempo que sus equivalentes RSA-1024
    RSA-2048 (3DES) equivale a clave de 112-bit
  • RSA-3072 equivale a una clave de 128-bit (AES)
  • RSA-7680 equivale a una clave de 192-bit (AES)
  • RSA-15380 equivale a una clave AES de 256-bit

A pesar de este panorama, que puede parecer desolador, existen algoritmos alternativos de mayor fortaleza y rapidez y estan disponibles hoy. Estos algoritmos se han denominado Algoritmos Suite-B e incluye 3 componentes:

  • La criptografía de Curva Elíptica - Elliptical Curve Cryptography (ECC)
  • El protocolo de cifrado AES - Advanced Encryption Standard
  • Algoritmos de hash SHA-2

La criptografía de curva elíptica (ECC) fue inventada por Neil Koblitz y Victor Miller en 1985. Solo 8 años despues del algoritmo RSA. Ha sido estudiada durante lo últimos 20 años y se le reconoce su fortaleza y la estabilidad de sus fundamentos matemáticos. ECC ha sido estandarizada por organismos como el ISO y el IETF.

Se han definido 3 curvas y tamaños de claves: P-256, P-384 y P-521 con longitudes de claves de 256, 384 y 521 bits respectivamente. Estas curvas equivalen a claves AES de 256, 192 y 512 respectivamente.

En general ECC es equivalente en fortaleza a RSA pero requiere menos potencia de cálculo en sus operaciones.

  • P-256 equivale a RSA-3020
  • P-384 equivale a RSA-7680
  • P-521 equivale a RSA-15380

El rendimiento de ECC es tambien proporcional a la longitud de la clave elevada al cubo, pero al emplear claves más cortas su rendimiento mejora. P-256 es más rapido que RSA-2048.

Rames.