La seguridad informática ha sido víctima del síndrome del "año del...". Primero fueron los contrafuegos, después los sistemas de detección de intrusiones, luego las VPN [Redes Privadas Virtuales], y ahora se trata de las autoridades de certificación (ACs) y la infraestructura de clave pública (ICP). "Tan sólo con que compres X", dice el vendedor, "estarás seguro." Pero en realidad nunca es tan simple, y esto es especialmente cierto con la ICP.

Los certificados proporcionan un modelo de negocios atractivo. Cuestan casi nada de hacer, y si puede usted convencer a alguien de que compre un certificado cada año por cinco dólares, eso multiplicado por la población de Internet constituye un gran ingreso anual. Si convence usted a alguien de que compre una AC privada y te pague una tasa por cada certificado que emita, también le irá bien. No es de extrañar que tantas empresas intenten sacar tajada de este mercado potencial. Con tanto dinero en juego, tampoco es de extrañar que casi toda la bibliografía y los cabildeos del tema sean producto de los vendedores de ICP. Y la bibliografía deja algunas cuestiones básicas sin respuesta: ¿cuán buenos son los certificados, a fin de cuentas? ¿Son seguros? ¿Para qué? En este ensayo, esperamos explorar algunas de estas cuestiones.

La seguridad es una cadena; es solamente tan fuerte como su eslabón más débil. La seguridad de cualquier sistema basado en AC se basa en muchos enlaces, y no todos ellos son de naturaleza criptográfica. Hay gente involucrada.

¿Ayuda el sistema a esa gente, la confunde o simplemente la ignora? ¿Se basa de forma inapropiada en la honradez o minuciosidad de la gente? Hay ordenadores involucrados. ¿Son esos sistemas seguros? Todos trabajan juntos en un proceso conjunto. ¿Está este proceso diseñado para maximizar la seguridad o simplemente los beneficios?

Cada una de estas preguntas puede indicar riesgos de seguridad que han de ser atendidos.

Antes de comenzar: ¿necesitamos siquiera una ICP para el comercio electrónico? Abra usted cualquier artículo sobre ICP en la prensa popular o técnica, y muy probablemente encontrará la declaración de que se necesita desesperadamente la ICP para que el comercio electrónico florezca. Esta declaración es flagrantemente falsa. El comercio electrónico ya está floreciendo, y no hay tal ICP. Las páginas web son felices con tomar nota del pedido, tenga usted un certificado o no. Con todo, al igual que con muchas otras declaraciones falsas, hay una verdad relativa: las ICP comerciales necesitan desesperadamente el comercio electrónico para florecer. En otras palabras, las ICP que comienzan necesitan afirmar que son esencial para el comercio electrónico si quieren obtener inversores.

Resulta arriesgado creer en esta popular falsedad. El riesgo inmediato está del lado de los inversores. Los riesgos de seguridad son sobrellevados por cualquiera que decida usar realmente el producto de una ICP comercial.


Riesgo nº 1: ¿En quién confiamos, y por qué?

Hay un riesgo inherente en el uso impreciso de la palabra confianza. Una AC es a menudo definida como "de confianza."

En la bibliografía sobre criptografía, esto solamente significa que organiza sus propias claves adecuadamente. Esto no significa que deba usted confiar en un certificado de una AC para un propósito concreto: hacer un micropago o firmar una orden de pago de un millón de dólares.

¿Quién dio a la AC la autoridad para emitir tales autorizaciones? ¿Quién la hizo de confianza?

Una AC puede hacer un gran trabajo cuando escribe una Declaración de Práctica de Certificación, o DPC (todas las que hemos leído nosotros declican toda responsabilidad y todo significado respecto al certificado), y luego hacen un gran trabajo siguiendo esa DPC, pero eso no significa que usted pueda confiar en un certificado para sus necesidades. Muchas ACs sortean la cuestión -de no tener autoridad para delegar autorizaciones- mediante la emisión de certificados de identificación. Cualquiera puede asignar nombres. Todos lo hacemos todo el tiempo. Esto deja el riesgo en las manos del verificador del certificado, caso de que éste usase un certificado de identiricación como si éste implicase alguna clase de autorización.

