LA NECESIDAD DE ESTABLECER UN ENTORNO SEGURO

En la actualidad, la falta de medidas de seguridad en las redes es un problema que está en crecimiento. Cada vez es mayor el número de atacantes y cada vez están más organizados, por lo que van adquiriendo día a día habilidades más especializadas que les permiten obtener mayores beneficios en su labor de piratería.
Tal y como se avanzaba en la primera parte de este articulo, la criptografía por sí sola no es suficiente para prevenir los posibles ataques que se perpetran sobre las redes, sino que es necesario establecer unos mecanismos más complejos que utilizan los distintos sistemas criptográficos en sus cimientos. Pero el problema no queda solucionado instalando en una serie de servidores herramientas de seguridad, porque ¿quién tendría acceso a esas herramientas?, ¿a qué aplicaciones se aplicarían?, ¿qué sucedería si sólo uno de los dos interlocutores en una comunicación tiene acceso a herramientas de seguridad?. Por lo tanto, cuando se habla de seguridad en redes es necesario definir el entorno en el que se va a aplicar.

La definición de un entorno seguro implica la necesidad de estudiar varios aspectos y de establecer una infraestructura que dé soporte a los servicios de seguridad que se quieren proporcionar. Lo primero que hay que establecer es qué aplicaciones necesitan seguridad y cuántos servicios se necesitan. En segundo lugar hay que determinar cómo se van a proporcionar esos servicios, si van a ser transparentes al usuario, si se le va a dejar elegir el tipo de servicio, etc. También es necesario determinar en qué nivel se van a proporcionar, si en el nivel de aplicación o en niveles inferiores. Y sobre todo, tanto si se utiliza criptografía de clave secreta, como si se utiliza criptografía de clave pública es necesario diseñar un sistema de gestión de claves y definir una política que determine la forma en la que se debe operar.

Cuando se utiliza únicamente criptografía de clave simétrica, aunque el sistema de generación de claves suele ser sencillo, ya que no se requiere una gran infraestructura para soportarlo, los mecanismos de distribución de las claves suelen ser muy complejos. En este caso, los principales parámetros que hay que tener en cuenta son el modo de difundir la clave secreta de forma segura a las dos entidades que van a utilizarla y la frecuencia con la que se deben renovar las claves para evitar que sean desveladas.

Cuando se utiliza criptografía de clave pública, el sistema de gestión de claves se complica. En primer lugar es necesario almacenar las claves públicas en un lugar al que tengan libre acceso todos los usuarios que forman parte del entorno de seguridad. ITU, en su recomendación X.509, propone la utilización del Directorio para este fin; pero no todos los usuarios de seguridad tienen acceso al Directorio X.500, por lo que en muchos entornos es necesario crear o utilizar otro tipo de bases de datos.

El segundo problema que se plantea al utilizar criptosistemas de clave pública, es que las claves públicas, por el simple hecho de ser públicas, están expuestas a la manipulación por parte de todos los usuarios, por lo que es necesario buscar un mecanismo que permita confiar en su validez. Siguiendo el ejemplo de los actuales sistemas legales, aparece la figura de una autoridad de confianza que se encarga de certificar las claves públicas. Estas autoridades, conocidas con el nombre de Autoridades de Certificación (CA "Certification Authority"), emiten certificados de las claves públicas de los usuarios firmando con su clave secreta un documento, válido por un período determinado de tiempo, que asocia el nombre distintivo de un usuario con su clave pública. En la recomendación X.509 se define en sintaxis ASN.1 el siguiente modelo de certificado:

Certificate ::= SIGNED SEQUENCE{
version [0] Version DEFAULT 0,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
SubjectPublicInfo SubjectPublicInfo,
issuerUniqueId [1] IMPLICIT BIT STRING OPTIONAL,
SUBJECTUniqueId [1] IMPLICIT BIT STRING OPTIONAL}

Además, para que los usuarios puedan estar seguros de la validez de los certificados de las claves pública de sus interlocutores, la CA debe mantener una lista con los certificados emitidos por ella y que han sido revocados por detección de un uso fraudulento de la clave pública certificada o de la clave secreta asociada. Estas listas se conocen con el nombre de Listas de Certificados Revocados (CRL, "Certificate Revocation List").
Cuando la comunidad de usuarios crece, una sola CA puede verse desbordada por el número de certificados que tiene que gestionar. En otros casos, las empresas o instituciones quieren tener cierto control sobre la manera en que sus usuarios generan las claves, la caducidad de los certificados, etc. Esto hace conveniente distribuir las funciones de certificación entre varias CAs, cuya política de seguridad puede ser diferente. En la recomendación X.509 ya se prevé la necesidad de una organización de CAs donde se certifiquen unas a otras, sin indicar el tipo de relación organizativa que se debe establecer entre ellas. De esta forma, dependiendo de las necesidades de cada entorno han aparecido distintos modelos de organización de CAs.

Volver a Seguridad

Miguel A. Ruz
miguelruz@delitosinformaticos.com