Hay quienes incluso intentan inducir a un cliente de ICP a hacer precisamente eso. Su lógica es: (1) usted tiene un certificado de identificación, (2) eso le da a usted el nombre del propietario de la clave, (3) eso significa que usted sabe quién es el propietario de la clave, (4) eso es lo que usted necesita saber. Por supuesto, eso no es lo que usted necesita saber. Además, los pasos lógicos de 1 a 2, de 2 a 3 y de 3 a 4 tienen fallos (dejaremos al lector el encontrar esos fallos).


Riesgo nº 2: ¿Quién usa mi clave?

Uno de los mayores riesgos en cualquier sistema basado en AC está dentro de la propia clave privada de firmado de usted. ¿Cómo protegerla? Seguro que usted no posee un ordenador seguro con controles de acceso físico, apantallamiento TEMPEST, seguridad de redes con "pared de aire" y otrsa protecciones: usted almacena su clave privada en un ordenador convencional. Allí es susceptible de ataques por virus y otros programas maliciosos. Aunque su clave privada esté segura en su ordenador, ¿está el ordenador en una habitación cerrada, con videovigilancia, de forma que usted pueda estar seguro de que nadie más lo use? Si está protegido mediante contraseña, ¿cuán difícil es de adivinar dicha contraseña? Si la clave está almacenada en una tarjeta inteligente, ¿cúan resistente a ataques es la tarjeta? (la mayorías son muy débiles). Si está almacenada en un dispositivo realmente resistente a ataques, ¿puede un ordenador infectado hacer que el ingenio confiable firme algo que usted no pretenda firmar?

Esto importa sobre todo debido al término "no repudio." Como "confianza", este término está sacado de la bibliografía de criptografía académica. Ahí significa algo muy específico: que el algoritmo de firma digital no sea reventable, de forma que un tercero no pueda falsificar su firma. Los vencedores de ICP se han pegado al término y lo usan en sentido legal, cabildeando para conseguir leyes de forma que, si alguien usa la clave privada de firmado de usted, entonces usted no puede repudiar la firma. En otras palabras, bajo algunas leyes de firma digital (p. ej. en Utah y Washington), si la clave de firma de usted ha sido certificada por una AC autorizada, entonces usted es responsable de cualquier cosa que haga esa clave privada. No importa quién estaba en el teclado del ordenador, o qué virus hizo la forma; usted es responsable desde el punto de vista legal.

Contraste esto con la práctica habitual en el caso de tarjetas de crédito. Bajo las reglas [norteamericanas] de órdenes de compra mediante correo o por teléfono, si usted pone objeciones a algo cargado a tarjeta de crédito, usted tiene el derecho de repudiarlo -decir que usted no lo compró- y el vendedor debe demostrar que usted lo compró.


Riesgo nº 3: ¿Cuán seguro es el ordenador verificador?

La sección anterior mostró que el ordenador que tiene o ejecuta la clave privada debe ser seguro. Las claves largas no sirven en un sistema inseguro porque la seguridad total es más débil que el componente más débil del sistema.

Lo mismo puede decirse del ordenador verificador, el que usa el certificado.

La verificación del certificado no usa una clave secreta, solamente claves públicas.

Por tanto, no hay secretos que proteger. No obstante, sí usará una o más claves públicas "raíz". Si el atacante puede añadir su propia clave pública a esa lista, podrá emitir sus propios certificados, los cuales serán tratados exactamente como los legítimos. Incluso puede hacer certificados iguales en todos los campos excepto en que contendrían una clave pública del atacante en lugar de la correcta.

No sirve tener estas claves raíz en "certificados raíz." Dichos certificados están firmados por sí mismos, y no proporcional mayor seguridad. La única respuesta es hacer todas las verificaciones de certificados en un sistema informático invulnereable a la penetración por parte de código hostil o a la intrusión física.


Riesgo nº 4: ¿Cuál de los John Robinson es éste?

Los certificados suelen asociar una clave pública con un nombre, pero pocas personal hablan acerca de la utilidad de esa asociación. Imagínese que usted recibe el certificado de John Robinson. Puede que usted conozca solamente a un John Robinson personalmente, pero ¿cuántos conoce esa AC? ¿Cómo puede usted averiguar si el certificado de ese John Robinson en particular es el certificado de su amigo? Puede que usted haya recibido su clave pública en persona, o verificado ésta en persona (PGP permite hacer esto), pero es más probable que usted haya recibido un certificado por correo electrónico y que simplemente confía en que ese es el John Robinson correcto. El Nombre Común del certificado probablemente irá acompañado de otra información para que sea único entre los nombres certificados por esa AC.

¿Conoce usted esa otra información acerca de su amigo? ¿Sabe de qué AC debería venir ese certificado?

Cuando Diffie y Hellman introdujeron la criptografía de clave pública, propusieron una guía telefónica modificada, en la cual podrían hallarse claves públicas. En lugar de nombre, dirección y número de teléfono, contendría nombre, dirección y clave pública. Si ustes quisiese hallar la clave pública de John Robinson buscaría en la guía, obtendría su clave pública y le enviaría un mensaje "solamente para sus ojos" usando esa clave pública. Eso pudiera haber funcionado con el listín telefónico del Departamento de Informática de Stanford en 1976, pero ¿cuántos John Robinsons hay en la guía telefónica de Nueva York, por no hablar de una guía hipotética para la Internet global?

Crecemos en familias pequeñas donde los nombre funcionan como identificadores. Para cuando tenemos cinco años de edad, sabemos esa lección. Los nombre funcionan. Eso es falso en el gran mundo, pero las cosas que aprendemos de pequeñajos nunca se olvidan. En este caso, necesitamos pensar cuidadosamente acerca de los nombres y no aceptar ciegamente su valor mediante las lecciones esculpidas en nuestra memoria cuando teníamos cinco años.


Riesgo nº 5: ¿Es la AC una autoridad?

La AC puede ser una autoridad en la emisión de certificados, pero ¿es una autoridad acerca de aquello que el certificado contiene? Por ejemplo, un certificado de servidor SSL contiene dos datos de potencial interés de seguridad: el nombre del propietario de la clave (por lo general, el nombre de una empresa) y el nombre DNS del servidor. Hay autoridades sobre asignaciones de DNS, pero ninguna de las ACs de SSL listadas en los navegadores habituales es una autoridad así. Esto significa que el nombre DNS del certificado no es algo autoritativo. Hay autoridades sobre nombres de empresas. Esos nombres no necesitan estar registradas cuando uno obtiene una licencia comercial. No obstante, ninguna de las AC de SSL listadas en los navegadores es una autoridad así. Además de ello, cuando un servidor tiene un certificado de servidor SSL, tiene permiso para hacer SSL. ¿Quién dio a la AC de SSL autoridad para controlar ese permiso? ¿Es siquiera necesario el control de ese permiso? Sirve a un fin económico (generar un flujo de ingresos para las AC), pero ¿sirve a un fin de seguridad? ¿Qué daño se hace si un servidor no certificado fuese autorizado a usar cifrado? Ninguno.


Riesgo nº 6: ¿Es el usuario parte del diseño de seguridad?

¿Acaso la aplicación que usa certificados tiene en cuenta al usuario, o se preocupa solamente de criptografía?

Por ejemplo, un usuario habitual toma la decisión de comprar en una página web dada, protegida con SSL, basándose en lo que se muestra en esa página. El certificado no se muestra, y no guarda necesariamente relación con lo que se muestra. La seguridad SSL no tiene la capacidad de controlar, o incluso reaccionar a, el contenido de la página web, solamente su dirección DNS. El nombre de la empresa ni siquiera se compara con nada que el usuario ve, y hay algunas páginas web cuyos certificados son para una compañía que aloja páginas web, no para la compañía cuyo logotipo se muestra en la página. Los usuarios no se aperciben de todo esto, y no se puede esperar que lo hagan.


Riesgo nº 7: ¿Era una AC o una AC mas una Autoridad de Registro?

Algunas AC, en respuesta al hecho de que no son autoridades en el contenido de los certificados, han creado una estructura certificadora en dos partes: una Autoridad de Registro (AR), manejada por la autoridad en los contenidos, que está en comunicación segura con la AC que solamente emite certificados. Otros vendedores venden maquinaria de AC directamente a la autoridad en contenidos.

El modelo AR+AC es categóricamente menos seguro que un sistema con una AC en la mesa de la autoridad. El modelo AR+AC permite que una entidad (la AC) que no es una autoridad en contenidos pueda falsificar un certificado con dichos contenidos. Por supuesto, la AC firmará un contrato prometiendo no hacer eso, pero eso no elimina la capacidad de hacerlo. Mientras tanto, ya que la seguridad de una cadena es más débil que el eslabón más débil, la AR+AC es menos seguro que la AR o la AC, no importa lo fuerte que sea la AC o lo bueno que sea el contrato con la AC. Por supuesto, el modelo con una AC en la mesa de autoridad (no en el emplazamiento del vendedor) viola los modelos de negocios de algunos vendedores de ICP. Es más difícil cobrar por certificados cuando usted vende a alguien el código de AC (o cuando éste alguien puede conseguirlo gratis, como Código Abierto).


Riesgo nº 8: ¿Cómo identificó la AC al dueño del certificado?

Sea que un certificado contenga solamente un identificador o alguna autorización específica, la AC necesita identificar al peticionario del certificado antes de emitirlo.

Hubo una oficina de crédito que creyó poder meterse en el negocio de las ICP.

Después de todo, tenían una vasta base de datos acerca de mucha gente, así que pensaron poder establecer la identidad de alguien on-line con facilidad. Si alguien quisiese establecer su identidad on-line, podría hacerse suponiendo que se tuviese algún secreto compartido con ese alguien y un canal seguro de comunicación por el cual revelar ese secreto. SSL proporcional el canal seguro.

El problema con una oficina de crédito que quisiese hacer eso es que, en su vasta base de datos, no hay ni un secreto compartido con el sujeto. Esto se debe a que las oficinas de crédito están en el negocio de vender la información que poseen a terceros. Peor aún, ya que las oficinas de crédito son tan competentes al recoger y vender datos sobre personas, otros que tengan esa información sobre una persona lo tendrán difícil a la hora de encontrar cualquier dato compartido con el sujeto que no esté ya disponible a través de otras oficinas de crédito. Esto pone en peligro ACs comerciales que usan información de oficinas de crédito para verificar identidades on-line; el modelo, sencillamente, no funciona.

Mientras tanto, una vez que el peticionario del certificado ha sido identificado de un modo o de otro, ¿cómo verifica la AC que el peticionario realmente controla la clave privada correspondiente a la clave pública que está siendo certificada? Algunas AC ni siquiera tienen en consideración esto a la hora de formar parte del proceso de petición de certificación. Otras pudieran exigir que el peticionario firme algo en ese mismo momento, mientras la AC observa.


Riesgo nº 9: ¿Cuán seguras son las prácticas de certificación?

Los certificados no son elixires mágicos de seguridad, con los que simplemente se añade una gota a tu sistema para convertirlo en seguro.

Los certificados deben usarse con propiedad si se quiere seguridad. ¿Se diseñan las prácticas de certificación por sólidos motivos de seguridad, o simplemente son rituales o imitaciones del comportamiento de otro? Muchas de tales prácticas, e incluso partes de algunos estándares, son tan sólo imitaciones que, cuando se rastrean con cuidado, comenzaron como elecciones arbitrarias por gente que no intentaba conseguir una respuesta de verdad.

¿Cómo se computa la vida de una clave? ¿Usa el vendedor un año tan sólo porque es lo habitual? Una clave tiene una vida criptográfica. También tiene una vida de robo, como función de la vulnerabilidad del subsistema que la almacena, la tasa de exposición física y de red, el valor de la clave frente a un atacante, etc. A partir de esto, uno puede calcular la probabilidad de pérdida de la clave como función del tiempo y del uso. ¿Hizo el vendedor ese tipo de cálculo? ¿Qué umbral de probabilidad se usa para considerar una clave como inválida?

¿Incluye el vendedor revocación de certificados o de claves? Las Listas de Revocación de Certificados (LRC) se construyen mediante estándares certificados, pero muchas implementaciones las evitan porque parecen ser remanentes arcaicos de las listas impresas con números de cuenta malos que se usaban en los cajeros de los supermercados. Como esas listas, se considera a las LRC como demasiado grandes y pasados de fecha para ser relevantes. Sin embargo, si no se usan las LRC, ¿cómo se administra la revocación?

Si la revocación se administra, ¿cómo se detecta que una clave ha sido comprometida, con objeto de activar dicha revocación? ¿Puede la revocación tener carácter retroactivo?. Esto es, ¿puede el propietario de un certificado negar haber hecho una firma en el pasado? De ser así, ¿se fechan las firmas para que se puedan distinguir las firmas buenas de las sospechosas? ¿Es ese fechado efectuado por un servicio de fechado seguro?

¿Qué tamaño tienen las claves públicas generadas, y por qué se escogió esa longitud? ¿Soporta el vendedor claves RSA de 512 bits tan sólo porque son rápidas, o las de 2048 bits porque alguien de allí en la esquina dijo que creía que eran seguras?

¿Son necesaria acciones por parte del usuario para que los certificados sean usados correctamente? ¿Llevan los usuarios a cabo estas acciones? Por ejemplo, cuando uno establece una conexión SSL mediante el navegador, hay una indicación visual de que el protocolo SSL funcionó y de que la conexión está cifrada. Pero ¿con quién está uno conectándose de manera segura? A menos que uno se tome el tiempo para leer el certificado recibido, no puede saberse.

Incluso en ese caso, puede no saberse (ver riesgo nº 4), pero si uno ni siquiera mira, es como entrar en una habitación privada con las luces apagadas: puede uno saber que hay alguien más allí y la conversación es privada, pero hasta que usted sepa quién es la otra persona, no debería revelarse información secreta.


Riesgo nº 10: Y a fin de cuentas, ¿por qué estamos usando el proceso AC?

Un empleado de un vendedor de ICP nos comentó confidencialmente hace algunos ahos que tenían gran éxito vendiendo su solución de ICP, pero que los clientes seguían sin estar contentos.

Después de que se instalase la AC y todos los empleados hubiesen recibido certificados, el cliente se fue al vendedor de ICP y pregunto: "vale, ¿cómo hacemos una firna única?" La respuesta fue: "No puede. Eso requeriría un cambio en el software del sistema a escala masiva"

La Firma Única [SSO, Single Sign-On] puede ser matadora para la ICP. Bajo la SSO, uno llega a trabajar por la mañana, inserta su tarjeta inteligente, entra el número de identificación PIN que la activa, y durante el resto del día no hay que hacer más "login". Todo lo hace el mecanismo SSO.

Actractivo, ¿no? Claro que es atractivo. La autenticación es un latazo.

Todo lo que podamos hacer para evitarlo, lo haremos.

Desafortunadamente, el valor de seguridad proveniente de autenticación queda anulado por ls SSO. Se supone que la autenticación demuestra que el usuario está presente frente al ordenador que controla el proceso, en el momento de la prueba. Con la SSO, si el usuario tiene que salir corriendo al servicio, cualquier persona que pase podría sentarse frente al ordenador y conectarse por medio del mecanismo SSO.

Con eso, ¿por qué no tanta gente se apunta al proceso AC con tal fervor? ¿Usan certificados debido a un ritual vacío, solamente porque el otro tío lo hace y es lo que está de moda este año? ¿Lo hacen para pasar el testigo de la responsabilidad, esto es, para poder culpar a los expertos en ICP si hay cualquier pega de seguridad?

No somos tan cínicos. Nuestra valoración es que la seguridad es muy difícil, no sólo de comprender sino de implementar. Los administradores de sistema atareados no tienen tiempo de comprender realmente la seguridad. Leen los informes para la prensa del ramo. Esa prensa, influenciada por los vendedores de ICP, canta las alabanzas de las ICP. Y los vendedores de ICP saben lo que la gente ocupada necesitan: una solución de impacto mínimo. "Eh, compra esto y estarás seguro." Así que eso es lo que ofrecen. La realidad se queda corta respecto a esas promesas, pero en fin, esto es un negocio y las voces prominentes son las que tienen algo que vender. Caveat emptor.


Bruce Scineier es el autor de Applied Cryptography, los algoritmos de cifrado Blowfish y Twofish, y de docenas de informes de investigación y artículos sobre criptografía y seguridad informática. Es el director ejecutivo de Counterpane Internet Security Inc, una empresa de servicios de seguridad que ofrecen asesoramiento de alto nivel en los campos de detección y prevención de intrusos, descubrimiento preventivo de amenazas, investigación forense y análisis de sistemas de información y telecomunicaciones.

Puede usted suscribirse a su boletín electrónico mensual gratuito, Crypto-Gram, en http://www.counterpane.com

Carl M. Ellison es Arquitecto de Seguridad en la Intel Corporation, con dedicación especial en criptografía, control criptográfico de acceso y certificados de clave pública. Antes de dedicarse a la criptografía, su carrera profesional informática se centraba en diseño de sistemas, con énfasis en los sistemas distribuidos y en red.