Anda di halaman 1dari 434

www.FreeLibros.

org
www.FreeLibros.org
FUNDAMENTOS DE SEGURIDAD
EN REDES
APLICACIONES Y ESTNDARES
Segunda edicin
www.FreeLibros.org
www.FreeLibros.org
FUNDAMENTOS DE SEGURIDAD
EN REDES
APLICACIONES Y ESTNDARES
Segunda edicin
William Stallings
Revisin tcnica:
Manuel Gonzlez Rodrguez
Facultad de Informtica
Universidad de las Palmas de Gran Canaria
Luis Joyanes Aguilar
Universidad Pontificia de Salamanca, campus de Madrid
Traduccin:
Laura Cruz Garca
Facultad de Informtica
Universidad de Las Palmas de Gran Canaria
Manuel Gonzlez Rodrguez
Facultad de Informtica
Universidad de las Palmas de Gran Canaria
P E AR S ON
Prentice
Hall
Madrid Mxico Santaf d e Bogot Buenos Aires Caracas Lima Montevideo
San Juan San Jos Santiago Sao Paulo White Plains
www.FreeLibros.org
_______________________________ / E&tos de catalogacin bibliogrfica
STALLINGS, W.
FUNDAMENTOS DE SEGURIDAD E N REDES.
APLICACIONES Y ESTNDARES.
Segunda edicin
PEARSON EDUCACIN, S.A., Madrid, 2004
ISBN: 84-205-4002-1
Materia: Informtica 681.3
Formato: 170 x 240 fginas: 432
Todos los derechos reservados.
Queda prohibida, salvo excepcin prevista en la Ley, cualquier forma
de reproduccin, distribucin, comunicacin pblica y transformacin
de esta obra sin contar con autorizacin de los titulares de propiedad intelectual.
La infraccin de los derechos mencionados puede ser constituti va de delito
contra la propiedad intelectual (arts. 270 y sgts. Cdigo Penal).
DERECHOS RESERVADOS
O 2004 por PEARSON EDUCACIN, S.A.
Ribera del Loira, 28
28042 Madrid (Espaa)
FUNDAMENTOS DE SEGURIDAD EN REDES. APLICACIONES Y ESTNDARES. Segunda edicin
STALLINGS, W.
ISBN: 84-205-4002-1
Depsito Legal: M-
PEARSON PRENTICE HALL es un sello editorial autorizado de PEARSON EDUCA CIN, S. A.
Traducido de:
NetWork Security Essentials. Applications and Standars. Second edition, by Stallings, William.
Published by Pearson Education, Inc., publishing as Prentice Hall.
2003. All rights reserved. No part o f this book may be reproduced o r transmitted in an y form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from Pearson Education, Inc.
Equipo editorial:
Director: David Fayerman Aragn
Tcnico editorial: Ana Isabel Garca Borro
Equipo de produccin:
Director: Jos Antonio Clares
Tcnico: Jos Antonio Hernn
Diseo de cubierta: Equipo de diseo de Pearson Educacin, S.A.
Composicin: Claroscuro Servicio Grfico, S.L.
Impreso por:
IMPRESO EN ESPAA - PRINTED IN SPAIN
Este libro ha sido impreso con papel y tintas ecolgicos
www.FreeLibros.org
Contenido
Prlogo ............................................................................................................................. IX
Captulo 1. Introduccin ............................................................................................ 1
1.1. La arquitectura de seguridad O S I ........................................................................ 4
1.2. Ataques a la seguridad........................................................................................... 5
1.3. Servicios de seguridad........................................................................................... 9
1.4. Mecanismos de seguridad...................................................................................... 13
1.5. Un modelo de seguridad en redes........................................................................ 14
1.6. Estndares de Internet y la Sociedad Internet ................................................... 17
1.7. Estructura del libro ................................................................................................. 21
1.8. Bibliografa recomendada...................................................................................... 22
1.9. Recursos web y de Internet .................................................................................. 22
PRIMERA PARTE
Criptografa
Captulo 2. Cifrado simtrico y confidencialidad de mensajes........................ 27
2.1. Principios del cifrado simtrico............................................................................ 28
2.2. Algoritmos de cifrado simtrico.......................................................................... 34
2.3. Modos de operacin del cifrado de bloques........................................................ 44
2.4. Ubicacin de los dispositivos de cifrado............................................................ 48
2.5. Distribucin de claves............................................................................................ 49
2.6. Bibliografa y sitios web recomendados............................................................. 51
2.7. Palabras clave, preguntas de repaso y problemas............................................. 52
Captulo 3. Criptografa de clave pblica y autentifcacin de mensajes .. 55
3.1. Enfoques para la autentifcacin de mensajes................................................... 56
3.2. Funciones hash seguras y HMAC ....................................................................... 61
3.3. Principios de criptografa de clave pblica ....................................................... 71
3.4. Algoritmos de criptografa de clave pblica ..................................................... 75
3.5. Firmas digitales....................................................................................................... 81
3.6. Gestin de claves.................................................................................................... 82
3.7. Bibliografa y sitios web recomendados............................................................. 84
3.8. Trminos clave, preguntas de repaso y problemas........................................... 85
www.FreeLibros.org
VI ndice de contenido
SEGUNDA PARTE
Aplicaciones de seguridad en redes
Captulo 4. Aplicaciones de autentiflcacin......................................................... 91
4.1. Kerberos.................................................................................................................... 92
4.2. Servicio de autentiflcacin de X.509.................................................................. 111
4.3. Bibliografa y sitios web recomendados............................................................. 121
4.4. Trminos clave, preguntas de repaso y problemas ........................................... 121
Apndice 4A. Tcnicas de cifrado Kerberos............................................................ 123
Captulo 5. Seguridad en el correo electrnico................................................... 127
5.1. PGP (Pretty Good Privacy).................................................................................. 128
5.2. S/MIME ................................................................................................................... 149
5.3. Sitios web recomendados ...................................................................................... 167
5.4. Trminos clave, preguntas de repaso y problemas........................................... 167
Apndice 5A. Compresin de datos usando Z i p ..................................................... 168
Apndice 5B. Conversin RADIX 64 ....................................................................... 171
Apndice 5C. Generacin de nmeros aleatorios PGP .......................................... 173
Captulo 6. Seguridad IP - ......................................................................................... 177
6.1. Introduccin a la seguridad I P .............................................................................. 178
6.2. Arquitectura de seguridad IP ................................................................................ 181
6.3. Cabecera de autentiflcacin.................................................................................. 188
6.4. Encapsulamiento de la carga til de seguridad ................................................. 192
6.5. Combinacin de asociaciones de seguridad...................................................... 198
6.6. Gestin de claves.................................................................................................... 201
6.7. Bibliografa y sitios web recomendados............................................................. 212
6.8. Trminos clave, preguntas de repaso y problemas .......................................... 212
Apndice 6A. Comunicacin entre redes y protocolos de Internet...................... 214
Captulo 7. Seguridad de la w e b .............................................................................. 223
7.1. Consideraciones sobre seguridad en la w e b ...................................................... 224
7.2. SSL (Secure Socket Layer) y TLS (Transpon Layer Security)...................... 227
7.3. SET (Secure Electronic Transactior)................................................................. 246
7.4. Bibliografa y sitios web recomendados............................................................. 258
7.5. Palabras clave, preguntas de repaso y problemas............................................. 259
Captulo 8. Seguridad en la gestin de redes ...................................................... 261
8.1. Conceptos bsicos de SNMP................................................................................ 262
8.2. Comunidades SNMP vi ......................................................................................... 270
8.3. SNMPv3................................................................................................................... 272
8.4. Bibliografa y sitios web recomendados............................................................. 298
8.5. Trminos clave, preguntas de repaso y problemas........................................... 298
www.FreeLibros.org
ndice de contenido VII
TERCERA PARTE
Seguridad de los sistemas
Captulo 9. Intrusos .................................................................................................... 305
9.1. Intrusos................................................................................................................... 306
9.2. Deteccin de intrusos........................................................................................... 310
9.3. Gestin de contraseas ....................................................................................... 323
9.4. Bibliografa y sitios web recomendados.......................................................... 332
9.5. Trminos clave, preguntas de repaso y problemas ........................................ 334
Apndice 9A. La falacia de la tasa base.................................................................... 336
Captulo 10. Software d a i n o ................................................................................... 341
10.1. Virus y otras amenazas....................................................................................... 342
10.2. Contramedidas a los virus .................................................................................. 353
10.3. Bibliografa y sitios web recomendados.......................................................... 358
10.4. Trminos clave, preguntas de repaso y problemas ........................................ 359
Captulo 11. Cortafuegos........................................................................................... 361
11.1. Principios de diseo de cortafuegos................................................................. 362
11.2. Sistemas de confianza.......................................................................................... 374
11.3. Bibliografa y sitios web recomendados.......................................................... 380
11.4. Trminos clave, preguntas de repaso y problemas ........................................ 381
APNDICE A Estndares citados en este l i b r o ................................................. 383
A.1. Estndares ANS I ................................................................................................... 383
A.2. RFC de Internet.................................................................................................... 383
A.3. Recomendaciones ITU-T.................................................................................... 385
A.4. Estndares de procesamiento de informacin de NIST................................. 385
APNDICE B Algunos aspectos de la teora de nmeros ............................... 387
B. 1. Nmeros primos y primos relativos................................................................. 3 88
B.2. Aritmtica modular.............................................................................................. 390
Glosario.............................................................................................................................. 393
Referencias ....................................................................................................................... 399
Indice analtico ................................................................................................................ 405
www.FreeLibros.org
www.FreeLibros.org
Prlogo
La corbata, s me permite la sugerencia, seor, lleva el nudo ms apretado. Se per
sigue el efecto mariposa perfecto. Me permite?
Qu importa, Jeeves, en un momento como ste?Es que no ves cmo se tamba
lea la felicidad domstica de Mr. Little?
Seor, no hay momento en e l que las corbatas no importen.
M uy bien, Jeeves! P. G. Wodehouse
E
n esta era de la conectividad electrnica universal, de virus y hackers, de escuchas
y fraudes electrnicos, no hay un momento en el que no importe la seguridad. Dos
tendencias han confluido para hacer de inters vital el tema de este libro. En pri
mer lugar, el enorme crecimiento de los sistemas de computadores y sus interconexio
nes mediante redes ha hecho que organizaciones e individuos dependan cada vez ms de
la informacin que se almacena y se transmite a travs de estos sistemas. Esto, a su vez,
ha llevado a un aumento de la conciencia de la necesidad de proteger los datos y los re
cursos, de garantizar la autenticidad de los datos y los mensajes y de proteger los siste
mas frente a ataques a la red. En segundo lugar, las disciplinas de la criptografa y la se
guridad de la red han madurado, dando como resultado el desarrollo de aplicaciones
prcticas, ya disponibles, para la seguridad de la red.
OBJETIVOS
El propsito de este libro es proporcionar un estudio prctico sobre las aplicaciones y
los estndares relativos a la seguridad de la red. Se resaltan, por una parte, las aplica
ciones que ms se utilizan en Internet y en las redes corporativas y, por otra, los estn
dares ms extendidos, especialmente los de Internet.
www.FreeLibros.org
X Prlogo
DESTINATARIOS
El libro est destinado a una audiencia tanto acadmica como profesional. Como libro
de texto, est diseado para cubrir un curso de un semestre sobre seguridad en redes para
estudiantes universitarios de ciencias de la computacin, ingeniera de la computacin e
ingeniera elctrica. Tambin sirve como libro bsico de referencia y es adecuado para
el aprendizaje autnomo.
ORGANIZACIN DEL LIBRO
El libro se divide en tres partes:
M m a parte Criptografa: consiste en un estudio conciso de los algoritmos y
protocolos criptogrficos que subyacen a las aplicaciones de seguridad en la red, inclu
yendo el cifrado, las funciones hash las firmas digitales y el intercambio de claves.
Seguida parte Aplicaciones de seguridad en redes: cubre herramientas y aplica
ciones importantes de seguridad en la red, incluyendo Kerberos, los certificados
X.509v3, PGP, S/MIME, seguridad IP, SSL/TLS, SET y SNMPv3.
Tercera parte Segmdad de los sistemas observa los aspectos de seguridad en el
mbito de los sistemas, que incluyen las amenazas de intrusos y virus y sus contrame
didas, y el uso de cortafuegos y sistemas confiables.
Adems, el libro incluye un Glosario extenso, una lista de Acrnimos frecuentes y
una Bibliografa. Cada captulo ofrece problemas, preguntas de repaso, una lista de pa
labras que hacen referencia a conceptos fundamentales, as como lecturas y sitios web
recomendados.
Al principio de cada una de las partes del libro se presenta un resumen ms detalla
do de cada captulo.
SERVICIOS DE INTERNET PARA DOCENTES Y ESTUDIANTES
Existe una pgina web para este libro que proporciona apoyo a los estudiantes y a los do
centes. La pgina incluye enlaces a sitios relevantes, las transparencias en formato PDF
(Adobe Acrobat) de las figuras y tablas que se muestran en el libro e informacin para re
gistrarse en la lista de correo de Internet de este libro. La direccin de la pgina web es
WilliamStallings.com/NetSec2e.html. Adems, se ha creado una lista de correo para que
los docentes que utilicen este libro puedan intercambiar, entre ellos y con el autor, infor
macin, sugerencias y preguntas. En WilliamStallings.com se dispone de una lista de
erratas para incluir aquellos errores tipogrficos o de cualquier otra ndole que se detec
ten. Tambin, la pgina Computer Science Student Resource (recursos para estudiantes de
ciencias de la computacin), en WilliamStallings.com/StudentSupport.html. proporciona
documentos, informacin y enlaces tiles para estudiantes y profesionales.
www.FreeLibros.org
Prlogo XI
PROYECTOS PARA LA ENS E AN ZA DE LA SEGURIDAD EN LA RED
Para muchos docentes, una parte importante de un curso sobre criptografa o seguridad
lo constituye un proyecto o conjunto de proyectos mediante los cuales los estudiantes
puedan realizar actividades experimentales para reforzar los conceptos del libro. Este li
bro proporciona un grado incomparable de apoyo para incluir un componente de pro
yectos en el curso. El manual del docente no slo aporta una gua sobre cmo asignar y
estructurar los proyectos, sino que tambin incluye una serie de propuestas de proyec
tos que cubren una amplia gama de temas que trata el texto:
Proyectos de investigacin: una serie de ejercicios de investigacin que instruyen al
alumno para investigar un tema en particular sobre Internet y escribir un informe.
Proyectos d e programacin: una serie de proyectos de programacin que cubren
un amplio abanico de temas y que se pueden implementar en un lenguaje adecua
do en una plataforma.
Ejercicios de lectura y redaccin de informes: una lista de artculos sobre el
tema, uno para cada captulo, que se pueden asignar para que los estudiantes los
lean y despus escriban un breve informe.
Vase Apndice B.
RELACIN CON CRYPTOGRAPHY A N D NETWORK SECURITY,
TERCERA EDICIN
Este libro es un producto derivado de Cryptography andNetwork Security Tercera Edi
cin. Dicha obra proporciona un tratamiento sustancial de la criptografa, incluyendo, en
400 pginas, un anlisis detallado de los algoritmos y el componente matemtico signi
ficativos. Fundamentos de Seguridad en Redes de Computadores: Aplicaciones y Es
tndares ofrece una introduccin concisa de estos temas en los Captulos 2 y 3. Tambin
incluye todo el material restante del otro libro. Adems, cubre la seguridad SNMP, que
tambin se trata en Cryptography and Network Security As, este libro est diseado
para universitarios y para profesionales con un inters especial en la seguridad de la red,
sin la necesidad o el deseo de ahondar en la teora y los principios de la criptografa.
www.FreeLibros.org
www.FreeLibros.org
C A P T U L O 1
Introduccin
1.1. La arquitectura de segundad OSI
1.2. Ataques a la seguridad
A t a q u e s p a s i v o s
A t a q u e s a c t i v o s
1.3. Servicios de seguridad
A u t e n t i f i c a d o n
C o n t r o l d e a c c e s o
C o n f i d e n c i a l i d a d d e l o s d a t o s
I n t e g r i d a d d e l o s d a t o s
N o r e p u d i o
S e r v i c i o d e d i s p o n i b i l i d a d
1.4. Mecanismos de seguridad
1.5. Un modelo de segundad en redes
1.6. Estndares de Internet y la Sociedad Internet
La s o r g a n i z a c i o n e s d e I n t e r n e t y l a p u b l i c a c i n d e l o s RFC
El p r o c e s o d e e s t a n d a r i z a c i n
C a t e g o r a s d e e s t n d a r e s d e I n t e r n e t
O t r o s t i p o s d e RFC
1.7. Estructura del libro
1.8. Bibliografa recomendada
1.9. Recursos web y de Internet
S i t i o s w e b p a r a e s t e l i b r o
O t r o s s i t i o s w e b
G r u p o s d e n o t i c i a s d e U S E N E T
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
La combinacin de espacio, tiempo y fuerza, que deben considerarse como los elemen
tos bsicos de esta teora de la defensa, hace de sta una cuestin complicada. Por con
siguiente, no es fcil encontrar un punto fjo de partida.
D e la fie rra , C ar l Vo n C lausewitz
El arte de la guerra nos ensea a confiar no en la posibilidad de que e l enemigo no
venga, sino en nuestra propia disponibilidad para recibirlo; no en la oportunidad de
que no ataque, sino en e l hecho de que hemos logrado que nuestra posicin sea inex
pugnable.
E l a rte de la fia ra , Sun Tzu
L
as necesidades de sfffliidad de la informacin en una organizacin han sufrido
dos cambios fundamentales en las ltimas dcadas. Antes de la expansin del uso
de equipamiento de procesamiento de datos, la seguridad de la informacin que
una organizacin consideraba valiosa se proporcionaba, por un lado, por medios fsicos,
como el uso de armarios con cierre de seguridad para almacenar documentos confiden
ciales y, por otro, por medios administrativos, como los procedimientos de proteccin de
datos del personal que se usan durante el proceso de contratacin.
Con la introduccin del computador, se hizo evidente la necesidad de disponer de
herramientas automatizadas para la proteccin de archivos y otros tipos de informacin
almacenada en el computador. Esto ocurre especialmente en el caso ae sistemas compar
tidos como, por ejemplo, un sistema de tiempo compartido; y la necesidad se acenta en
sistemas a los que se puede acceder por medio de una red telefnica pblica, una red de
datos o Internet. El nombre genrico que se da al grupo de herramientas diseadas para
proteger los datos y evitar la intrusin de los hackerses el de segpdad informtica
El segundo cambio que afect a la seguridad fue la introduccin de sistemas distri
buidos y el uso de redes y herramientas de comunicacin para transportar datos entre el
usuario de un terminal y el computador, y entre dos computadores. Las medidas de segu
ridad de la red son necesarias para proteger los datos durante la transmisin. De hecho,
el trmino seguridad d e la red es engaoso, en cierto modo, yaque prcticamente todas
las empresas, las instituciones gubernamentales y acadmicas conectan sus equipos de
procesamiento de datos formando un grupo de redes conectadas entre s. Este grupo se
considera con frecuencia como una i n t e r n e t y se emplea el trmino g ir id a J d e la
internet.
No existen unas fronteras bien delimitadas entre estas dos formas de seguridad. Por
ejemplo, uno de los tipos de ataque a los sistemas de informacin a los que ms publi
cidad se ha dado es el virus informtico. Un virus se puede introducir fsicamente en un
sistema por medio de un disquete o llegar por una internet. En cualquier caso, una vez
que el virus reside en un sistema informtico, se necesitan las herramientas internas de
seguridad del computador para detectarlo, eliminarlo y restablecer el sistema.
1 Usamos el trmino internet, con i minscula, para referimos a cualquier grupo de redes conectadas
entre s. Una intranet corporativa es un ejemplo de internet. Internet con I mayscula pude ser una de las
herramientas que usa una organizacin para construir su internet.
www.FreeLibros.org
Captulo 1 / Introduccin 3
Este libro se centra en la seguridad de la internet, aue consiste en las medidas para
impedir, prevenir, detectar y corregir las violaciones ae la seguridad que se producen
durante la transmisin de la informacin. Esta es una afirmacin muy general que abar
ca una gran cantidad de posibilidades. Para que el lector se haga una idea de las reas
que trata este libro, considere los siguientes ejemplos de violaciones de la seguridad:
1. El usuario A enva un archivo al usuario B. El archivo contiene informacin con
fidencial que debe protegerse (por ejemplo, registros de nminas). El usuario C,
que no est autorizado a leer el archivo, observa la transmisin y captura una
copia del archivo durante dicha transmisin.
2. Un administrador de red, D, transmite un mensaje a un computador, E, que se
encuentra bajo su gestin. El mensaje ordena al computador E que actualice un
fichero de autorizacin para incluir las identidades de nuevos usuarios a los que
se va a proporcionar el acceso a ese computador. El usuario F intercepta el men
saje, altera su contenido aadiendo o borrando entradas y, posteriormente, lo
enva a E, que lo acepta como si procediera del administrador D y, por tanto,
actualiza su archivo de autorizacin.
3. Ms all de interceptar un mensaje, el usuario F construye su propio mensaje
con las entradas deseadas y lo transmite a E como si procediera del administra
dor D. Por consiguiente, el computador E acepta el mensaje y actualiza su fiche
ro de autorizacin sin percatarse de la intrusin.
4 Un empleado es despedido sin previo aviso. El jefe de personal enva un mensa
je a un sistema servidor para invalidar la cuenta del empleado. Cuando la invali
dacin se ha llevado a cabo, el servidor ha de notificar la confirmacin de la
accin al archivo del empleado. El empleado intercepta el mensaje y lo retrasa el
tiempo suficiente para realizar un ltimo acceso al servidor y recuperar, as, infor
macin confidencial. A continuacin, se enva el mensaje, se lleva a cabo la
accin y se notifica la confirmacin. La accin del empleado puede pasar inad
vertida durante un perodo de tiempo considerable.
5. Un cliente enva un mensaje a un corredor de bolsa con instrucciones para rea
lizar diferentes transacciones. Ms tarde, las inversiones pierden valor y el clien
te niega haber enviado dicho mensaje.
Aunque, de ningn modo, esta lista abarca todos los tipos posibles de violaciones de la
seguridad, ilustra una serie de aspectos que afectan a la seguridad de la red.
La seguridad de la red se presenta como un tema fascinante a la vez que complejo.
A continuacin se exponen algunas de las razones:
1. La seguridad relativa a las comunicaciones y a las redes no es tan simple como
podra parecer a los principiantes en este tema. Los requisitos parecen claros;
de hecho, a la mayora de los requisitos fundamentales que deben cumplir los
servicios de seguridad se les puede asignar etiquetas de una sola palabra que
se explican por s mismas: confidencialidad, autentificacin, no repudio, inte
gridad. Pero los mecanismos empleados para satisfacer estos requisitos pueden
ser muy complejos, y comprenderlos puede implicar un razonamiento un tan
to sutil.
2. En el desarrollo de un mecanismo particular de seguridad o algoritmo, siempre
se deben tener en cuenta los posibles ataques a esas caractersticas de seguridad.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
En muchos casos, los ataaues con xito estn diseados analizando el problema
de una forma totalmente diferente, explotando, por lo tanto, una debilidad inad
vertida del mecanismo.
3L Como consecuencia del punto 2, los procedimientos empleados para proporcio
nar servicios particulares no suelen ser intuitivos; es decir, a partir de la afirma
cin de un requisito particular no es obvio que sean necesarias medidas tan
elaboradas. Las medidas empleadas slo cobran sentido cuando se han conside
rado las diferentes contramedidas.
4 Despus de disear distintos mecanismos de seguridad, es necesario decidir dn
de usarlos, tanto en lo que respecta a la ubicacin fsica (por ejemplo, en qu
puntos de una red se necesitan determinados mecanismos de seguridad) como a
la ubicacin lgica [en qu capa o capas de una arquitectura como la TCP/IP
(Transmission Control Protocol / Internet Protocol) deberan estar localizados
los mecanismos].
5. Los mecanismos de seguridad suelen implicar ms de un algoritmo o protocolo.
Con frecuencia tambin requieren que los participantes posean alguna informa
cin secreta (que podra ser una clave de cifrado), lo que da lugar a cuestiones
sobre la creacin, distribucin y proteccin de esa informacin secreta. Tambin
hay una dependencia de los protocolos de comunicacin cuyo comportamiento
puede complicar la tarea de desarrollar mecanismos de seguridad. Por ejemplo,
si el funcionamiento adecuado del mecanismo de seguridad requiere establecer
unos lmites de tiempo para la transmisin de un mensaje desde el emisor hasta
el receptor, cualquier protocolo o red que introduzca retrasos variables e impre-
decibles podra hacer que estos lmites temporales carecieran de sentido.
Por lo tanto, son muchas las cuestiones que han de tenerse en cuenta. Este Captulo pro
porciona una visin general del tema, que se ir desarrollando a lo largo del libro. Empe
zaremos con una discusin general sobre los servicios y mecanismos de seguridad en las
redes y los tipos de ataques para los que estn diseados. A continuacin, desa
rrollaremos un modelo general en el que se podrn observar los distintos servicios y
mecanismos de seguridad.
1.1 LA ARQUITECTURA DE SEGURIDAD OSI
Para analizar de forma efectiva las necesidades de seguridad de una organizacin y eva
luar y elegir distintos productos y polticas de seguridad, el responsable de la seguridad
necesita una forma sistemtica de definir los requisitos de seguridad y caracterizar los
enfoques para satisfacer dichos requisitos. Esto es bastante difcil en un entorno centra
lizado de procesamiento de datos, y con el uso de redes de rea local y de rea ancha,
los problemas se agravan.
La recomendacin X.800 de la ITU-T2, Arquitectura de seguridad OSI, define este
enfoque sistemtico. La arquitectura de seguridad OSI es til a los administradores de
2 El Sector de Estandarizacin de Telecomunicaciones (ITU-'T) de la Unin Internacional de Telecomu
nicaciones (ITU) es una agencia financiada por las Naciones Unidas que desarrolla estndares, denominados
Recomendaciones, relativos a las telecomunicaciones y a la interconexin de sistemas abiertos (OSI).
www.FreeLibros.org
Captulo 1 / Introduccin 5
red para organizar la tarea de proporcionar seguridad. Adems, debido a que esta arqui
tectura fue desarrollada como un estndar internacional, los vendedores han desarrolla
do caractersticas de seguridad para sus productos y servicios conforme a esta definicin
estructurada de servicios y mecanismos.
Para nuestros propsitos, la arquitectura de seguridad OSI proporciona una visin
general til, aunque abstracta, de muchos de los conceptos que se tratan en este libro. La
arquitectura de seguridad OSI se centra en los ataques a la seguridad, los mecanismos y
los servicios, que se definen brevemente a continuacin:
Tabla 1.1 A m e n a z a s y a t a q u e s ( R F C 2 8 2 8 )
Amenaza
U n a p o s i b i l i d a d d e v i o l a c i n d e l a s e g u r i d a d , q u e e x i s t e c u a n d o se d a u n a c i r c u n s
t a n c i a , c a p a c i d a d , a c c i n o e v e n t o q u e p u d i e r a r o m p e r l a s e g u r i d a d y c a u s a r p e r j u i
cio. Es d e c i r , u n a a m e n a z a e s u n p e l i g r o p o s i b l e q u e p o d r a e x p l o t a r u n a v u l n e r a b i
l i d a d .
Ataque
U n a s a l t o a l a s e g u r i d a d de l s i s t e m a d e r i v a d o d e u n a a m e n a z a i n t e l i g e n t e ; e s d e c i r ,
u n a c t o i n t e l i g e n t e y d e l i b e r a d o ( e s p e c i a l m e n t e e n el s e n t i d o d e m t o d o o t c n i c a )
p a r a e l u d i r l o s s e r v i c i o s d e s e g u r i d a d y v i o l a r l a p o l t i c a d e s e g u r i d a d d e u n s i s
t e m a .
Ataque a la segiridad: cualquier accin que comprometa la seguridad de la infor
macin de una organizacin.
Mecanismo de seguridad: un mecanismo diseado para detectar un ataque a la
seguridad, prevenirlo o restablecerse de l.
Servicio de seguridad: un servicio que mejora la seguridad de los sistemas de
procesamiento de datos y la transferencia de informacin de una organizacin. Los
servicios estn diseados para contrarrestar los ataques a la seguridad, y hacen uso
de uno o ms mecanismos para proporcionar el servicio.
En la literatura al respecto, los trminos amenaza y ataque se usan frecuentemente para
referirse ms o menos a lo mismo. La Tabla 1.1 proporciona las definiciones extradas
de RFC 2828, Internet Securty Glossary.
1.2 ATAQUES A LA SEGURIDAD
Una forma til de clasificar los ataques a la seguridad, empleada en la recomendacin
X.800 y RFC 2828, es la distincin entre ataques pasivos y ataques activos. Un ataque
pasivo intenta conocer o hacer uso de informacin del sistema, pero no afecta a los
recursos del mismo. Un ataque activo, por el contraro, intenta alterar los recursos del
sistema o afectar a su funcionamiento.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
ATAQUES PASIVOS
Los ataques pasivos se dan en forma de escucha o de observacin no autorizadas de las
transmisiones. El objetivo del oponente es obtener informacin que se est transmitien
do. Dos tipos de ataques pasivos son la obtencin de contenidos de mensajes y el anli
sis del trfico.
La obtaicin de ant a dos demeasajes se entiende fcilmente. (Figura 1.1a). Una
conversacin telefnica, un mensaje por correo electrnico y un fichero enviado pueden
contener informacin confidencial. Queremos evitar que un oponente conozca los con
tenidos de estas transmisiones.
David Lee los contenidos del
mensaje de Benito para
Alicia
Benito
(a) Obtencin del contenido del mensaje
Alicia
David Observa el patrn de los
mensajes de Benito para Alicia
Alicia
(b) Anlisis del trfico
Figura 1.1 A t a q u e s p a s i v o s
www.FreeLibros.org
Captulo 1 / Introduccin 7
David l Mensaje de David, que suplanta
\ a Benito
(a) Suplantacin de identidad
David T \ Captura el mensaje de Benito para Alicia;
/ \ luego reenva el mensaje a Alicia
(b) Repeticin
Figura 1.2 A t a q u e s a c t i v o s
Un segundo tipo de ataque pasivo, el anlisis d e trfico, es ms sutil (Figura 1.1b).
Supongamos que hemos enmascarado los contenidos de los mensajes u otro trfico de
informacin de forma que el oponente, incluso habiendo capturado el mensaje, no pue
da extraer la informacin que contiene. La tcnica comn para enmascarar los conteni
dos es el cifrado. Incluso si tuvisemos proteccin mediante cifrado, un oponente podra
observar el patrn de los mensajes, determinar la localizacin y la identidad de los ser
vidores que se comunican y descubrir la frecuencia y la longitud de los mensajes que se
estn intercambiando. Esta informacin puede ser til para averiguar la naturaleza de la
comunicacin que est teniendo lugar.
Los ataques pasivos son muy difciles de detectar ya que no implican alteraciones en
los datos. Normalmente, el mensaje se enva y se recibe de una forma aparentemente
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
normal y ni el emisor ni el receptor son conscientes de que una tercera persona ha ledo
los mensajes o ha observado el patria del trfica Sin embargo, es posible evitar el xi
to de estos ataques, normalmente mediante el uso del cifrado. As, al tratar con los ata
ques pasivos, el nfasis se pone ms en la prevencin que en la deteccin.
David i David modifica el mensaje
\ de Benito para Alicia
(c) Modificacin de mensajes
Figura 1.2 A t a q u e s a c t i v o s (continuacin)
ATAQUES ACTIVOS
Los ataques activos implican alguna modificacin del flujo de datos o la creacin de
un flujo falso y se pueden dividir en cuatro categoras: suplantacin de identidad, repe
ticin, modificacin de mensajes e interrupcin de servicio.
Una suplantacin se produce cuando una entidad finge ser otra (Figura 1.2a). Un
ataque de este tipo incluye habitualmente una de las otras formas de ataque activo. Por
David l David interrumpe el servicio
proporcionado por el servidor
(d) Interrupcin de servicio
Servidor
www.FreeLibros.org
Captulo 1 / Introduccin 9
ejemplo, las secuencias de autentificacin pueden ser capturadas y repetidas despus de
que una secuencia vlida de autentificacin haya tenido lugar, permitiendo as, que una
entidad autorizada con pocos privilegios obtenga privilegios extra hacindose pasar por
la entidad que realmente los posee.
La repeticin implica la captura pasiva de una unidad de datos y su retransmisin
posterior para producir un efecto no autorizado (Figura 1.2b).
La modificacin de mensajes significa que una parte de un mensaje original es
alterada, o que los mensajes se han retrasado o reordenado, para producir un efecto no
autorizado (Figura 1.2c). Por ejemplo, el mensaje Permitir a Carlos Prez que lea las
cuentas de archivos confidenciales se modifica para convertirlo en Permitir a Marcos
Fernndez que lea las cuentas de archivos confidenciales.
La intexnipdn deservicio impide el uso o la gestin normal de las utilidades de
comunicacin (Figura 1.2d). Este ataque podra tener un objetivo especfico; por ejem
plo, una entidad podra suprimir todos los mensajes dirigidos a un destino en particular
(por ejemplo, el servicio de auditora de la seguridad). Otra forma de este tipo de ataque
es la interrupcin de una red completa, ya sea inhabilitndola o sobrecargndola con
mensajes para reducir su rendimiento.
Los ataques activos presentan las caractersticas opuestas a los pasivos. Aunque los
ataques pasivos son difciles de detectar, existen medidas para prevenir su xito. Sin
embargo, es bastante difcil prevenir por completo los ataques activos, debido a que se
requerira la proteccin fsica de todas las herramientas de comunicacin y las rutas en
todo momento. Por el contrario, el objetivo es el de detectarlos y recuperarse de cual
quier irrupcin o retraso que originen. Como la deteccin tiene un efecto disuasivo, tam
bin podra contribuir a la prevencin.
1.3 SERVICIOS DE SEGURIDAD
La recomendacin X.800 define un servicio de seguridad como un servicio proporcio
nado por una capa de protocolo de sistemas abiertos de comunicacin, que garantiza la
seguridad adecuada de los sistemas o de las transferencias de datos. Quizs es ms cla
ra la definicin recogida en RFC 2828: un servicio de procesamiento o de comunicacin
proporcionado por un sistema para dar un tipo especial de proteccin a los recursos del
sistema; los servicios de seguridad implementan polticas de seguridad y son imple-
mentados, a su vez, por mecanismos de seguridad.
En X.800 estos servicios quedan divididos en cinco categoras y 14 servicios espec
ficos (Tabla 1.2). Observemos a continuacin cada una de las categoras3.
3 No existe un acuerdo universal sobre la gran cantidad de trminos que se emplean en la literatura sobre
seguridad. Por ejemplo, el trmino integridad se usa a veces para referirse a todos los aspectos de la seguri
dad de la informacin. El trmino autentificacin se usa con frecuencia para hacer alusin tanto a la verifi
cacin de la identidad como a las diferentes funciones que aparecen referidas a integridad en este Captulo.
Nuestro uso aqu est de acuerdo con las normas X.800 y RFC 2828.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Tabla 1.2 Servicios de seguridad (X.800)
A U T E N T I C A C I N
La seguridad de que la entidad que se comuni
ca es quien dice ser.
Autentificacin de las entidades o rigen /destn o
Empleada conjuntamente con una conexin
lgica para aportar confianza sobre la identi
dad de las entidades conectadas.
Autentificacin del origen de los datos
En transferencias no orientadas a la conexin,
garantiza que la fuente de los datos recibidos
es la que dice ser.
CONTROL DE ACCESO
La prevencin del uso no autorizado de una
fuente (este servicio controla quin puede
tener acceso a una fuente, en qu condiciones
se puede producir el acceso y qu tienen per
mitido los que acceden a la fuente).
CONFIDENCIALIDAD DE LOS DATOS
La proteccin de los datos contra la revelacin
no autorizada.
Confidencialidad de la conexin
La proteccin de los datos de todos los usua
rios en una conexin.
Confidencialidad no orientada a la conexin
La proteccin de los datos de todos los usua
rios en un nico bloque de datos.
Confidencialidad de campos seleccionados
La confidencialidad de campos seleccionados
en los datos del usuario en una conexin o
en un nico bloque de datos^
Confidencialidad del flujo de tr fi co
La proteccin de la informacin que podra
extraerse a partir de la observacin del flujo
del trfico.
INTEGRIDAD DE LOS DATOS
La seguridad de que los datos recibidos son
exactamente como los envi una entidad
autorizada (no contienen modificacin, inser
cin, omisin, ni repeticin).
Integridad de la conexin con recuperacin
Proporciona la integridad de los datos de todos
los usuarios en una conexin y detecta cual
quier modificacin, insercin, omisin o
repeticin de cualquier dato de una secuen
cia completa de datos, con intento de recu
peracin.
Integridad de la conexin sin recuperacin
Igual que el anterior, pero proporciona slo
deteccin sin recuperacin.
Integridad de la conexin de campos
seleccionados
Proporciona la integridad de los campos selec
cionados en los datos del usuario del bloque
de datos transferido por una conexin y
determina si los campos seleccionados han
sido modificados, insertados, suprimidos o
repetidos.
Integridad no orientada a la conexin
Proporciona integridad de un bloque de datos
sin conexin y puede detectar la alteracin
de datos. Adems, puede proporcionar una
forma limitada de deteccin de repeticin.
Integridad no orientada a la conexin
de campos seleccionados
Proporciona la integridad de los campos selec
cionados en un bloque de datos sin cone
xin; determina si los campos seleccionados
han sido modificados.
NO REPUDIO
Proporciona proteccin contra la interrupcin,
por parte de una de las entidades implicadas
en la comunicacin, de haber participado en
toda o parte de la comunicacin.
No repudio, origen
Prueba que el mensaje fu e enviado por la par
t e especificada.
No repudio, destino
Prueba que el mensaje fue recibido por la par
t e especificada.
www.FreeLibros.org
Captulo 1 / Introduccin 11
AUTENTIFICACIN
El servicio de autentificacin se encarga de garantizar la autenticidad de la comunica
cin. En el caso de un nico mensaje como, por ejemplo, una seal de aviso o de alar
ma, la funcin del servicio de autentificacin es asegurar al receptor que el mensaje
pertenece a la fuente de la que dice proceder. En el caso de una interaccin continua
da como la conexin de un terminal a un host, intervienen dos aspectos. En primer
lugar, en el inicio de la conexin, el servicio asegura que las dos entidades son autn
ticas; es decir, cada entidad es la que dice ser. En segundo lugar, el servicio debe ase
gurar que la conexin no est intervenida de forma que una tercera persona pueda
suplantar a una de las dos partes autnticas con la finalidad de realizar una transmi
sin o una recepcin no autorizada.
En el estndar X.800 se definen dos tipos particulares de autentificacin:
Autentificaran d e entidades origen/destinoc proporciona la confirmacin de la
identidad de una entidad de una asociacin. Se proporciona en el establecimiento
de una conexin o a veces durante la fase de transmisin de datos de dicha cone
xin. Intenta asegurar que una entidad no est realizando una suplantacin o una
repeticin no autorizada de una conexin anterior.
Autentificacin d d origm d e los datos: corrobora la fuente de una unidad de
datos. No aporta proteccin contra la repeticin o la alteracin de unidades de
datos. Este tipo de servicio admite aplicaciones como el correo electrnico, donde
no hay interacciones previas entre las entidades que se comunican.
CONTROL DE ACCESO
En el contexto de la seguridad de redes, el control de acceso es la capacidad de limitar
y controlar el acceso a sistemas host y aplicaciones por medio de enlaces de comunica
ciones. Para conseguirlo, cualquier entidad que intente acceder debe antes ser identifi
cada o autentificada, de forma que los derechos de acceso puedan adaptarse de manera
individual.
CONFIDENCIALIDAD DE LOS DATOS
La confidencialidad es la proteccin de los datos transmitidos por medio de ataques
pasivos. En funcin del contenido de una transmisin de datos, existen diferentes nive
les de proteccin. El servicio ms amplio protege los datos de los usuarios que se han
transmitido por conexin TCP. Se pueden distinguir formas ms especficas de este ser
vicio, incluyendo la proteccin de un solo mensaje o incluso de determinados campos
de un mensaje. Estos refinamientos son menos tiles que el enfoque amplio y su imple-
mentacin puede incluso ser ms compleja y costosa.
El otro aspecto de la confidencialidad es la proteccin del flujo del trfico frente al
anlisis del trfico. Para ello el atacante no debera poder ver la fuente, el destino, la fre
cuencia, la longitud ni otras caractersticas del trfico en una comunicacin.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
INTEGRIDAD DE LOS DATOS
Al igual que ocurre con la confidencialidad, la integridad se puede aplicar a una serie de
mensajes, a un solo mensaje o a campos seleccionados de un mensaje. Nuevamente, el
enfoque ms til y claro es la proteccin del flujo completo.
Un servicio de integridad orientado a la conexin que funcione sobre un flujo de
mensajes garantiza que los mensajes se reciben tal y como son enviados, sin duplicacin,
insercin, modificacin, reordenacin ni repeticiones. La destruccin de datos tambin
queda cubierta con este servicio. As, el servicio de integridad orientado a la conexin
trata tanto la modificacin del flujo de mensajes como la interrupcin del servicio. Por
otra parte, un servicio de integridad sin conexin, que trata nicamente mensajes indi
viduales sin tener en cuenta contextos mayores, slo proporciona, generalmente, pro
teccin contra la modificacin del mensaje.
Podemos distinguir entre el servicio con y sin recuperacin. Debido a que el servi
cio de integridad tiene que ver con ataques activos, nos interesa ms la deteccin que la
prevencin. Si se detecta una violacin de la integridad, el servicio podra simplemente
informar de esta violacin, y ser necesaria la intervencin humana o de algn otro soft
ware para restablecerse de la violacin. Por otra parte, existen mecanismos para la recu
peracin de la prdida de integridad de los datos, como estudiaremos ms tarde. La
incorporacin de mecanismos de recuperacin automatizada se presenta, en general,
como la alternativa ms atrayente.
NO REPUDIO
El no repudio evita que el emisor o el receptor nieguen la transmisin de un mensaje.
As, cuando se enva un mensaje, el receptor puede comprobar que, efectivamente, el
supuesto emisor envi el mensaje. De forma similar, cuando se recibe un mensaje, el
emisor puede verificar que, de hecho, el supuesto receptor recibi el mensaje.
SERVICIO DE DISPONIBILIDAD
Tanto X.800 como RFC 2828 definen la disponibilidad como la propiedad que tiene un
sistema o recurso de un sistema de estar accesible y utilizable a peticin de una entidad
autorizada, segn las especificaciones de rendimiento para el sistema (un sistema est
disponible si proporciona servicios de acuerdo con el diseo del sistema en el momen
to en que los usuarios lo soliciten). Una variedad de ataques puede dar como resultado
la prdida o reduccin de la disponibilidad. Algunos de estos ataques son susceptibles a
contramedidas automatizadas, como la autentificacin o el cifrado, mientras que otras
requieren algn tipo de accin fsica para prevenir o recuperarse de la prdida de dispo
nibilidad de elementos de un sistema distribuido.
La norma X.800 trata la disponibilidad como una propiedad asociada a diferentes ser
vicios de seguridad. Sin embargo, tiene sentido solicitar un servicio concreto de disponibi
lidad. Un servicio de disponibilidad es aquel que protege un sistema para asegurar su dis
ponibilidad y trata los problemas de seguridad que surgen a raz de ataques de interrupcin
de servicio. Depende de la gestin y control adecuados de los recursos del sistema y, por lo
tanto, del servicio de control de acceso y otros servicios de seguridad.
www.FreeLibros.org
Captulo 1 / Introduccin 13
La Tabla 1.3 muestra la relacin existente entre los servicios de seguridad y los ata
ques.
Tabla 1 . 3 R e l a c i n e n t r e s e r v i c i o s d e s e g u r i d a d y a t a q u e s
Ataque
Servicio Obtencin
del
contenido
del mensaje
Anlisis
de
trfico
Suplantacin Repeticin Modificacin
de
mensajes
Interrup
cin
de servicio
Autentificacin
de las entida
des origen/
destino
Y
Autentificacin
del origen de
los datos
Y
Control de acceso Y
Confidencialidad Y
Confidencialidad
del flujo de
trfico
Y
Integridad de los
datos
Y Y
No repudio
Disponibilidad Y
1.4 M E C A NI SM O S DE SEGURIDAD
La Tabla 1.4 presenta los mecanismos de seguridad definidos en X.800. Como se puede
observar, los mecanismos se dividen en aquellos que se implementan en una capa espe
cfica de un protocolo y aquellos que no son especficos de ninguna capa de protocolo o
servicio de seguridad en particular. Estos mecanismos se tratarn en las secciones
correspondientes de este libro y por ello no se elaboran ahora, excepto para adelantar la
definicin de cifrado. X.800 distingue entre mecanismos de cifrado reversible y meca
nismos de cifrado irreversible. El primero es un algoritmo de cifrado que permite cifrar
los datos y, posteriormente, descifrarlos. Por otro lado, los mecanismos de cifrado irre
versible incluyen algoritmos hash y cdigos de autentificacin de mensajes, que se
emplean en firmas digitales y en aplicaciones de autentificacin de mensajes.
La Tabla 1.5, basada en X.800, indica la relacin que se da entre los servicios de
seguridad y los mecanismos de seguridad.
www.FreeLibros.org
14 Fundamentos de seguridad en redes. Aplicaciones y estndares
Tabla 1.4 M e c a n i s m o s d e s e g u r i d a d ( X . 8 0 0 )
M E C A N I S M O S ESPECFICOS
DE SEGURIDAD
Pueden s e r i ncorporados en la capa de pro
t o c ol o adecuada pa ra propor cionar a l g u
nos de los servicios de seguridad OSI
Cifrado
El uso d e algoritmos matemticos para tr ans
f o r m a r datos en un a f o r m a inteligible. La
transformacin y la posterior recuperacin
de los datos de pende de un a lgor itmo y
cero o ms claves de cifrado.
F i ima di gita l
Datos aadidos a , o una tr ansformacin
c r iptogrfica de , una unidad de datos que
pe rm ite al r ecep to r v e r if i c a r la fu e nt e y la
i ntegridad de la unidad de datos y pr ot e
ge rla de la fa l sifi cacin (por parte del
receptor).
Control de acceso
Una serie de mecanismos que refuerza n los
derechos de acceso a los recursos.
I ntegridad de los datos
Una serie de mecanismos e m pl e a do s para
v e rif icar la integridad de una unidad de
datos o del f l u j o de unidades de datos.
I nter cambio de autenti fl caci n
Un mec a n i s m o di s e a do para c o m p r o b a r la
ident idad de una en ti d ad p o r m e dio del
i n te r c a m bi o de informacin.
Relleno de l t r fi c o
La insercin de bits en espacios en un flujo
de datos pa ra fr u s t r a r los intentos de a n
lisis de trfi co.
Control de e n r u t a m i e n t o
Permite la seleccin de rutas fs ic a m e n te
seguras pa ra de te r mi na d os datos y p e r m i
t e los ca mbios de en ruta m i ent o, es pec i al
m e nt e cuando se sospecha de una brecha
en la seguridad.
Not ari zaci n
El uso de una t e rc e ra pa rt e co nfi able para
as egura r de ter mi nad as pr opiedade s de un
i n ter cambio de datos.
M E C A N I S M O S GENERALES
DE SEGURIDAD
Me cani smos qu e no son especficos de n i n
guna capa de protocolo o sis tema de
seguridad OSI en particular.
Func iona lida d fiable
La que se considera correcta con r especto a
algunos criterios (por e j e m p l o , los e s ta b l e
cidos p o r una poltica de seguridad).
Etiquetas de segur idad
La ma rc a asociada a un r e c u rs o (que podr a
ser una unidad de datos) que designa los
atributos de seguridad de ese recurso.
Deteccin de acciones
Deteccin de acciones relacionadas con la
seguridad.
I nforme para la a udit or a de seguridad
Recopilacin de datos para f a c il it a r una a u d i
t o r a de se gur i d ad, que consiste en una
revisin y un e x a m e n i ndependientes de
los informes y actividades del sistema.
Recuperacin de la seguridad
M a ne j a las peticiones de los mecanismos
( c om o funcione s de gestin de acciones) y
lleva a cabo acciones de recuperacin.
1.5 U N MODELO DE SEGURIDAD EN REDES
La Figura 1.3 constituye un modelo que presenta, en trminos generales, gran parte de
los aspectos que discutiremos a continuacin. Un mensaje ha de ser transmitido de una
parte a otra mediante algn tipo de internet. Las dos partes, que son los interlocutores en
esta transaccin, deben cooperar para que el intercambio tenga lugar. Se establece un
canal de informacin definiendo una ruta a travs de la internet que vaya de la fuente al
www.FreeLibros.org
Captulo 1 / Introduccin 1 5
Tabla 1.5 Relacin entre servicios y mecanismos de seguridad
Mecanismo
Servicio Cifrado
Firma
digital
Control
de
acceso
Integridad
de los
datos
Intercambio
de
autenti-
ficacin
Relleno
del
trfico
Control
del
en ruta-
miento
Notari-
zacin
Autentifica-
cin de en
tidades
origen/des
tino
Y Y Y
Autentifcacin
del origen
de los datos
Y Y
Control de
acceso Y
Confidenciali
dad Y Y
Confidenciali
dad del flujo
del trfico Y Y Y
Integridad de
los datos Y Y Y
No repudio Y Y Y
Disponibilidad Y Y
destino y mediante el uso cooperativo de los protocolos de comunicacin (TCP/IP) por
parte de los dos interlocutores.
Los aspectos de seguridad entran enjuego cuando se necesita o se quiere proteger la
transmisin de informacin de un oponente que pudiera presentar una amenaza a la con
fidencialidad, a la autenticidad, etc. Todas las tcnicas para proporcionar seguridad tie
nen dos componentes:
Una transformacin relacionada con la seguridad de la informacin que se va a
enviar. Ejemplos de ello los tenemos en el cifrado del mensaje, que lo desordena
para que resulte ilegible al oponente, y la aplicacin de un cdigo basado en el con
tenido del mensaje, que puede usarse para verificar la identidad del emisor.
Alguna informacin secreta compartida por los interlocutores y desconocida por el
oponente. El ejemplo lo hallamos en una clave de cifrado usada en conjuncin con
la transformacin para desordenar el mensaje antes de la transmisin y reordenar-
lo en el momento de la recepcin4.
4 El Captulo 3 trata una forma de cifrado, conocida como cifrado de clave pblica, en la que slo uno
de los dos interlocutores necesita conocer la informacin secreta.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Para lograr una transmisin segura, puede ser necesaria una tercera parte confiable, que, por
ejemplo, sea la responsable de distribuir la informacin secreta a los dos interlocutores y la
guarde de cualquier oponente. Tambin puede ser necesaria para arbitrar disputas entre los
interlocutores en lo relativo a la autenticidad de la transmisin de un mensaje.
Este modelo general muestra que hay cuatro tareas bsicas en el diseo de un servi
cio de seguridad particular:
L Disear un algoritmo para llevar a cabo la transformacin relacionada con la
seguridad. El algoritmo debe estar diseado de forma que un oponente no pue
da frustrar su finalidad.
Z Generar la informacin secreta que deba ser usada con el algoritmo.
3L Desarrollar mtodos para distribuir y compartir la informacin secreta.
4 Especificar un protocolo para los dos interlocutores que hagan uso del algoritmo
de seguridad y la informacin secreta, para obtener un servicio concreto de segu
ridad.
La Segunda Parte de este libro se centra en los tipos de mecanismos y servicios de segu
ridad que encajan en el modelo que muestra la Figura 1.3. Sin embargo, existen otras
situaciones relacionadas con la seguridad que son de inters y que no se corresponden
claramente con este modelo, pero que se tienen en consideracin en este libro. La Figu
ra 1.4 ofrece un modelo general de estas situaciones, que refleja la preocupacin por
proteger un sistema de informacin del acceso no deseado. La mayora de los lectores
estn familiarizados con los problemas ocasionados por la existencia de hackers, que
tratan de penetrar sistemas a los que se puede acceder por una red. El hacker puede ser
alguien que, sin la intencin de hacer dao, obtiene satisfaccin simplemente rompien
do y entrando en sistemas informticos. El intruso tambin puede ser un empleado con
trariado que quiere hacer dao, o un criminal que intenta explotar los sistemas compu-
tacionales para obtener beneficios financieros (obtencin de nmeros de tarjetas de
crdito o realizacin de transferencias ilegales de dinero).
Otro tipo de acceso no deseado consiste en introducir en un sistema computacional
soware que explote debilidades en el sistema y que pueda afectar a programas de apli
caciones, como editores y compiladores. Los programas pueden presentar dos tipos de
amenazas:
Amenazas al acceso a la informacin: captura o alteracin de datos por parte de
usuarios que no deberan tener acceso a dichos datos.
Amenazas al servidos explotacin de fallos del servicio en los computadores para
impedir el uso por parte de los usuarios legtimos.
Los virus y gusanos son dos ejemplos de ataques mediante software. Tales ataques pue
den introducirse en un sistema por medio de un disco que contenga el programa no
deseado oculto en soware til. Tambin pueden ser introducidos en un sistema a travs
de una red; este ltimo mecanismo es de ms inters en la seguridad de redes.
Los mecanismos de seguridad necesarios para enfrentarse a accesos no deseados se
dividen en dos grandes categoras (vase la Figura 1.4). La primera categora puede
denominarse funcin de vigilancia. Incluye los procedimientos de conexin mediante
clave, diseados para negar acceso a usuarios no autorizados, y los soware de oculta
cin, diseados para detectar y rechazar gusanos, virus y ataques similares. Una vez que
www.FreeLibros.org
Captulo 1 / Introduccin 17
un usuario o software no deseado accede, la segunda lnea de la defensa consiste en una
serie de controles internos que monitorizan la actividad y analizan la informacin alma
cenada con el fin de detectar la presencia de intrusos. Estos aspectos se tratan ms
exhaustivamente en la Tercera Parte del libro.
Tercera parte confiable
Figura 1.3 M o d e l o p a r a la s e g u r i d a d d e r e d e s
Sistema de informacin
Oponente
- humano (hacker)
- software (virus, gusano)
(i
Canal de acceso
Funcin
de vigilancia
Recursos informticos
(procesador, memoria,
dispositivos
de entrada/salida)
Datos
Procesos
Software
Controles internos
de seguridad
Figura 1.4 M o d e l o p a r a l a s e g u r i d a d e n e l a c c e s o a r e d e s
1.6 ESTANDARES DE INTERNET Y LA SOCI EDAD INTERNET
Muchos protocolos que conforman la suite de protocolos TCP/IP han sido estandariza
dos o estn en proceso de estandarizacin. Por acuerdo universal, una organizacin
conocida como la Sociedad Internet es responsable del desarrollo y la publicacin de los
estndares. La Sociedad Internet es una organizacin de miembros profesionales que
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
controla una serie de comisiones y grupos de trabajo implicados en el desarrollo y la
estandarizacin de Internet.
Esta seccin ofrece una breve descripcin de la forma en que se desarrollan los estn
dares para la suite de protocolos TCP/IP.
Tabla 1.6 r e a s d e la I E T F
rea IETF Tema Grupos de t r a b a j o (ejemplos)
General Proceso y pr oc edimie ntos de
IETF.
Polticas de tr ab aj o.
Proceso para la organizacin
de los estndares de Internet.
Apli caciones Apl icaci ones de Internet. Protocolos w e b (HTTP).
Integracin EDI-Internet.
LDAP.
I n te r ne t Infraestructura de Internet. IPv6.
Extensiones PPR
Operaciones
y gestin
Estndares y definiciones para
las operaciones de las redes.
S N MP v3.
Monitorizacin r emota de redes
de comunicacin.
En ruta mi e nt o P ro toc olo s y a d m i n i s t r a c i n
pa ra el e n r u t a m i e n t o d e la
i nformacin.
E nr uta mie nto Multicast.
OSPF.
E nr uta mie nto QoS.
Seguri dad Protocolos y t e c n o lo g a s de
seguridad.
Kerberos.
IPSec.
X.509.
S /M I M E .
TLS.
Transporte Protocolos de la capa de t r a n s
porte.
Servicios di ferenciados.
Telefona IP.
NFS.
RSVP.
Servicios
de usuarios
M tod os pa ra m e j o r a r la cali
dad de la i nforma cin di sponi
ble a los usuarios de Internet.
Uso responsabl e de Internet.
Servicios de usuarios.
Documentos FYI.
LAS ORGANIZACIONES DE INTERNETY LA PUBLICACIN DE LOS RFC
La Sociedad Internet es el comit coordinador para el diseo, la ingeniera y la gestin
de Internet. Las reas que cubre incluyen el funcionamiento de Internet y la estandari
www.FreeLibros.org
Captulo 1 / Introduccin 19
zacin de protocolos que se usan en sistemas terminales en Internet para operar entre s.
Existen tres organizaciones en el mbito de la Sociedad Internet que son responsables
del trabajo real del desarrollo y la publicacin de los estndares:
Inem*AnM eckmBosad$XB): es responsable de definir la arquitectura gene
ral de Internet, proporcionando orientaciones a la IETF.
Intern etE n ^neain g TaskFoire (EETF): se encarga del desarrollo y la ingenie
ra de protocolos en Internet.
In ta netE ng in em n g S tea in g Group (IESG): responsable de la gestin tcnica
de las actividades de la IETF y del proceso de estndares de Internet.
Los grupos de trabajo de IETF llevan a cabo el desarrollo real de los nuevos estn
dares y protocolos para Internet. Ser miembro de un grupo de trabajo es una accin
voluntaria y cualquier parte interesada puede participar. Durante el desarrollo de una
especificacin, un grupo de trabajo realizar un borrador del documento disponible
como Borrador de Internet, que se coloca en el directorio en lnea Borradores de Inter
net de la IETF. El documento puede permanecer como un Borrador de Internet duran
te seis meses, y las partes interesadas pueden revisarlo y hacer observaciones sobre l.
Durante ese perodo de tiempo, el IESG puede aprobar la publicacin del borrador como
RFC (Request for Comment). Si el borrador no ha progresado hasta llegar al estado de
RFC durante esos seis meses, se retira del directorio. El grupo de trabajo puede, a con
tinuacin, publicar una versin revisada del borrador.
La IETF es responsable de la publicacin de los RFC con la aprobacin del IESG.
Los RFC son las notas de trabajo de la comunidad de investigacin y desarrollo de Inter
net. Estos documentos pueden versar sobre cualquier asunto relacionado con las comu
nicaciones computaconales y puede constituir cualquier tipo de documento, desde un
informe de una reunin a las especificaciones de un estndar.
El trabajo de la IETF se divide en ocho grandes reas. La Tabla 1.6 refleja estas re
as y sus correspondientes objetivos.
EL PROCESO DE ESTANDARIZACIN
El IESG toma la decisin por la cual los RFC se convierten en estndares de Internet,
con la recomendacin de la IETF. Para llegar a ser un estndar, una especificacin debe
cumplir con los siguientes requisitos:
Ser estable y comprensible.
Ser tcnicamente competente.
Tener implementaciones mltiples, independientes e interoperativas con una expe
riencia operativa sustancial.
Tener apoyo pblico significativo.
Ser reconocidamente til en algunas o en todas las partes de Internet.
La diferencia clave entre estos criterios y los que se usan para los estndares internacio
nales de la ITU se halla en la importancia que se otorga aqu a la experiencia operativa.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
La parte izquierda de la Figura 1.5 presenta los diferentes pasos (standards tracti) ,
que sigue una especificacin hasta convertirse en estndar; este proceso est definido en
la norma RFC 2026. A medida que se avanza por dichos pasos aumentan el escrutinio y
las pruebas. En cada paso, la IETF debe solicitar recomendacin para el avance del pro
tocolo, y el IESG debe ratificarlo. El proceso comienza cuando el IESG aprueba la
publicacin de un borrador de Internet como RFC con el estatus de Estndar Propuesto.
Los recuadros blancos de la Figura 1.5 representan estados temporales, que deberan
estar ocupados durante el tiempo mnimo. Sin embargo, un documento debe permane
cer como Estndar Propuesto durante al menos seis meses, y un Estndar de Borrador,
durante un mnimo de cuatro meses para permitir su revisin y discusin. Los recuadros
grises representan los estados de larga duracin que pueden estar ocupados durante aos.
Figura 1.5 P r o c e s o p a r a l a p u b l i c a c i n d e lo s R F C d e I n t e r n e t
Para que una especificacin adquiera el estatus de Estndar de Borrador, debe haber
al menos dos implementaciones independientes e interoperativas de las cuales se haya
obtenido experiencia operativa adecuada.
Despus de que se haya obtenido implementacin significativa y experiencia opera
tiva, la especificacin puede ser elevada a Estndar de Internet. En este momento, se
asigna un nmero STD y un nmero RFC a la especificacin.
Finalmente, cuando un protocolo se queda obsoleto, se asigna al estado de Histrico.
CATEGORAS DE ESTNDARES DE INTERNET
Los estndares de Internet se dividen en dos categoras:
Especificacin tcnica (TS, TedmkalSpecifcatiot): define un protocolo, servi
cio, procedimiento, convencin o formato. La mayora de los estndares de Inter
net son especificaciones tcnicas.
www.FreeLibros.org
Captulo 1 / Introduccin 21
Informe de apticabiKdad (AS, AppBcabiBfy Sistemen): especifica cmo y en
qu circunstancias una o ms especificaciones tcnicas pueden aplicarse para posi
bilitar una determinada capacidad de Internet. Un informe de aplicabilidad identi
fica a una o ms especificaciones tcnicas que son relevantes para la capacidad y
puede especificar valores o rangos para determinados parmetros asociados con un
TS o subgrupos funcionales de un TS relevantes para la capacidad.
OTROS TIPOS DE RFC
Hay numerosos RFC que no estn destinados a convertirse en estndares de Internet.
Algunos RFC estandarizan los resultados de las deliberaciones de la comunidad sobre
los informes de principios o conclusiones sobre el mejor modo de realizar algunas ope
raciones o la funcin del proceso de la IETF. Estos RFC se denominan Best Current
Practice (BCP). La aprobacin de los BCP sigue bsicamente el mismo proceso de
aprobacin para los Estndares Propuestos. A diferencia de los otros documentos, los
BCP no siguen un proceso de tres etapas, sino que pasan del estatus de Borrador de
Internet a BCP aprobado en un solo paso.
Un protocolo u otra especificacin que no se considere preparada para la estandari
zacin podra publicarse como un RFC Experimental. Ms tarde, la especificacin
podra volverse a presentar. Si la especificacin es, en general, estable, cumple los requi
sitos de diseo, se considera comprensible, ha recibido una revisin significativa por
parte de la comunidad y parece gozar de suficiente inters en la misma, entonces el RFC
se elevar al estatus de Estndar Propuesto.
Finalmente, se publica una Especificacin Informativa para informar a la comunidad
de Internet.
1.7 ESTRUCTURA DEL LIBRO
Este primer Captulo, como vemos, sirve como introduccin. El resto del libro se orga
niza en tres partes:
Primera Partes proporciona un estudio conciso de los algoritmos criptogrficos y
los protocolos fundamentales para las aplicaciones de seguridad de redes, incluyendo el
cifrado, las funciones hash, las firmas digitales y el intercambio de claves.
Seg^mda Partes examina el uso de algoritmos criptogrficos y protocolos de seguri
dad para proporcionar seguridad a las redes y a Internet. Los temas que abarca incluyen
la autentifcacin de usuarios, el correo electrnico, la seguridad IP y web.
Tercera Parte: se centra en las herramientas de seguridad diseadas para proteger
un sistema informtico de amenazas a la seguridad, como intrusos, virus y gusanos. Esta
parte tambin menciona la tecnologa de cortafuegos.
Muchos de los algoritmos criptogrficos, protocolos y aplicaciones de seguridad en
redes descritos en este libro han sido especificados como estndares. Los ms impor
tantes de ellos son los Estndares de Internet, definidos en los RFC de Internet (Request
for Comments), y Federal Information Processing Standards (FIPS), publicados por el
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
NIST (National Institute ofStandards and Technology. El apndice A presenta un lis
tado de los estndares citados en este libro.
1.8 BIBLIOGRAFA RECOMENDADA
[PFLE97] proporciona una buena introduccin a la seguridad de computadores y de
redes. Otro estudio excelente es [NICH99]. [SCHNOO] es una lectura valiosa para cual
quier iniciado en el campo de la seguridad en computadores y redes: trata las limitacio
nes de la tecnologa y la criptografa en particular, a la hora de proporcionar seguridad,
y la necesidad de tener en cuenta el hardware, la implementacin de software, las redes
y las personas implicadas en proporcionar seguridad y en atacarla.
NICH99 Nichols, R. Ed. ICSA Guide to Cryptography. New York: McGraw-Hill, 1999.
PFLE97 Pfleeger, C. Security in Computing. Upper Saddle River, NJ: Prentice Hall,
1997.
SCHNOO Schneier, B. Secrets and Les: Digital Security in a Networked World. New
York: Wley, 2000.
1.9 RECURSOS WEB Y DE INTERNET
Existe una serie de recursos web y de Internet que sirven de apoyo a este libro y que pue
den ayudar a seguir el ritmo de los avances en este campo.
SITIOS WEB PARA ESTE LIBRO
Se ha creado una pgina web especial para este libro en:
WilliamStallings.com/NetSec2e.html
El sitio incluye lo siguiente:
Sitios web tiles: enlaces a otros sitios web relevantes, organizados en captulos,
que incluyen los sitios que se mencionan en esta seccin y a lo largo de este libro.
Fe d e erratas se mantiene y actualiza la fe de erratas de este libro. Se agradecen
las indicaciones por correo electrnico sobre cualquier error que se encuentre. La
fe de erratas de mis otros libros se encuentran en WilliamStallings.com.
F ig u r as todas las figuras de este libro en formato PDF (Adobe Acrobat).
Tablas todas las tablas de este libro en formato PDF.
Diapositivas una serie de diapositivas en Power Point, organizadas por captulos.
l i s t a d e carreo d e U n t : el sitio incluye informacin para participar en la lis
ta de correo de Internet del libro.
www.FreeLibros.org
Captulo 1 / Introduccin 23
Cursos d e segiridad d e redes: hay enlaces a pginas de cursos basados en este
libro y que pueden aportar ideas a otros profesores sobre cmo estructurar el curso.
Tambin se mantiene el sitio de recursos para estudiantes de Ciencias de la Computa
cin en:
WilliamStallings.com/StudentSupport.html
La finalidad de este sitio es la de proporcionar documentos, informacin y enlaces
para estudiantes y profesionales del campo de la Computacin. Los enlaces y documen
tos estn organizados en cuatro categoras:
Matemticas incluye un curso bsico de matemticas, un libro de texto de anli
sis de colas, un libro de texto de sistemas de nmeros y enlaces a numerosos sitios
de matemticas.
Gua (bow-iq): recomendaciones e indicaciones para resolver problemas, escribir
informes tcnicos y preparar presentaciones tcnicas.
Recursos d e invcstigftfri: enlaces a artculos, informes tcnicos y bibliografas.
Miscelnea: otros documentos y enlaces tiles.
OTROS SITIOS WEB
Hay numerosos sitios web que proporcionan informacin relacionada con los temas de
este libro. En la seccin de Bibliografa y sitios web recomendados de captulos poste
riores, se pueden encontrar enlaces a sitios web especficos. Como las direcciones de los
sitios web cambian con frecuencia, no estn incluidas en el libro. Para todos los sitios
web mencionados en este libro se puede encontrar el enlace adecuado en el sitio web del
mismo, al que, adems, se irn aadiendo otros enlaces que no se han mencionado.
Los siguientes sitios web de inters general estn relacionados con la criptografa y
la seguridad de redes:
COAST: serie exhaustiva de enlaces relacionados con la criptografa y la seguri
dad de redes.
IETF Securty Arca: material relacionado con la estandarizacin de la seguridad
de Internet.
Computer and Network Security Referente Index: un buen ndice para pro
ductos comerciales, preguntas ms frecuentes (FAQs), archivos de grupos de noti
cias, artculos y otros sitios web.
T h e C i y p t o ^ a p h y FAQ: extensa y til lista de preguntas ms frecuentes que
cubren todos los aspectos de la criptografa.
Tcm DunigaTs Security PagK una excelente lista de enlaces a sitios web sobre
criptografa y seguridad de redes.
IEEE Tedinical Committeeon Security and Prvacy: copias de sus newsletters,
informacin sobre las actividades relacionadas con IEEE.
Computo* Security Resource Ceuta*: mantenido por el Instituto Nacional de
Estndares y Tecnologa (NIST); contiene una amplia informacin sobre amenazas
a la seguridad, tecnologa y estndares.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
GRUPOS DE NOTICIAS DE USENET
Una serie de grupos de noticias de USENET estn dedicados a algn aspecto de la segu
ridad de redes o la criptografa Como con casi todos los grupos de USENET, hay un
alto ndice de ruido a seal, pero vale la pena comprobar si alguno cubre sus necesida
des. Los ms importantes son los siguientes:
scryptresearch: es el grupo ms interesante. Es un grupo moderado que trata
temas de investigacin; las consultas y comentarios deben guardar alguna relacin
con los aspectos tcnicos del cifrado.
sd ciy p t: discusin general sobre cifrado y otros temas relacionados.
a y p t r a n d a n - i u i i b e r s : discusin sobre la aleatoriedad de la fuerza del cifrado.
a l t security: discusin general sobre temas de seguridad.
canp.security.iiiBc: discusin general sobre temas de seguridad de computa
dores.
ccmp.security.freivalfts: discusin sobre productos y tecnologa cortafuego.
ccmp.security.amounce noticias y anuncios de CERT.
comp.iisks: discusin sobre riesgos ocasionados por los computadores y los usua
rios.
comp.virus: discusin moderada sobre virus informticos.
www.FreeLibros.org
P A R T E I
CRIPTOGRAFA
CONTENIDO DE LA PRIMERA PARTE
L
a herramienta automatizada ms importante, con diferencia, para la seguridad de
redes y comunicaciones es el cifrado. Habitual mente se usan dos formas de cifra
do: cifrado convencional o simtrico, y cifrado de clave pblica o asimtrico. La
Primera Parte de este libro ofrece un estudio de los principios bsicos de la criptografa
simtrica y de clave pblica, muestra los algoritmos de uso ms comn y discute la apli-
cabilidad bsica de los dos enfoques.
G U A PARA LA PRIMERA PARTE
CAPTULO 2. CIFRADO SIMTRICO Y CONFIDENCIALIDAD DE MENSAJES
El Captulo 2 se centra en el cifrado simtrico, resaltando la tcnica de cifrado que ms
se usa, el DES (Data Encrypton Standard) y sus sucesores, la versin de triple clave del
DES y el AES (Advanced Encrypton Standard). Adems de las cuestiones que tratan de
la construccin real de un algoritmo de cifrado simtrico, se relaciona una serie de as
pectos de diseo con el uso del cifrado simtrico para proporcionar confidencialidad. El
Captulo incluye una discusin sobre el cifrado de mensajes largos, cifrado extremo a
extremo frente a cifrado de enlace, y tcnicas de distribucin de claves.
CAPTULO 3. CRIPTOGRAFA DE CLAVE PBLICA Y AUTENTIFICACIN
DE MENSAJES
De igual importancia que la confidencialidad, como medida de seguridad, es la autenti
ficacin. Como mnimo, la autentificacin de mensajes garantiza que el mensaje pro
viene de la fuente esperada. Adems, la autentificacin puede incluir proteccin contra
la modificacin, el retraso, la repeticin y el reordenamiento. El Captulo 3 comienza
con un anlisis de requisitos para la autentificacin y presenta, a continuacin, una se-
www.FreeLibros.org
rie de enfoques. Un elemento fundamental de los esquemas de autentiflcacin es el uso
de un autentificador, normalmente un cdigo de autentiflcacin de mensaje (MAC: Mes-
sage Authentcation Code) o una funcin hash. Se examinan consideraciones de diseo
para ambos tipos de algoritmos y se analizan varios ejemplos especficos.
Despus del cifrado simtrico, el otro mtodo importante de cifrado es el de clave
pblica, que ha revolucionado la seguridad en las comunicaciones. El Captulo 3 intro
duce el cifrado de clave pblica. El algoritmo RSA se examina detalladamente y se re
considera el problema de la gestin de claves. Tambin se expone la tcnica extendida
de intercambio de claves de Diffie-Hellman. Adems, se define la firma digital y se exa
mina su aplicacia
www.FreeLibros.org
C A P T U L O 2
Cifrado simtrico
y confidencialidad
de mensajes
2.1. Principios del cifrado simtrico
C r i p t o g r a f a
C r i p t o a n l i s i s
E s t r u c t u r a d e c i f r a d o F e i s t e l
2.2. Algoritmos de cifrado simtrico
D E S ( D a t a E n c r y p t i o n S t a n d a r d )
T r i p l e D E S
A E S ( A d v a n c e d E n c r y p t i o n S t a n d a r d )
O t r o s c i f r a d o r e s s i m t r i c o s d e b l o q u e
2.3. Modos de operacin del cifrado de bloques
M o d o C B C ( C i p h e r B l o c k C h a i n i n g )
M o d o C F B ( C i p h e r F e e d b a c k )
2.4. Ubicacin de los dispositivos de cifrado
2.5. Distribucin de claves
2.6. Bibliografa y sitios web recomendados
2.7. Palabras clave, preguntas de repaso y problemas
P a l a b r a s c l a v e
P r e g u n t a s d e r e p a s o
P r o b l e m a s
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Mungo haba estado trabajando toda la tarde en el cdigo Stem, ayudado principal
mente de los ltimos mensajes que haba interceptado durante la cada del sistema de
Nevin Square. El cdigo Stem era muy seguro. El deba ser consciente de que la Cen
tral de Londres saba sobre esa cada. Se sentan tan seguros de la impenetrabilidad del
cdigo que no les importaba con qu frecuencia Mungo lea sus mensajes.
H a b la r con desconocidos R ut h R endell
Entre las tribus de Australia Central, cada hombre, mujer y nio tiene un nombre secre
to o sagrado que el ms anciano decide al poco de nacer l o ella, y que no conoce na
die sino los miembros totalmente integrados en el grupo. Este nombre secreto nunca se
menciona excepto en las ocasiones ms solemnes; pronunciarlo al odo de un hombre de
otro grupo sera una seria violacin de la costumbre tribal. Cuando se menciona uno de
esos nombres, se hace con voz muy baja y tomando todas las precauciones para que na
die de otro grupo pueda orlo. Los nativos creen que un extrao que conozca su nombre
secreto tendra poder especial para causarle algn mal por medio de la magia.
L a ram a dorada, Snt J a m e s G e o r g e F ra zer
E
l cifrado simtrico, tambin conocido como cifrado convencional, de clave secre
ta o de clave nica, era el nico que se usaba antes del desarrollo del cifrado de
clave pblica a finales de los 7 0 An hoy contina siendo el ms usado de los
dos tipos de cifrado.
Este Captulo comienza presentando un modelo general del proceso de cifrado si
mtrico, permitindonos con ello entender el contexto en que se usan los algoritmos.
Luego se analizan tres algoritmos de cifrado importantes: DES, triple DES y AES. Tam
bin se examina la aplicacin de estos algoritmos para obtener confidencialidad.
2 .1 PRINCIPIOS DEL CIFRADO SIMTRICO
Un esquema de cifrado simtrico tiene cinco componentes (Figura 2.1):
Texto daro: es el mensaje o los datos originales que se introducen en el algoritmo
como entrada.
Algoritmo de cifrado: el algoritmo de cifrado realiza varias sustituciones y trans
formaciones en el texto claro.
Clave secreta la clave es tambin una entrada del algoritmo. Las sustituciones y
transformaciones realizadas por el algoritmo dependen de ella.
Texto cifrados el mensaje ilegible que se produce como salida. Depende del texto
claro y de la clave secreta. Para un mensaje determinado, dos claves diferentes pro
duciran dos textos cifrados diferentes.
1 El cifrado de clave pblica se describi por primera vez en 1976; la National Security Agency (NSA)
afirma haberlo descubierto unos aos antes.
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 29
Clave secreta compartida Clave secreta compartida
por emisor y receptor por emisor y receptor
de texto Algoritmo de cifrado Algoritmo de descifrado de texto
claro (por ejemplo, DES) (Inverso del d e cifrado) claro
Figura 2.1 M o d e l o s i m p l i f i c a d o d e l c i f r a d o c o n v e n c i o n a l
Algoritmo d e descifrado: Es, bsicamente, el algoritmo de cifrado ejecutado a la
inversa. Toma el texto cifrado y la misma clave secreta, y genera el texto claro.
Hay dos requisitos para el uso seguro del cifrado simtrico:
1. Se necesita un algoritmo de cifrado robusto. Como mnimo nos gustara que un
oponente que conozca el algoritmo y tenga acceso a uno o ms textos cifrados
no pudiera descifrar el texto o averiguar la clave. Este requisito se expresa ge
neralmente de forma ms rotunda: el atacante no debera poder descifrar el tex
to o averiguar la clave aunque estuviera en posesin de una serie de textos ci
frados junto con sus correspondientes textos originales.
Z El emisor y el receptor deben haber obtenido copias de la clave secreta de forma
segura y deben guardarla de la misma manera. Si alguien descubre la clave y co
noce el algoritmo, todas las comunicaciones que usen esa clave son descifrables.
Es importante observar que la seguridad del cifrado simtrico depende de la privacidad
de la clave, no de la privacidad del algoritmo. Es decir, se asume que no es prctico des
cifrar un mensaje teniendo el texto cifrado y conociendo el algoritmo de cifrado/desci
frado. En otras palabras, no es necesario que el algoritmo sea secreto; lo nico que hay
que mantener en secreto es la clave.
Esta caracterstica del cifrado simtrico es la causa de su uso tan extendido. El hecho
de que el algoritmo no tenga que ser secreto significa que los fabricantes pueden desa
rrollar y han desarrollado implementaciones con chips de bajo coste de los algoritmos
de cifrado de datos. Esos chips se pueden conseguir fcilmente y se han incorporado a
una serie de productos. Con el uso de cifrado simtrico, el problema principal de segu
ridad consiste en mantener la privacidad de la clave.
CRIPTOGRAFA
Generalmente, los sistemas criptogrficos se clasifican atendiendo a tres factores inde
pendientes:
L El tipo d e operacin utilizado para transformar d tocto daro en todo ci
frado. Todos los algoritmos de cifrado se basan en dos principios generales: sus
titucin, donde cada elemento de texto claro (bit, letra, grupo de bits o letras) se
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
sustituye por otro diferente; y transposicin, donde los elementos del texto cla
ro se reordenan. Lo fundamental del proceso es que no se pierda informacin (es
decir, que todas las operaciones sean reversibles). La mayora de los sistemas
emplean mltiples etapas de sustituciones y transposiciones.
Z El nmero d e daves usadas. Si tanto el emisor como el receptor usan la mis
ma clave, el sistema se denomina simtrico, de clave nica, de clave secreta, o
cifrado convencional. En cambio, si el emisor y el receptor usan cada uno claves
diferentes, el sistema se denomina asimtrico, de dos claves, o cifrado de clave
pblica.
3 La fin n a d e procesar d trato clara Un cifrador de bloque procesa un bloque
de elementos cada vez, produciendo un bloque de salida por cada bloque de en
trada. Un cifrador de flujo procesa los elementos de entrada continuamente, pro
duciendo la salida de un elemento cada vez.
CRIPTOANALISIS
El criptoanlisis es el proceso por el que se intenta descubrir un texto claro o una clave
de cifrado. La estrategia usada por el criptoanalista depende de la naturaleza del esque
ma de cifrado y de la informacin disponible.
La Tabla 2.1 resume los diferentes tipos de ataques criptoanalticos, basados en la
cantidad de informacin que posee el criptoanalista. El caso ms difcil es aquel en que
la nica informacin disponible es el texto cifrado. En algunos casos ni siquiera se co
noce el algoritmo de cifrado, pero en general se asume que el atacante lo conoce. Un po
sible ataque en estas circunstancias es el de fuerza bruta, intentando probar con todas las
claves posibles. Si el espacio de claves es muy grande, este enfoque es invable. En tal
caso, el atacante debe contar con un anlisis del texto cifrado, aplicndole, generalmen
te, varas pruebas estadsticas. Para utilizar este enfoque, el oponente debe tener alguna
idea general del tipo de texto claro implicado (texto en ingls o francs, un fichero EXE,
un listado de cdigo fuente de Java, un fichero de cuentas, etc.).
El ataque con slo texto cifrado es el ms fcil de evitar, ya que el oponente dispone
de la mnima cantidad de informacin con la que trabajar. En muchos casos, sin embar
go, el analista dispone de ms informacin. ste puede ser capaz de conseguir uno o ms
mensajes de texto claro y sus correspondientes cifrados, o podra saber que en un men
saje aparecern ciertos patrones de texto claro. Por ejemplo, un fichero codificado en for
mato PostScript siempre comienza con el mismo patrn, o podra haber un encabezado
estandarizado para un mensaje de transferencia electrnica de fondos, etc. stos son al
gunos ejemplos de texto claro conocido. Sabiendo esa informacin, el analista podra de
ducir la clave basndose en la forma en que se transforma el texto claro que conoce.
Estrechamente relacionado con el ataque de texto claro conocido se encuentra el que
se puede denominar como ataque de palabra probable. Si el atacante est trabajando con
el cifrado de algn mensaje general en prosa, podra tener poco conocimiento del con
tenido del mensaje. Sin embargo, si va tras alguna informacin especfica, entonces
podra conocer partes del mismo. Por ejemplo, si se est transmitiendo un fichero com
pleto de cuentas, el oponente podra conocer la situacin de ciertas palabras clave en el
encabezado del fichero. Otro ejemplo sera el hecho de que el cdigo fuente de un pro
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 31
grama desarrollado por una corporacin podra incluir informacin de copyright en al
guna posicin estandarizada.
Si el analista, de alguna forma, puede conseguir que el sistema fuente inserte en el
sistema un mensaje elegido por l, entonces se puede producir un ataque de texto claro
elegido. En general, si el analista es capaz de elegir los mensajes que va a cifrar, podra
captar deliberadamente patrones que se pueden esperar para revelar la estructura de la
clave.
La Tabla 2.1 presenta otros dos tipos de ataques: texto cifrado elegido y texto elegi
do. stos se utilizan menos como tcnicas criptoanalticas pero constituyen, no obstan
te, vas posibles para los ataques.
Tabla 2.1 T i p o s d e a t a q u e a m e n s a j e s c i f r a d o s
T i p o d e a t a q u e I n f o r m a c i n d e l c r i p t o a n a l i s t a
S l o t e x t o c i f ra do A l g o r i t m o d e c i f r a d o .
T e x to c i f r a d o q u e se v a a d e c o d i f i c a r .
Texto c l a r o c o n o c i d o A l g o r i t m o d e c i f r a d o .
T e x to c i f r a d o q u e s e v a a d e c o d i f i c a r .
U n o o m s p a r e s d e t e x t o c l a r o - t e x t o c i f r a d o f o r m a d o s
con l a c l a v e s e c re ta .
Texto c l a r o e l e g i d o A l g o r i t m o d e c i f r a d o .
T e x to c i f r a d o q u e se v a a d e c o d i f i c a r .
M e n s a j e d e t e x t o e n c l a r o e l e g i d o p o r e l c r i p t o a n a l i s t a
j u n t o co n su c o r r e s p o n d i e n t e t e x t o c i f r a d o g e n e r a d o
con l a c l a v e s e c re ta .
Texto c i f r a d o e l e g i d o A l g o r i t m o d e c i f r a d o .
T e x to c i f r a d o q u e s e v a a d e c o d i f i c a r .
T e x to c i f r a d o i n t e n c i o n a d o e l e g i d o p o r el c r i p t o a n a l i s t a ,
j u n t o co n su c o r r e s p o n d i e n t e t e x t o c l a r o d e s c i f r a d o g e
n e r a d o co n l a c l a v e s e c re ta .
Texto e l e g i d o A l g o r i t m o d e c i f r a d o .
T e x to c i f r a d o q u e s e v a a d e c o d i f i c a r .
M e n s a j e d e t e x t o c l a r o e l e g i d o p o r el c r i p t o a n a l i s t a j u n
to co n su c o r r e s p o n d i e n t e t e x t o c i f r a d o g e n e r a d o co n la
c l a v e se cre ta.
T e x to c i f r a d o i n t e n c i o n a d o e l e g i d o p o r el c r i p t o a n a l i s t a ,
j u n t o co n su c o r r e s p o n d i e n t e t e x t o c l a r o g e n e r a d o con
la c l a v e se cre ta.
Solamente un algoritmo relativamente dbil no resistira un ataque de slo texto ci
frado. Generalmente, un algoritmo de cifrado se disea para resistir un ataque de texto
claro conocido.
Un esquema de cifrado es canputacMnalmente seg^iro si el texto cifrado generado
cumple uno o los dos criterios siguientes:
El coste de romper el cifrado excede el valor de la informacin cifrada.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
El tiempo necesario para romper el cifrado excede el tiempo de vida til de la in
formacin.
El problema est en que es muy difcil estimar la cantidad de esfuerzo necesario para rea
lizar satisfactoriamente el criptoanlisis del texto cifrado. Sin embargo, si no hay debili
dades matemticas inherentes en el algoritmo, lo que procede es un enfoque de fuerza bru
ta, y aqu se pueden calcular algunas estimaciones razonables sobre costos y tiempo.
El enfoque de fuerza bruta implica intentar cada clave posible hasta que se obtenga
una traduccin legible del texto cifrado al texto claro. Como promedio, se debe intentar
la mitad de todas las claves posibles para conseguir descubrirla. La Tabla 2.2 muestra el
tiempo necesario para distintos tamaos de clave. El tamao de clave de 56 bits se usa
con el algoritmo DES (Data Encryption Standard). Para cada tamao de clave, se mues
tran los resultados suponiendo que cada operacin de descifrado simple necesita un ps,
lo cual es un valor razonable para las mquinas actuales. Con el uso de arquitecturas de
microprocesadores en paralelo, podra ser posible conseguir ratios de procesamiento de
mayor magnitud. La ltima columna de la Tabla 2.2 considera los resultados para un sis
tema que puede procesar un milln de claves por microsegundo. Como se puede ver, con
un nivel de rendimiento como ste, el DES dejara de ser computacionalmente seguro.
Tabla 2.2 T i e m p o m e d i o p a r a l a b s q u e d a e x h a u s t i v a d e c l a v e s
Tamao
de clave (bits)
Nmero
de claves
alternativas
Tiempo necesario
a 1 cifrado/ps
Tiempo
necesario a
106 cifrados/ps
32 232 = 4 , 3 x 109 2 31 p s = 3 5 , 8 m i n u t o s 2 , 1 5 m i l i s e g u n d o s
5 6 2 56 = 7,2 x 1016 2 55 p s = 1.142 aos 10,01 ho r a s
128 2 128 = 3 , 4 x 1038 2 127 p s = 5 , 4 x 1024 aos 5 , 4 x 1018 aos
168 2 168 = 3 , 7 x 105 2 167 p s = 5 , 9 x 1036 aos 5 , 9 x 103 a o s
2 6 ca rac ter es
( p e r m u t a c i n ) 26 ! = 4 x 1026 2 x 1026 p s = 6 , 4 x 1012 aos 6 , 4 x 106 aos
ESTRUCTURA DE CIFRADO FEISTEL
La mayora de los algoritmos de cifrado simtrico de bloque, incluido el DES, tienen
una estructura descrita inicialmente por Horst Feistel de IBM en 1973 [FEIS73], y que
se muestra en la Figura 2.2. Las entradas al algoritmo de cifrado son un bloque de tex
to claro de tamao 2 w bits y una clave K El bloque de texto claro se divide en dos mi
tades, Lq y tfp. Las dos mitades de datos pasan a travs de n etapas de procesamiento y
luego se combinan para producir el bloque de texto cifrado. Cada etapa i tiene como en
tradas L xy R. j, que se derivan de la etapa anterior, as como una subclave /^.generada
a partir de K En general, las subclaves K. son diferentes a K y entre ellas mismas, y se
generan a partir de la clave mediante un algoritmo de generacin de subclaves.
Todas las etapas tienen la misma estructura. Se realiza una sustitucin sobre la mitad
izquierda de los datos. Esto se hace aplicando una funcin de etapa F a la mitad derecha
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 33
de los datos y haciendo luego un OR exclusivo (XOR) de la salida de la funcin y la mi
tad izquierda de los datos. La funcin de etapa tiene la misma estructura general para cada
etapa pero est parametrizada por la subclave de etapa Kt Despus de esta sustitucin, se
realiza una permutacin que consiste en intercambiar las dos mitades de datos.
Texto claro (2 w bits)
Figura 2.2 R e d c l s i c a d e F e i s t e l
La realizacin exacta de una red de Feistel depende de la eleccin de los siguientes
parmetros y caractersticas de diseo:
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Tamao d d bloque: bloques mayores implican mayor seguridad (quedando igual
todo lo dems) pero reduce la velocidad de cifrado/descifrado. Un tamao de 64
bits es adecuado y es casi universal en el diseo del cifrador de bloques.
Tamao d e la clave: claves ms largas implican mayor seguridad pero puede re
ducir la velocidad de cifrado/descifrado. La longitud de clave ms comn en los
algoritmos modernos es de 128 bits.
Nmero d e etapas la esencia del cifrado de Feistel consiste en que mientras una
sola etapa ofrece una seguridad inadecuada, mltiples etapas la aumentan. Un va
lor tpico es 16 etapas.
Algoritmo degeneracin desubdaves cuanto ms complejo sea este algoritmo
ms difcil resultar el criptoanlisis.
Fundn d e etapa: otra vez, generalmente, a mayor complejidad mayor resisten
cia al criptoanlisis.
Hay otras dos consideraciones en el diseo del cifrado de Feistel:
Cifrado/descifrado mediante softw are rpido: en muchos casos, el cifrado es
parte de aplicaciones o funciones de utilidad, lo cual imposibilita una implemen-
tacin hardware. En esos casos, la rapidez de ejecucin del algoritmo es un aspecto
importante.
Facilidad d e anlisis: aunque sera deseable hacer el algoritmo tan difcil como fue
ra posible para el criptoanlisis, tambin es ventajoso hacerlo fcil de analizar. Es de
cir, si el algoritmo se puede explicar de manera concisa y clara, entonces es ms f
cil detectar las debilidades y por tanto desarrollar un nivel mayor de garantas en
funcin de su robustez. El DES, por ejemplo, no es fncionalmente fcil de analizar.
El descifrado es bsicamente igual que el proceso de cifrado. La regla es la siguiente:
usar el texto cifrado como entrada al algoritmo, pero usar las subclaves Ki en orden in
verso. Es decir, usar Kn en la primera etapa, K en la segunda, y as sucesivamente has
ta K{ en la ltima Es una ventaja ya que implica que no es necesario implementar dos
algoritmos diferentes, uno para el cifrado y otro para el descifrado.
2 . 2 ALGORITMOS DE CIFRADO SIMTRICO
Los algoritmos de cifrado simtrico ms comnmente usados son los cifradores de blo
ques. Un cifrador de bloques procesa la entrada de texto claro en bloques de tamao fijo
y genera un bloque de texto cifrado del mismo tamao para cada texto claro. Esta seccin
se centra en los tres cifradores de bloque simtrico ms importantes: el DES (Data
Encryption Standard) y el 3DES (triple DES), y el AES (Advanced Encryption Standard).
Adems, se muestran, brevemente, otros algoritmos de cifrado simtrico en uso.
DES (DATA ENCRYPTION STANDARD)
El esquema de cifrado ms extendido se basa en el DES (Data Encryption Standard)
adoptado en 1977 por el National Bureau of Standards, ahora el NIST (National Institu-
te of Standards and Technology), como Federal Information Processing Standard 46.
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 35
(FIPS PUB 46). Al algoritmo se le denomina DEA (Data Encrypton Algorithm) 2.
DESCRIPCIN DEL ALGORITMO
El texto claro tiene una longitud de 64 bits y la clave, de 56; si el texto claro es ms lar
go se procesa en bloques de 64 bits. La estructura del DES consiste en una pequea va
riacin de la red de Feistel, que se muestra en la Figura 2.2. Hay 16 etapas de proceso.
Se generan 16 subclaves partiendo de la clave original de 56 bits, una para cada etapa.
El proceso de descifrado con el DES es bsicamente el mismo que el de cifrado. La
regla es la siguiente: usar el texto cifrado como entrada al algoritmo del DES, pero las
subclaves K se pasan en orden inverso. Es decir, en la primera etapa se usa Kl6, Kl5 en
la segunda, y as hasta Kxen la 16a y ltima.
ROBUSTEZ DEL DES
Los aspectos de robustez del DES se engloban en dos categoras: aspectos sobre el al
goritmo mismo y aspectos sobre el uso de una clave de 56 bits. Los primeros se refieren
a la posibilidad de que el criptoanlisis se realice explotando las caractersticas del al
goritmo DES. A lo largo de los aos, se han intentado encontrar debilidades que explo
tar en el algoritmo, lo que ha hecho del DES el algoritmo de cifrado existente ms estu
diado. A pesar de los numerosos enfoques, nadie ha conseguido descubrir ninguna
debilidad grave en el DES3.
Un aspecto de mayor importancia es la longitud de la clave. Con una clave de 56 bits,
hay 256 claves posibles, que es aproximadamente 7,2 x 1016 claves. Por este motivo, no
parece prctico un ataque de fuerza bruta. Suponiendo que, en promedio, se tiene que
intentar la mitad del espacio de claves, una nica mquina que realice un cifrado DES
por microsegundo tardara ms de mil aos en romper el cifrado (vase la Tabla 2.2).
En cualquier caso, la suposicin de un cifrado por microsegundo es demasiado con
servadora. Finalmente y definitivamente, en julio de 1998, se prob que el DES no era
seguro, cuando la Electronic Frontier Foundation (EFF) anunci que haba roto un ci
frado DES utilizando una mquina especializada, DES cracker, construida por menos
de 250.000 dlares. El ataque dur menos de tres das. La EFF ha publicado la descrip
cin detallada de la mquina, haciendo posible que cualquiera construya su propio crac
ker [EFF98]. Naturalmente, los precios del hardware continuarn bajando mientras la
velocidad ir aumentando, haciendo al DES prcticamente intil.
Es importante tener en cuenta que para un ataque de bsqueda de clave no basta con
probar todas las posibles claves. A menos que se suministre el texto claro, el analista
debe ser capaz de reconocer el texto claro como tal. Si el mensaje es texto claro en in
gls, entonces el resultado se obtiene fcilmente, aunque la tarea de reconocimiento del
2 La terminologa es un poco confusa. Hasta hace poco, los trminos DES y DEA se usaban indistinta
mente. Sin embargo, la edicin ms reciente del documento del DES incluye una especificacin del DEA y
del triple DEA (3DES). Ambos son parte del DES (Data Encrypton Standard). Es ms, hasta la reciente
adopcin del trmino oficial 3DES, al algoritmo triple DEA se le denominaba triple DES y se escriba 3DES.
Fbr conveniencia, nosotros usaremos 3DES.
3 Al menos, nadie ha revelado pblicamente tal descubrimiento.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
ingls tendra que estar automatizada. S el mensaje de texto se ha comprimido antes del
cifrado, entonces el reconocimiento es ms difcil. Y si el mensaje es de un tipo ms ge
neral de datos, como un fichero numrico, y ha sido comprimido, el problema es an
ms difcil de automatizar. Por eso, para complementar el enfoque de fuerza bruta, se ne
cesita algn grado de conocimiento sobre el texto claro esperado y alguna forma de dis
tinguir automticamente el texto claro de lo que no lo es. El enfoque de la EFF trata
tambin este tema, e introduce algunas tcnicas automatizadas que seran efectivas en
muchos contextos.
Como punto final, si la nica forma de ataque a un algoritmo de cifrado es la fuerza
bruta, entonces la manera de contrarrestar ese ataque es obvia: usar claves ms largas.
Para tener una idea del tamao de clave necesario, usaremos el cracker de la EFF como
base de nuestras estimaciones. El cracker de la EFF era un prototipo, y se puede supo
ner que con la tecnologa actual es rentable construir una mquina ms rpida. Si asu
mimos que un dispositivo como el cracker puede realizar un milln de descifrados por
ps, que es el ratio usado en la Tabla 2.2, entonces se tardara alrededor de diez horas en
descifrar un cdigo DES. Esto constituye un incremento de velocidad en aproximada
mente un factor de siete comparado con los resultados de la EFF. Usando este ratio, la
Figura 2.3 muestra cunto se tardara en romper un algoritmo del estilo del DES en fun
cin del tamao de la clave. Por ejemplo, para una clave de 128 bits, que es comn en
tre los algoritmos actuales, se tardara 101aos en romper el cdigo usando el cracker
de la EFF. Incluso, aunque se aumentara la velocidad del cracker en un factor de un tri-
lln (1012), todava se tardara un milln de aos en romper el cdigo. As que una cla
ve de 128 bits garantiza que el algoritmo es inexpugnable por la fuerza bruta.
1044
1040
1036
1032
o
? 124
I 1020
g. 1016
11012
108
104
10
50 56 100 128 150 168 200
Longitud de la clave (bits)
Figura 2.3 T i e m p o e m p l e a d o e n r o m p e r u n c d i g o
( s u p o n i e n d o 1 0 6 d e s c i f r a d o s / p s )
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 3 7
TRIPLE DES
El triple DES (3DES) se estandariz inicialmente para aplicaciones financieras en el es
tndar ANSI X9.17 en 1985. El 3DES se incorpor como parte del DES en 1999, con la
publicacin de FIPS PUB 46-3.
El 3DES usa tres claves y tres ejecuciones del algoritmo DES. La funcin sigue la
secuencia cifrar-descifrar-cifrar (EDE: encrypt-decrypt-encrypt) (Figura 2.4a):
c = EK[DK2[EKm
donde
C = texto cifrado
P = texto claro
Ek[X\ = cifrado de t u s a n d o la clave K
Dk [ Y\ = descifrado de Y usando la clave K
El descifrado es simplemente la misma operacin con las claves en orden inverso (Fi
gura 2.4b):
P = DKx[E^[DK3[C[}\
K,
(a) Cifrado
B
I
K.
}
(b) Descifrado
Figura 2 . 4 T r i p l e D E S
El descifrado del segundo paso no es significativo en trminos criptogrficos. Su ni
ca ventaja es que permite a los usuarios del 3DES descifrar datos cifrados por usuarios
del DES:
C = EK[DKlEKm = EK[P\
Con tres claves diferentes, el 3DES tiene una longitud efectiva de clave de 168 bits. El
FIPS 46-3 tambin permite el uso de dos claves, con K = K3 lo que proporciona una lon
gitud de clave de 112 bits. El FIPS 46-3 incluye las siguientes directrices para el 3DES:
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
El 3DES es el algoritmo de cifrado simtrico oficial del FIPS.
El DES original, que usa una nica clave de 56 bits, se mantiene slo para los sis
temas existentes. Las nuevas adquisiciones deberan admitir 3DES.
Se apremia a las organizaciones gubernamentales con sistemas que usan DES a
migrar a 3DES.
Se prev que el 3DES y el AES (Advanced Encryption Stardard) coexistirn como
algoritmos oficiales del FIPS, permitiendo una transicin gradual hacia el AES.
Es fcil observar que el 3DES es un algoritmo robusto. Debido a que el algoritmo crip
togrfico que lo sustenta es el DEA, el 3DES resulta igual de resistente al criptoanlisis
basado en el algoritmo que el DEA. Es ms, con una clave de 168 bits de longitud, los
ataques de fuerza bruta son efectivamente imposibles.
ltimamente, el AES pretende reemplazar al 3DES, pero este proceso tardar unos
aos. El NIST ha anunciado que el 3DES se mantendr como algoritmo oficial (para uso
del gobierno estadounidense) durante los prximos aos.
AES (ADVANCED ENCRYPTION STANDARD)
El 3DES tiene dos atractivos que aseguran su uso durante los prximos aos. Primero,
con su longitud de clave de 168 bits evita la vulnerabilidad al ataque de fuerza bruta del
DEA. Segundo, el algoritmo de cifrado que usa es el mismo que en el DEA. Este algo
ritmo ha estado sujeto a ms escrutinios que ningn otro durante un largo perodo de
tiempo, y no se ha encontrado ningn ataque criptoanaltico efectivo basado en el algo
ritmo que no sea la fuerza bruta. Por tanto, hay un alto grado de seguridad en la resis
tencia al criptoanlisis del 3DES. Si la seguridad fuera la nica consideracin, el 3DES
sera una eleccin adecuada para un algoritmo de cifrado estndar durante las prximas
dcadas.
El inconveniente principal del 3DES es que el algoritmo es relativamente lento en su
implementacin software. El DEA original se dise para implementaciones hardware
de mediados de los 70 y no produce cdigo software eficiente. El 3DES tiene tres veces
ms etapas que el DEA y, por ello, es ms lento. Un inconveniente secundario es que
tanto el DEA como el 3DES usan un tamao de bloque de 64 bits. Por razones tanto de
eficiencia como de seguridad, es preferible un mayor tamao de bloque.
Debido a esos inconvenientes, el 3DES no es un candidato razonable para usarlo du
rante mucho tiempo. Para reemplazarlo, el NIST realiz en 1997 un concurso de pro
puestas para el desarrollo de un nuevo estndar de cifrado avanzado (AES), que debera
ser tan robusto o ms que el 3DES y que mejorara significativamente la eficiencia. Ade
ms de esos requisitos generales, el NIST especific que el AES deba ser un cifrador
simtrico de bloque con una longitud de bloque de 128 bits y permitir longitudes de cla
ve de 128, 192 y 256 bits. Los criterios de evaluacin incluyen la seguridad, la eficien
cia computacional, los requisitos de memoria, la idoneidad para hardware y software y
la flexibilidad.
En la primera etapa de evaluacin, se aceptaron 15 de los algoritmos propuestos. La
segunda etapa los redujo a cinco. El NIST complet el proceso de evaluacin y public
el estndar final (FIPS PUB 197) en noviembre de 2001. El algoritmo seleccionado por
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 39
el NIST como propuesta del AES fue el Rijndael, desarrollado y presentado por dos
criptgrafos belgas: Dr. Joan Daemen y Dr. Vincent Rijmen.
DESCRIPCIN DEL ALGORITMO
El AES usa una longitud de bloque de 128 bits, y la longitud de la clave puede ser de 128,
192 o 256 bits. En la descripcin de esta seccin se asume una longitud de clave de 128
bits, que posiblemente es la ms implementada.
La Figura 2.5 muestra la estructura general del AES. La entrada a los algoritmos de
cifrado y descifrado es un solo bloque de 128 bits. En el FIPS PUB 197, este bloque se
representa como una matriz cuadrada de bytes. Este bloque se copia en el vector Esta
do, que se modifica en cada etapa del cifrado o descifrado. Despus de la ltima etapa,
Estado se copia en una matriz de salida. De igual manera, la clave de 128 bits se repre
senta como una matriz cuadrada de bytes. Esta clave luego se expande en un vector de
palabras para la generacin de claves; cada palabra tiene cuatro bytes, y el nmero total
de palabras para generar claves es de 44 para la clave de 128 bits. El orden de los bytes
dentro de una matriz se establece por columnas. As, por ejemplo, los primeros cuatro
bytes de una entrada de texto claro de 128 bits al cifrador ocupan la primera columna de
la matriz n, los segundos cuatro bytes la segunda columna, y as sucesivamente. De
igual forma, los primeros cuatro bytes de la clave expandida, que forman una palabra,
ocupan la primera columna de la matriz w.
Los siguientes comentarios revelan algunos aspectos del AES:
1. Una caracterstica notable de su estructura es que no es una estructura Feistel.
En la estructura clsica de Feistel, la mitad del bloque de datos se usaba para mo
dificar la otra mitad, y entonces se intercambiaban entre s. El AES procesa todo
el bloque de datos en paralelo durante cada etapa, realizando sustituciones y per
mutaciones.
2. La clave suministrada como entrada se expande en un vector de 44 palabras de
32 bits, w[f]. Cuatro palabras diferentes (128 bits) sirven como clave de etapa en
cada ronda.
3. Se utilizan cuatro fases diferentes, una de permutacin y tres de sustitucin:
Sustitucin d e bytes: se usa una tabla, denominada cajaS\ para realizar una
sustitucin byte a byte del bloque.
Desplazamiento d e filas: una simple permutacin realizada fila por fila.
Mezcla d e columnas: una sustitucin que altera cada byte de una columna en
funcin de todos los bytes de la columna.
Suma de la dave de etapa: una simple operacin XOR bit a bit del bloque
actual con una porcin de la clave expandida.
4 La estructura es muy simple. Tanto para el cifrado como para el descifrado, se
comienza con una fase de suma de clave de etapa, seguido de nueve etapas de
4 El trmino caja S (caja de sustitucin) se utiliza normalmente en la descripcin de cifradores simtri-
( d s para referirse a un tipo de tabla de consulta usada por el mecanismo de sustitucin.
www.FreeLibros.org
E
t
a
p
a

1
0

E
t
a
p
a

9
E
t
a
p
a

1
Fundamentos de seguridad en redes. Aplicaciones y estndares
Texto claro
1
Suma de clave de etapa
i
Sustitucin de bytes
*
Desplazamiento de filas

Mezcla de columnas
i
Suma de clave de etapa
Sustitucin de bytes
i
Desplazamiento de filas
Mezcla de columnas
i
Suma de clave de etapa
V
Suma de clave de etapa
i
Sustitucin de bytes
a la Inversa
i
Desplazamiento
de filas a la inversa
Clave
w[0, 3]
Sustitucin de bytes
w[4, 7]
w[36, 39]
w[40, 43]
Texto claro
A
Suma de clave de etapa

Sustitucin de bytes
a la inversa
A
co
Q .
2
lL
Desplazamiento
cte filas a la inversa
Mezcla de columnas
a la Inversa
A. ___
Suma de clave de etapa
A
Sustitucin de bytes
a la inversa
Desplazamiento
de filas a la inversa
Mezcla de columnas
a la inversa

Suma de clave de etapa


Sustitucin de bytes
a la Inversa

Desplazamiento
de filas a la inversa
A
Suma de clave de etapa
(a) Texto cifrado
Figura 2.5
(b) Texto cifrado
Cifrado y descifrado AES
cuatro fases cada una, y acaba con una dcima etapa de tres fases. La Figura 2.6
muestra la estructura de una etapa completa de cifrado.
5l Solamente la fase de suma de la clave de etapa utiliza la clave. Por esta razn el
cifrador comienza y termina con una suma de clave de etapa. Cualquier otra fase,
aplicada al comienzo o al final, sera reversible sin conocer la clave y por tanto
aadira inseguridad.
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 41
Figura 2.6 Etapa de cifrado del AES
& La fase de suma de la clave de etapa no funcionara por s misma. Las otras tres
fases juntas desordenan los bits, pero no proporcionan seguridad por s mismas,
porque no usan la clave. Se puede ver el cifrador como una secuencia alterna
tiva de operaciones de cifrado XOR (suma de clave de etapa) de un bloque, se
guida por un desordenamiento del bloque (las otras tres fases), seguida por un
cifrado XOR, y as sucesivamente. Este esquema es eficiente y muy seguro.
7. Cada fase es fcilmente reversible. Para las fases de sustitucin de byte, des
plazamiento de fila y mezcla de columnas, se usa una funcin inversa en el al
goritmo de descifrado. Para la fase de suma de clave de etapa, la inversa se con
sigue con un XOR entre la misma clave de etapa y el bloque, usando la
propiedad de que A A B = B.
& Como con la mayora de los cifradores de bloque, el algoritmo de descifrado
hace uso de la clave expandida en orden inverso. De todas formas, como con
secuencia de la estructura particular del AES, el algoritmo de descifrado no es
idntico al de cifrado.
9l Una vez se ha establecido que las cuatro fases de cada etapa son reversibles, es
fcil verificar que el descifrado recupera el texto claro. La Figura 2.5 muestra
el cifrado y el descifrado desplazndose en direcciones verticalmente opuestas.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
En cada punto horizontal (por ejemplo, la lnea discontinua de la figura), Esta
do es el mismo para el cifrado y para el descifrado.
10. La ltima etapa de cifrado y descifrado consiste slo en tres fases. Otra vez,
esto es consecuencia de la estructura particular del AES y es necesario para que
el cifrador sea reversible.
OTROS CIFRADORES DE BLOQUE SIMTRICOS
En vez de renventar de nuevo la rueda, casi todos los algoritmos de cifrado de bloque
simtricos actuales utilizan la estructura bsica de bloque de Feistel. Esto se debe a que
dicha estructura se comprende muy bien, resultando ms fcil determinar la robustez
criptogrfica de un algoritmo nuevo. Si se usara una estructura totalmente nueva, podra
tener alguna debilidad sutil no detectada inmediatamente por el diseador. En esta sec
cin se vern otros cifradores que, al igual que el DES y el 3DES, han tenido aceptacin
comercial. En la Tabla 2.3 se comparan algunas de las principales caractersticas.
Tabla 2.3 Algoritmos de cifrado convencional
Algoritmo
Tamao de clave
(bits)
Tamao de
bloque (bits)
Nmero
de etapas Aplicaciones
DES 56 6 4 16 SET, K e r b e r o s
T r i p l e DES 112 o 168 6 4 48 F i n a n c i a l k e y m a n a -
g e m e n t , PGP,
S / M I M E
AES 1 2 8 , 1 9 2 o 2 5 6 128 10, 12 o 14 D e s t i n a d o a s u s t i t u ir
DES y 3 DE S
I D E A 128 6 4 8 PGP
B lo w fis h V a r i a b l e
h a s ta 448
6 4 16 V a r i o s p a q u e t e s d e
s o f t w a r e
RC5 V a r i a b l e
h a s t a 2 0 4 8
64 V a r i a b l e
h a s ta 2 5 5
V a r i o s p a q u e t e s d e
s o f t w a r e
IDEA
El IDEA (International Data Encrypton Algorithm) es un cifrador de bloque simtrico
desarrollado por Xuejia Lai y James Massey del Instituto Federal Suizo de Tecnologa
en 1991 [LAI91]. El IDEA usa una clave de 128 bits. Difiere notablemente del DES en
la funcin de etapa as como en la funcin de generacin de subclaves. Para la funcin
de etapa el IDEA no usa cajas S, sino que cuenta con tres operaciones matemticas di
ferentes: XOR, suma binaria de enteros de 16 bits, y multiplicacin binaria de enteros
de 16 bits. Esas funciones se combinan de tal forma que producen una transformacin
compleja muy difcil de analizar, y por ende muy difcil para el criptoanlisis. El algo
ritmo de generacin de subclave se basa solamente en el uso de desplazamientos circu
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 4 3
lares pero ejecutados de manera compleja para generar un total de seis subclaves para
cada una de las ocho etapas del IDEA.
Debido a que el IDEA fue uno de los primeros algoritmos de 128 bits de los pro
puestos para remplazar al DES, ha sido sometido a considerables exmenes y por ahora
parece ser muy resistente al criptoanlisis. El IDEA se usa como una alternativa en PGP
(Pretty Good Prvacy) y tambin en una serie de productos comerciales.
BLOWFISH
El Blowsh fue desarrollado en 1993 por Bruce Schneier [SCHN93, SCHN94], asesor y
criptgrafo independiente, y consigui ser rpidamente una de las alternativas ms popu
lares al DES. Se dise para que fuera fcil de implementar y rpido en su ejecucin. Tam
bin es un algoritmo muy compacto que puede ejecutarse en menos de 5K de memoria.
Una caracterstica interesante es que la longitud de la clave es variable, pudiendo alcanzar
hasta los 448 bits. En la prctica se usan claves de 128 bits. El Blowsh usa 16 etapas.
Utiliza cajas S y la funcin XOR, como el DES, pero tambin utiliza sumas bina
rias. Al contrario que el DES, que utiliza cajas S estticas, Blowsh usa cajas S din
micas generadas como una funcin de la clave. Las subclaves y las cajas S se generan
por la aplicacin repetida del propio algoritmo a la clave. Se necesita un total de 521
ejecuciones del algoritmo de cifrado Blowsh para producir las subclaves y las cajas S.
Por este motivo no es adecuado para aplicaciones en las que la clave secreta cambia fre
cuentemente.
Este es uno de los algoritmos de cifrado simtrico ms robustos hasta la fecha, por
que tanto las subclaves como las cajas S se generan por un proceso de aplicaciones re
petidas del propio algoritmo, lo cual modifica totalmente los bits haciendo muy difcil
el criptoanlisis. Hasta ahora, se han publicado algunos artculos sobre el Blowsh, sin
que se hayan encontrado debilidades.
Este algoritmo se usa en varias aplicaciones comerciales.
RC5
El RC5 fue desarrollado en 1994 por Ron Rivest [RIVE94, RIVE95], uno de los inven
tores del algoritmo de clave pblica RSA. El RC5 se define en el RFC 2040 y se dise
para tener las siguientes caractersticas:
Adecuado para hardw arey sofhvarv: slo usa operaciones computacionales pri
mitivas que se encuentran comnmente en los microprocesadores.
Rpido; para conseguir esto, el RC5 es un algoritmo simple y orientado a pala
bras. Las operaciones bsicas procesan palabras enteras de datos cada vez.
Adaptable a procesadores con diferentes tamaos d e palabra: el nmero de
bits en una palabra es un parmetro del RC5; diferentes longitudes de palabra pro
ducen algoritmos diferentes.
Nmero variable d e etapas: el nmero de etapas es un segundo parmetro. Esto
permite alcanzar un compromiso entre mayor rapidez y mayor seguridad.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Lmjtud d e clave variables la longitud de la clave es un tercer parmetro. Otra
vez, posibilita un acuerdo entre velocidad y seguridad.
Simples la estructura simple del RC5 es fcil de implementar y facilita la tarea de
determinar la robustez del algoritmo.
Bajo consuno d e memoria: la poca necesidad de memoria hace que el RC5 sea
adecuado para tarjetas inteligentes y otros dispositivos con restricciones de me
moria.
Alta seguridad: proporciona alta seguridad con los parmetros adecuados.
Rotaciones dependientes d e los datos: incorpora rotaciones (desplazamientos
circulares de bits) cuya cantidad depende de los datos. Esto parece fortalecer el al
goritmo contra el criptoanlisis.
El RC5 se usa en varios productos de la RSA Data Security, Inc.
2 . 3 M O D O S DE OPERACIN DEL CIFRADO DE BLOQUES
Un cifrador simtrico de bloque procesa un bloque de datos cada vez. En el caso del DES
y el 3DES, la longitud del bloque es de 64 bits. Para cantidades mayores de texto claro, es
necesario trocearlo en bloques de 64 bits (rellenando el ltimo bloque si fuera necesario).
La forma ms sencilla de proceder es la que se conoce como modo ECB (electronic co-
debook), en el cual se manejan 64 bits cada vez y cada bloque de texto claro se cifra con
la misma clave. Se usa el trmino codebook (libro de cdigos) porque para una clave dada
hay un nico texto cifrado por cada bloque de 64 bits de texto claro. Por eso, nos podemos
imaginar un libro de cdigos gigantesco en el que hay una entrada para cada posible pa
trn de texto claro de 64 bits junto con su correspondiente texto cifrado.
Con el ECB, si el mismo bloque de texto claro de 64 bits aparece ms de una vez en
el mensaje, ste siempre produce el mismo texto cifrado. Por este motivo, para mensa
jes largos, el modo ECB puede no ser seguro. S el mensaje est muy estructurado, un
criptoanalista podra explotar esas regularidades. Por ejemplo, si se sabe que el mensa
je comienza siempre con ciertos campos predefinidos, entonces el criptoanalista podra
conocer un buen nmero de pares de texto claro-texto cifrado con los que trabajar. Si el
mensaje contiene elementos repetitivos, con un perodo de repeticin mltiplo de 64
bits, entonces el criptoanalista puede identificar dichos elementos, lo cual puede ayu
darle en el anlisis u ofrecerle la oportunidad de sustituir o reorganizar bloques.
Para superar las deficiencias de seguridad del ECB, necesitaramos una tcnica en la
que el mismo bloque de texto claro, si se repite, produzca diferentes bloques de texto ci
frado. En esta seccin veremos dos alternativas comunes, definidas en FIPS PUB 81.
MODO CBC (CIPHER BLOCK CHAINING)
En el modo CBC (Cipher Block Chaing) (Figura 2.7), la entrada al algoritmo de cifra
do es el XOR entre el bloque de texto claro actual y el bloque de texto cifrado anterior;
se usa la misma clave para cada bloque. Se ha encadenado el procesamiento de la se
cuencia de bloques de texto claro. La entrada a la funcin de cifrado para cada bloque
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 45
de texto claro no mantiene una relacin fija con dicho bloque. Por lo tanto, no se expo
nen los patrones de 64 bits que se repiten.
Para descifrar cada bloque de cifrado se pasa por el algoritmo de descifrado. Con el
resultado y el bloque texto cifrado precedente se hace un XOR para obtener el bloque
de texto claro. Para comprobar que funciona, se puede escribir
Cj = 1 P}
Donde EK[X\ es el cifrado del texto claro X usando la clave K, y es la operacin
OR exclusivo. Entonces
D * [ q = dk[ek(cm P}\
D Q = (C P)
Cf \ D fCj] = CM 0 CM P= Pj
lo que verifica la Figura 2.7b.
Time = 1
IV Pi
Time = 2 Time = N
K Cifrar K Cifrar
C A/-1
K Cifrar
(a) Cifrado
1
C2
1
1
Descifrar K Descifrar K Descifrar
(b) Descifrado
Figura 2.7 Modo CBC
Para producir el primer bloque de texto cifrado se realiza un XOR de un vector de
inicializacin (IV, Intializaton Vector) con el primer bloque de texto claro. Al descifrar,
se hace un XOR de IV con l a salida del algoritmo de descifrado para recuperar el pri
mer bloque de texto claro.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
El IV debe ser conocido por el emisor y el receptor. Para mxima seguridad, el IV
debera ser protegido, al igual que la clave. Esto podra hacerse enviando el IV utilizan
do cifrado ECB. Una razn para proteger el IV es la siguiente: si un atacante puede en
gaar al receptor para que use un valor diferente del IV, entonces el atacante tiene la
posibilidad de invertir determinados bits del primer bloque de texto claro. Para verlo,
considrese lo siguiente:
q = Ef IV P,)
P ^ N Q D / q )
Ahora usando la notacin de que X\J representa el j-simo bit de los 64 bits de X.
Entonces
= DQ\j\
Usando las propiedades de XOR se puede establecer
P\\j[ = w\j\' DfQ\J\
donde la notacin prima indica el complemento de bit. Esto significa que si un atacante
tiene la posibilidad de cambiar bits en IV, los bits correspondientes del valor de P , reci
bido tambin se pueden cambiar.
El modo CBC se utiliza en aplicaciones de seguridad, como se ver en la Segunda
Parte.
MODO CFB ( CIPHER FEEDBACK)
Es posible convertir cualquier cifrador de bloque en un cifrador de flujo usando el modo
de realimentacin de cifrado (CFB). Un cifrador de flujo elimina la necesidad de com
pletar el ltimo bloque de un mensaje para que tenga la longitud requerida. Tambin
puede operar en tiempo real. As, si se est transmitiendo una ristra de caracteres, se pue
de cifrar y transmitir inmediatamente cada carcter usando un cifrador de flujo orienta
do al mismo.
Una propiedad deseable de un cifrador de ristra es que el texto cifrado sea del mis
mo tamao que el texto claro. As, si se estn transmitiendo caracteres de ocho bits, los
caracteres deberan cifrarse usando ocho bits. Si se usaran ms de ocho bits se estara
malgastando capacidad de transmisin.
La Figura 2.8 muestra el esquema del CFB. Se asume que la unidad de transmisin
es sbits; un valor comn es s = 8. Con el CBC las unidades de texto claro se encadenan
juntas, de manera que el texto cifrado de cualquier unidad de texto claro es funcin de
todos los textos claros anteriores.
En primer lugar, consideremos el cifrado. La entrada a la funcin de cifrado es un re
gistro de desplazamiento de 64 bits que al principio se inicializa con un vector (IV). A
los s bits ms a la izquierda (ms significativos) ae la salida de la funcin de cifrado se
les aplica un XOR con la primera unidad de texto claro Px para producir la primera uni
dad de texto cifrado Cv que luego se transmite. Adems, los contenidos del registro de
desplazamiento se mueven s bits a la izquierda y se coloca C{ en los s bits ms a la de
recha (menos significativos) del registro de desplazamiento. Este proceso contina has
ta que se hayan cifrado todas las unidades del texto claro.
www.FreeLibros.org
R
e
g
i
s
t
r
o

d
e

d
e
s
p
l
a
z
a
m
i
e
n
t
o

R
e
g
i
s
t
r
o

d
e

d
e
s
p
l
a
z
a
m
i
e
n
t
o

R
e
g
i
s
t
r
o

d
e

d
e
s
p
l
a
z
a
m
i
e
n
t
o

6
4
-
s

b
i
t
s

I
s
b
i
t
s

6
4
-
s

b
i
t
s

I
s
b
i
t
s

6
4
-
s
b
l
t
s

I
s
b
i
t
s
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 4 7
F
i
g
u
r
a

2
.
8

M
o
d
o

C
F
B

d
e

s
b
i
t
s
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Para descifrar se usa el mismo esquema, excepto que a la unidad de texto cifrado re
cibido se aplica el XOR con la salida de la funcin de cifrado para producir la unidad de
texto claro. Ntese que se usa la funcin de cifrado no la de descifrado. Esto es fcil de
explicar. Sea S^X) los s bits ms significativos de X Entonces
Cy = p x e s ^ E i m
Por lo tanto
Py = Cy SE[N))
El razonamiento es el mismo para los subsiguientes pasos del proceso.
2 . 4 UBICACIN DE LOS DISPOSI TI VOS DE CIFRADO
El enfoque ms potente y usual para contrarrestar las amenazas a la seguridad en la red
es el cifrado. Al usar cifrado se debe decidir qu cifrar y dnde situar los engranajes de
cifrado. Hay dos alternativas fundamentales: cifrado en enlace y cifrado extremo a ex
tremo; en la Figura 2.9 se ilustra su uso sobre una red de conmutacin de paquetes.
Con cifrado en enlace, cada enlace de comunicaciones vulnerable es equipado con
un dispositivo de cifrado en ambos extremos. De esta manera, todo el trfico sobre los
enlaces de comunicaciones es seguro. Aunque en una red grande se necesitara gran can
tidad de estos dispositivos, proporciona un alto grado de seguridad. Una desventaja de
este enfoque es que el mensaje debe descifrarse cada vez que introduce el conmutador
de un paquete; esto es necesario porque el conmutador debe leer la direccin (nmero
de circuito virtual) en la cabecera del paquete para decidir su ruta. Por eso, el mensaje
es vulnerable en cada conmutador. S la red de conmutacin de paquetes es pblica, el
usuario no tiene control sobre la seguridad en los nodos.
Con el cifrado extremo a extremo, el proceso se realiza en los dos sistemas finales.
El host o terminal fuente cifra los datos. stos se transmiten cifrados a travs de la red
hacia el terminal o hostde destino sin ser alterados. El destino y la fuente comparten una
clave y por tanto el primero es capaz de descifrar los datos. Este enfoque parece que ase
gurara la transmisin contra ataques en los enlaces de comunicacin o conmutadores.
Pero todava hay una debilidad.
Considrese la siguiente situacia Un host se conecta a una red X. 2 5 de conmuta
cin de paquetes, establece un circuito virtual con otro host, y est preparado para
transmitir datos a ese otro host usando cifrado extremo a extremo. Los datos se trans
miten por dicha red en forma de paquetes, que consisten en una cabecera y algunos da
tos de usuario. Qu parte de cada paquete cifrar el hosf Supongamos que cifra el pa
quete entero, incluyendo la cabecera. Esto no funcionara porque, recurdese, slo el
otro host puede realizar el descifrado. El nodo de conmutacin de paquetes recibir un
paquete cifrado y ser incapaz de leer la cabecera. Por tanto, no ser capaz de encami
narlo. El host debe cifrar solamente la porcin de datos de usuario y debe dejar la cabe
cera del paquete en claro, por lo que sta puede ser leda por la red.
As, con cifrado extremo a extremo, los datos de usuario estn seguros. No obstante,
el patrn de trfico no lo est porque las cabeceras de los paquetes se transmiten en cla
ro. Para conseguir mayor seguridad se necesitan ambos cifrados como se muestra en la
Figura 2.9.
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 49
0 = Dispositivo d e cifrado extremo a extremo
Q = Dispositivo d e cifrado d e enlace
PSN = Packet-switching node (red d e conmutacin d e paquetes)
Figura 2.9 Cifrado a travs de una red de conmutacin de paquetes
Resumiendo, cuando se emplean ambas formas, el host cifra la parte de datos de usua
rio de un paquete usando una clave de cifrado extremo a extremo. Entonces se cifra el pa
quete entero usando una clave de cifrado de enlace. A medida que el paquete recorre la
red, cada conmutador descifra el paquete usando la clave de cifrado de enlace para leer
la cabecera y entonces cifra otra vez el paquete entero para enviarlo al prximo enlace.
Ahora el paquete entero est seguro, excepto durante el tiempo en que est en la memo
ria de un conmutador de paquetes, momento en el que la cabecera est en claro.
2 .5 DISTRIBUCIN DE CLAVES
Para que el cifrado simtrico funcione, las dos partes deben tener la misma clave para
realizar un intercambio seguro, y esa clave debe protegerse del acceso de otros. Ms an,
es deseable cambiar frecuentemente la clave para limitar la cantidad de datos comprometi
dos si un atacante la descubre. Por lo tanto, la robustez de un sistema criptogrfico depen
de de la tcnica de distribucin de claves, trmino que se refiere a la manera de entregar una
dave a dos partes que desean intercambiar datos, sin permitir que otros vean dicha clave.
La distribucin de claves se puede conseguir de diferentes maneras. Para dos partes A y B,
1. Una clave podra ser elegida por A y entregada fsicamente a B.
2. Una tercera parte podra elegir la clave y entregarla fsicamente a A y a B.
3. Si con anterioridad A y B han estado usando una clave, una parte podra trans
mitir la nueva clave a la otra cifrada usando la antigua.
4 Si A y B disponen de una conexin cifrada a una tercera parte C, C podra dis
tribuir mediante los enlaces cifrados una clave a A y a B.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Las opciones 1 y 2 implican la entrega manual de una clave. Para el cifrado de en
lace es un requisito razonable, porque cada dispositivo de cifrado de enlace solamente
intercambia datos con su interlocutor en el otro lado del enlace. Sin embargo, para
cifrado extremo a extremo la entrega manual es difcil. En un sistema distribuido, cual
quier host o terminal podra necesitar demasiado tiempo en ocuparse de los intercam
bios de clave con muchos otros hosts o terminales. Por eso, cada dispositivo necesita un
nmero de claves, suministradas de forma dinmica. El problema es especialmente dif
cil en un sistema distribuido de rea ancha.
La opcin 3 es una posibilidad tanto para cifrado de enlace como para cifrado extre
mo a extremo, pero si un atacante consiguiera acceso a una clave, se revelaran todas las
subsiguientes. Aunque se realizaran cambios frecuentes de las claves de cifrado de en
lace, deberan hacerse manualmente. Para suministrar claves para el cifrado extremo a
extremo, es preferible la opcin 4.
La Figura 2.10 ilustra una implementacin que satisface la opcin 4 para cifrado ex
tremo a extremo. En la figura se ignora el cifrado de enlace. ste se puede aadir, o no,
segn se requiera. Para este esquema se identifican dos tipos de claves:
Clave d e sesin: cuando dos sistemas finales (hosts, terminales, etc.) desean co
municarse, establecen una conexin lgica (por ejemplo, circuito virtual). Duran
te el tiempo que est activa esa conexin lgica, todos los datos de usuario se ci
fran con una clave de sesin, vlida slo para esa conexin. Al finalizar la conexin
o sesin, la clave es destruida.
Clave p o m a n o ite una clave permanente es una clave usada entre entidades con
el propsito de distribuir claves de sesin.
Figura 2.10 Distribucin automtica de clave para protocolo orientado
a conexin
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 51
La configuracin consiste en los siguientes elementos:
KDC {Key Dktribution Caita): el centro de distribucin de claves determina a
qu sistemas se les permite comunicarse entre s. Cuando se obtiene permiso para
que dos sistemas establezcan una conexin, el centro de distribucin de claves pro
porciona una clave de sesin vlida solamente para esa conexin.
FEP (Front-End Procesar) : el procesador front-end realiza cifrado extremo a ex
tremo y obtiene claves de sesin en nombre de su hosto terminal.
En la Figura 2.10 se muestran los pasos necesarios para el establecimiento de una cone
xin. Cuando un host desea iniciar una conexin con otro, transmite un paquete de so
licitud de conexin (paso 1). El procesador front-end almacena el paquete y solicita al
KDC permiso para establecer la conexin (paso 2). La comunicacin entre el FEP y
el KDC se cifra usando una clave maestra compartida solamente por ambos. Si el KDC
aprueba la solicitud de conexin, entonces genera la clave de sesin y la enva a los dos
procesadores front-end implicados, usando una nica clave permanente para cada front-
end (paso 3). El procesador front-end solicitante puede ahora liberar el paquete de soli
citud de conexin, establecindose as la conexin entre los dos sistemas (paso 4). To
dos los datos de usuario intercambiados entre los dos sistemas se cifran en los
procesadores front-end respectivos usando la clave de sesin de un solo uso.
El enfoque de distribucin automatizada de claves proporciona las caractersticas de
flexibilidad y dinamismo necesarias para permitir que una serie de usuarios de terminal
accedan a una serie de hosts y para que los hosts intercambien datos entre s.
Otro enfoque para la distribucin de clave utiliza el cifrado de clave pblica, que se
trata en el Captulo 3.
2 . 6 BIBLIOGRAFA Y SITIOS WEB RECOMENDADOS
Los temas tratados en este Captulo se pueden ver con mayor detalle en [STAL03]. Para
cubrir los algoritmos criptogrficos [SCHN96] es un libro de referencia fundamental;
contiene la descripcin de prcticamente todos los algoritmos y protocolos criptogrfi
cos publicados en los ltimos 15 aos. Otro estudio valioso y detallado es [MENE97].
Un tratamiento ms profundo, con discusiones matemticas rigurosas se encuentra en
[STIN02].
MENE97 Menezes, A., Oorshcot, P.; y Vanstone, S. Handbook o f Applied
Cryptography. Boca Ratn, FL: CRC Press, 1997.
SCHN96 Schneier, B. Applied Criptography. New York: Wiley, 1996.
STAL03 Stallings, W. Cryptography and Network Security: Principies and
Practice, 3** Edition. Upper Saddle River, NJ: Prentice Hall, 2003.
STINQ2 Stinson, D. Cryptography: Theory and Practice. Boca Ratn, FL:
CRC Press, 2002.
Sitios web recomendados:
Pgina web d e AES: pgina del NIST sobre el AES. Contiene el estndar y una
serie de documentos relevantes.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Pgina deRijndad: mantenida por los desabolladores del Rijndael. Contiene do
cumentacin, enlaces a implementaciones y otros enlaces de inters.
2 . 7 PALABRAS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
PALABRAS CLAVE
AES (Advanced Encryption
Standard)
ataque de fuerza bruta
CBC (modo de encadena
miento de bloque cifra
do)
CFB (modo de retroali-
mentacin de cifrado)
texto cifrado
cifrado de enlace
PREGUNTAS DE REPASO
&1. Cules son los componentes esenciales de un cifrador simtrico?
2.2. Cules son las dos funciones bsicas usadas en los algoritmos de cifrado?
2.3. Cuntas claves se necesitan para que dos personas se comuniquen usando un
cifrador simtrico?
2 .4 Cul es la diferencia entre un cifrador de bloque y un cifrador de flujo?
Z5. Cules son los dos enfoques generales para atacar a un cifrador?
2.6, Por qu algunos modos de operacin de cifrado de bloque usan solamente
cifrado mientras que otros utilizan tanto cifrado como descifrado?
2.7. Qu es triple cifrado?
2.& Por qu la parte intermedia del 3DES es un descifrado en vez de un cifrado?
&& Cul es la diferencia entre cifrado de enlace y cifrado extremo a extremo?
2.16 Enumera las formas en que se pueden distribuir las claves secretas a dos par
ticipantes en una comunicacin.
2 1 1 . En qu se diferencian la clave de sesin y la clave maestra?
2.12. Qu es un centro de distribucin de claves?
PROBLEMAS
Z l . Demuestra que el descifrado de Feistel es la inversa del cifrado de Feistel.
2. Con el modo ECB, si hay un error en un bloque del texto cifrado transmitido,
solamente afecta al bloque de texto claro correspondiente. Sin embargo, en el
modo CBC, este error se propaga. Por ejemplo, un error al transmitir C (Fi
gura 2.7) obviamente afecta a P{ y P2.
cifrado de Feistel
cifrado extremo a extremo
cifrado simtrico
cifrador de bloque
cifrador de flujo
clave de sesin
criptoanlisis
criptografa
DES (Data Encryption
Standard)
descifrado
distribucin de clave
modo ECB (Electronic
Code Book)
subclave
texto claro
triple DES (3DES)
www.FreeLibros.org
Captulo 2 / Cifrado simtrico y confidencialidad de mensajes 53
a) Se ven afectados los bloques siguientes a P2?
b) Supongamos que hay un bit de error en la versin fuente de Pv A travs
de cuntos bloques de texto cifrado se propaga este error? Qu efecto
produce en el receptor?
2.3. Si se produce un error de un bit en la transmisin de un carcter del texto ci
frado en el modo CFB de ocho bits, hasta dnde se propaga el error?
2.4. Los esquemas de distribucin de clave que usan un centro de control de acce
so y/o centro de distribucin de clave tienen puntos centrales vulnerables a los
ataques. Discute lo que dicha centralizacin implica para la seguridad.
J5. Supongamos que alguien sugiere la siguiente manera de confirmar que dos de
vosotros estn en posesin ae la misma clave secreta. Crea una ristra aleato
ria de bits del tamao de la clave, aplcale el XOR con la clave y enva el re
sultado por el canal. Tu receptor hace XOR del bloque entrante con la clave
(que debera ser la misma que la tuya) y enva el resultado de vuelta. Observas
lo que te devuelve y si coincide con tu ristra aleatoria, entonces has verificado
que tu receptor tiene la misma clave secreta que t, aunque ninguno haya trans
mitido la clave. Hay algn defecto en este esquema?
www.FreeLibros.org
www.FreeLibros.org
C A P T U L O 3
Criptografa de clave
pblica y autentificacin
de mensajes
3.1. Enfoques para la autentificacin de mensajes
Autentificacin mediante cifrado convencional
Autentificaci n de mensajes sin cifrado
3.2. Funciones hash seguras y HMAC
Requisitos de las funciones h a s h
Funciones hash simples
La fu nci n hash segura SHA-1
Otras funciones h a s h seguras
HMAC
3.3. Principios de criptografa de clave pblica
Estructura del cifrado de clave pblica
Aplicaciones para criptosistemas de clave pblica
Requisitos para la criptografa de clave pblica
3.4. Algoritmos de criptografa de clave pblica
El a lg or itmo de cifrado de clave pblica RSA
Intercambio de clave Diffie-Hellman
Otros algoritmos criptogrficos de clave pblica
3.5. Firmas digitales
3.6. Gestin de claves
Certificados de clave pblica
Distribucin de claves secretas mediante criptografa de clave
pblica
3.7. Bibliografa y sitios web recomendados
3.8. Trminos clave, preguntas de repaso y problemas
Trminos clave
Preguntas de repaso
Problemas
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Cada egipcio reciba dos nombres, el verdadero y e l bueno, o e l grande y el pequeo,
respectivamente; y mientras el nombre bueno o pequeo se haca pblico, el verdadero
o grande parece haber quedado cuidadosamente oculto.
La rama dorada, S er J a m e s G e o r g e F ra zer
Protegerse de la influencia funesta que ejercen los extraos es, por lo tanto, un precep
to elemental de la prudencia salvaje. As, antes de permitir que los extraos entren en
un distrito, o al menos antes de que se les permita mezclarse libremente con sus habi
tantes, a menudo los nativos del lugar celebran ciertas ceremonias para desarmar a los
extraos de sus poderes mgicos, o desinfectar, de alguna forma, la atmsfera corrom
pida de la que se les cree rodeados.
Laran&dorada, S er J a m e s G e o r g e F ra zer
A
dems de la confidencialidad de los mensajes, la autentificacin es una funcin
importante de la seguridad de las redes de computadores. Este Captulo analiza
tres aspectos de la autentificacin de mensajes: en primer lugar, se centra en el
uso de los cdigos de autentificacin de mensajes y en las funciones hash para propor
cionar la autentificacin; a continuacin, se tratan los principios del cifrado de clave
pblica y dos algoritmos especficos de clave pblica que son tiles en el intercambio de
claves de cifrado convencional; luego, se observar el uso del cifrado pblico para pro
ducir firmas digitales, lo que da lugar a una forma mejorada de autentificacin de men
sajes. Por ltimo, volveremos al tema de la gestin de claves.
3.1 ENFOQUES PARA LA AUTENTIFICACIN DE MENSAJES
El cifrado protege de los ataques pasivos (escuchas). Un requisito diferente es el de pro
teger de los ataques activos (falsificacin de datos y transacciones). La proteccin con
tra tales ataques se conoce como autentificacin de mensajes.
Se dice que un mensaje, archivo, documento o cualquier otro grupo de datos es
autntico cuando es genuino y procede de la fuente original. La autentificacin de men
sajes es un procedimiento que permite la comunicacin entre las partes para verificar
que los mensajes recibidos son autnticos. Los dos aspectos importantes son verificar
que los contenidos del mensaje no han sido alterados y que la fuente es autntica. Tam
bin podramos querer verificar si un mensaje no ha sido retrasado ni repetido de forma
artificial y conocer la secuencia relativa a otros mensajes que fluyen entre dos partes.
AUTENTIFICACIN MEDIANTE CIFRADO CONVENCIONAL
Es posible llevar a cabo la autentificacin simplemente mediante el uso de cifrado con
vencional. Si slo el emisor y el receptor comparten una clave (como debera ser), slo el
autntico emisor sera capaz de cifrar con xito un mensaje para el otro participante. Ade-
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y a u t e n t i c a c i n de mensajes 57
ms, si el mensaje incluye un cdigo de deteccin de errores y un nmero de secuencia,
el receptor estar seguro de que no se han producido alteraciones y de que la secuencia es
adecuada. Si el mensaje tambin incluye un sello de tiempo, el receptor estar seguro de
que el mensaje no se ha retrasado ms de lo habitual para el trnsito en la red.
AUTENTIFICACIN DE MENSAJES SIN CIFRADO
En esta seccin se examinan diferentes enfoques para la autentificacin de mensajes que
no se basan en el cifrado. En todos estos enfoques se genera y aade una referencia de
autentificacin a cada mensaje para su transmisin. El mensaje en s mismo no est
cifrado y se puede leer en el destino independiente de la funcin de autentificacin en el
destino.
Debido a que los enfoques que se tratan en esta seccin no cifran el mensaje, no se
proporciona la confidencialidad. Si el cifrado convencional aporta autentificacin y su
uso se ha extendido con productos ya disponibles, por qu no usar tal enfoque, que pro
porciona confidencialidad y autentificacin? [DAVI89] presenta tres situaciones en las
que es preferible la autentificacin de mensajes sin confidencialidad:
1. Hay una serie de aplicaciones mediante las cuales el mismo mensaje se emite a
un nmero de destinos, como sera el caso de un mensaje que notifica a los usua
rios que la red no est disponible o una seal de alarma en un centro de control.
Es ms barato y fiable tener un solo destino responsable de supervisar la auten
ticidad. As, el mensaje debe emitirse en texto claro con una referencia asociada
de autentificacin de mensaje. El sistema responsable realiza la autentificacin
y si se produce una violacin, los otros sistemas de destino son alertados por una
alarma general.
2. Otro posible escenario es un intercambio en el que una parte tiene una gran car
ga y no puede permitirse el tiempo necesario para descifrar todos los mensajes
que entran. La autentificacin se lleva a cabo de forma selectiva, eligindose los
menajes de forma aleatoria para su comprobacin.
3. La autentificacin de un programa informtico en texto claro es un servicio
atractivo. El programa se puede ejecutar sin necesidad de descifrarlo cada vez,
hecho que implicara un mal uso de los recursos del procesador. Sin embargo, si
se aadiera al programa una referencia de autentificacin de un mensaje, se
podra comprobar cuando se necesite garanta de la integridad del programa.
De este modo, tanto la autentificacin como el cifrado intervienen en la tarea de cubrir
las necesidades de seguridad.
CDIGO DE AUTENTIFICACIN DE MENSAJES
Una tcnica de autentificacin implica el uso de una clave secreta para generar un bloque
de datos pequeo, conocido como cdigo de autentificacin del mensaje, que se aade al
mensaje. Esta tcnica implica que dos partes que se comunican, A y B, comparten una
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
clave secreta comn, Cuando A tiene un mensaje que enviar a B, calcula el cdigo
de autentifcacin como una funcin del mensaje y la clave: MAC/= HKab M)- El men
saje y el cdigo se transmiten al receptor deseado. El receptor realiza los mismos clcu
los en el mensaje recibido, usando la misma clave secreta para generar un nuevo cdigo
de autentifcacin del mensaje. El cdigo recibido se compara con el cdigo calculado
(Figura 3.1). Si slo el receptor y el emisor conocen la identidad de la clave secreta, y si
el cdigo se corresponde con el cdigo calculado, entonces:
Mensaje
Tr ansm iso r
Figura 3.1 Autentifcacin de mensaje mediante cdigo de autentifcacin
de mensajes (MAC)
L El receptor est seguro de que el mensaje no ha sido alterado. Si un oponente
altera el mensaje pero no altera el cdigo, el clculo del cdigo del receptor ser
distinto al del cdigo recibido. Como se supone que el oponente no conoce la
clave secreta, no puede alterar el cdigo para hacerlo corresponderse con las
alteraciones realizadas en el mensaje.
Z El receptor est seguro de que el mensaje es del emisor indicado. Como nadie ms
conoce la clave, nadie ms podra crear un mensaje con un cdigo adecuado.
3. Si el mensaje incluye un nmero de secuencia (como el que se usa con X.25,
HDLC y TCP), el receptor puede estar seguro de la secuencia apropiada porque
un oponente no puede alterar con xito el nmero de secuencia.
Se podra emplear una serie de algoritmos para generar el cdigo. La especificacin
NIST, FIPS PUB 113 recomienda el uso del DES. El DES se emplea para generar una
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 59
versin cifrada del mensaje, y el ltimo nmero de bits de texto cifrado se usa como el
cdigo. Un cdigo de 16 o 32 bits es bastante comn.
El proceso que se acaba de describir es similar al cifrado. Una diferencia se halla en
que el algoritmo de autentificacin no necesita ser reversible, al contrario que en el
cifrado. Por lo tanto, debido a las propiedades matemticas de la funcin de autentifica
cin, es menos vulnerable que el cifrado.
FUNCIN HASH UNIDIRECCIONAL
Una alternativa al cdigo de autentificacin de mensajes es la funcin hash unidireccio
nal. Al igual que con el cdigo de autentificacin de mensajes, una funcin hash acepta
un mensaje de tamao variable, M, como entrada y produce un resumen del mensaje de
tamao fijo W(M) como salida. A diferencia del MAC, una funcin hash no acepta una
clave secreta como entrada. Para autentificar un mensaje, el resumen se enva con el
mensaje, con lo cual se verifica la autenticidad del resumen.
La Figura 3.2 ilustra tres formas de autentificar un mensaje. El resumen del mensa
je puede ser cifrado por medio de cifrado convencional (parte a); si slo el emisor y el
receptor comparten la clave de cifrado, la autentificacin est garantizada. El mensaje
tambin puede ser cifrado por medio de cifrado de clave pblica (parte b); esto queda
explicado en la seccin 3.5. El enfoque de clave pblica tiene dos ventajas: proporciona
una firma digital adems de autentificacin del mensaje y no necesita la distribucin de
claves a las partes que se comunican entre s.
La ventaja que tienen estos dos enfoques sobre los enfoques que cifran el mensaje
completo es que implican un coste computacional menor. Sin embargo, ha habido inte
rs por el desarrollo de una tcnica que evite el cifrado. [TSUD92] muestra algunas de
las razones por las que existe este inters:
El software de cifrado es muy lento. Aunque la cantidad de datos que han de cifrar
se por cada mensaje sea pequea, podra haber un flujo fijo de mensajes entrando
y saliendo del sistema.
Los costes de hardware de cifrado son muy elevados. Aunque existen las imple-
mentaciones de chips de bajo coste del DES, si todos los nodos de una red deben
tener esta capacidad, se aaden costes.
El hardware de cifrado se optimiza con grandes cantidades de datos. Con bloques
pequeos de datos, una gran proporcin del tiempo se invierte en la inicializacin.
Los algoritmos de cifrado pueden estar patentados. Algunos, como el algoritmo de
clave pblica RSA, estn patentados y deben tener licencia, lo cual aade un coste.
Los algoritmos de cifrado pueden estar sujetos a controles de exportacin, como
ocurre con el DES.
La Figura 3.2c muestra una tcnica que emplea una funcin hash y no usa cifrado para
la autentificacin de un mensaje. Esta tcnica implica que dos partes que se comuni
can, A y B, comparten un valor secreto comn s a b - Cuando A tiene un mensaje que
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
enviar a B, calcula la funcin hash de la concatenacin del valor secreto y el mensaje:
MDm = W(Sa^\M) Luego enva a B. Como B posee Sab, puede volver a cal
cular y verificar MDmComo la clave secreta no se ha enviado, no es posi
ble que un oponente modifique un mensaje interceptado. Mientras el valor secreto per
manezca como tal, tampoco es posible que un oponente genere un nuevo mensaje.
Una variacin de la tercera tcnica, llamada HMAC, es la que se ha adoptado para la
seguridad IP (descrita en el Captulo 6), que tambin ha sido especificada paraSNMPv3
(Captulo 8).
(a) Usando cifrado convencional
^ p b l i c a
i
(b) Usando cifrado d e clave pblica
Comparacin
i
(c) Usando valor secreto
Figura 3.2 Autentificacin de mensaje por medio de una funcin ha sh
unidireccional
indica concatenacin.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 61
3 . 2 FUNCIONES HASH SEGURAS Y HMAC
La funcin hash unidireccional o funcin hash segura no slo es importante para la
autentificacin de mensajes sino tambin para las firmas digitales. En esta seccin,
empezamos analizando los requisitos de una funcin hash segura. A continuacin se tra
tan las funciones hash ms importantes, las SHA-1.
REQUISITOS DE LAS FUNCIONES HASH
La finalidad de una funcin hash es la de obtener una huella de un archivo, mensaje
u otro bloque de datos. Para que resulte til a la autentificacin de mensajes, una fun
cin hashHdebe poseer las siguientes propiedades:
1. H puede aplicarse a un bloque de datos de cualquier tamao.
2. H produce una salida de tamao fijo.
3. H(x) es relativamente fcil de computar para cualquier A'dado, haciendo que tan
to las implementaciones de hardware como de software sean prcticas.
4 Para cualquier valor h dado, es imposible desde el punto de vista computacional
encontrar x tal que H(x) = h lo cual, con frecuencia, se conoce en la literatura
como propiedad in id irecn ial
5. Para cualquier bloque dado x, es imposible desde el punto de vista computacio
nal, encontrar y * x con H(y) = H(x), lo que a veces se conoce como r e s s t e n a
d A f l a l a c d U t a
6 Es imposible desde el punto de vista computacional encontrar un par (x, y) tal
que H(x) = H(y), lo que normalmente se conoce como re ssta icia fu e rt e a la
colisin
Las tres primeras propiedades son requisitos para la aplicacin prctica de una funcin
hash a la autentificacin de mensajes. La cuarta propiedad es la propiedad unidirec
cional: dado un mensaje, es fcil generar un cdigo, pero dado un cdigo, es prctica
mente imposible generar un mensaje. Esta propiedad es importante si la tcnica de
autentificacin implica el uso de un valor secreto (Figura 3.2c). El valor secreto no se
enva; sin embargo, si la funcin hash no es unidireccional, un oponente puede descu
brir fcilmente el valor secreto: si el oponente puede observar o interceptar una trans
misin, obtiene el mensaje M y el cdigo hash MD^= H (SAbHM). Entonces el oponen
te invierte la funcin hash para obtener SAg//M = H Debido a que ahora el
oponente tiene M y Sab//M, no tiene importancia recuperar SAb-
2 Fbr desgracia, estos trminos no se usan con consistencia. Los trminos alternativos que se usan en la
literatura al respecto incluyen fundnhashunidireccional (propiedades 4 y 5), funcinhashresistentea la
colisin(propiedades 4, 5 y 6), funcinhashunidireccional dbil (propiedades 4 y 5); funcinhashunidi
reccional robusta(propiedades 4, 5 y 6). Al leer la literatura al respecto, el lector debe tener cuidado para
determinar con precisin el significado de los trminos empleados.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
La quinta propiedad garantiza que es imposible encontrar un mensaje alternativo con
el mismo valor hash que un mensaje dado. Esto evita la falsificacin cuando se usa un
cdigo hash cifrado (Figuras 3.2a y b). Si no se diera esta propiedad, un oponente con
seguira, primero, observar o interceptar un mensaje y su cdigo hash cifrado; segundo,
generar un cdigo hash no cifrado desde el mensaje; y tercero, generar un mensaje alter
nativo con el mismo cdigo hash.
Una funcin hash que cumpla las cinco primeras propiedades se denomina funcin
hash dbil. Si tambin posee la sexta propiedad, se denomina funcin hash robusta. La
sexta propiedad protege de un tipo sofisticado de ataque conocido como ataque basado
en la paradoja del cumpleaos.
Adems de proporcionar autentificacin, un resumen de un mensaje tambin pro
porciona integridad de los datos. Realiza la misma funcin que una secuencia de com
probacin: si cualquier bit del mensaje se altera accidentalmente durante la transmisin,
el resumen del mensaje dar error.
FUNCIONES HASH SIMPLES
Todas las funciones hash usan los siguientes principios generales. La entrada (mensaje,
archivo, etc.) se ve como una secuencia de bloques de n bits. La entrada se procesa blo
que a bloque de forma iterativa para producir una funcin hash de n bits.
Una de las funciones hash ms simples es el OR exclusivo bit a bit (XOR) de cada
bloque. Se puede expresar de la siguiente manera:
C = bi bf 0 ... bjn
donde
Cj = Asimo bit del cdigo hash, 1 ^ i n
m = nmero de bloques de n bits en la entrada
bj = i-simo bit en e l / s i m o bloque
= operacin XOR
La Figura 3.3 ilustra esta operacin; produce una paridad simple por cada posicin
de bit y se conoce como una comprobacin de redundancia longitudinal. Es bastante
efectivo para datos aleatorios como comprobacin de la integridad de los datos. Cada
valor hash de n bits es igualmente parecido. As, la probabilidad de que un error en los
datos resulte en un valor hash inalterable es 2~n. Con datos formateados ms predeci
blemente, la funcin es menos efectiva. Por ejemplo, en la mayora de los archivos de
texto normales, el bit ms significativo de cada octeto siempre es cero. As, si se usa un
valor hash de 128 bits en vez de una efectividad de 2~128, la funcin hash en este tipo de
datos tiene una efectividad de 2'112.
Una forma sencilla de mejorar los hechos es realizar una rotacin circular de un bit
en el valor hash despus de que se haya procesado cada bloque. El procedimiento se
puede resumir de la siguiente manera:
L Inicialmente, establecer el valor hash de n bits en cero.
2 Procesar cada bloque de datos sucesivo de n bits como sigue:
a) Rotar el valor hash actual a la izquierda en un bit.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentifcacin de mensajes 63
b) Realizar la operacin XOR del bloque con el valor hash.
El efecto que se produce es el de aleatorizar la entrada de forma ms completa y sal
var cualquier regularidad que se presente en la entrada.
Bloque 1
Bloque 2
Bloque xn
C 6dig>hadi
Figura 3.3 Funcin ha sh simple mediante XOR bit a bit
Aunque el segundo procedimiento constituye una medida aceptable para la inte
gridad de los datos, es prcticamente intil para su seguridad cuando un cdigo hash
cifrado se usa con un mensaje de texto claro, como en las Figuras 3.2a y b. Dado un
mensaje, es fcil producir un nuevo mensaje que produzca ese cdigo hash: slo hay que
preparar el mensaje alternativo deseado y luego aadir un bloque de n bits que obligue
al nuevo mensaje y al bloque a producir el cdigo hash deseado.
Aunque un XOR simple o un XOR rotado (RXOR) no es suficiente si slo se cifra
el cdigo hash, todava puede parecer que una funcin tan simple sera til cuando se
cifran tanto el mensaje como el cdigo hash Pero se debe tener cuidado. Una tcnica
propuesta originalmente por la Agencia Nacional de Estndares usaba el XOR simple
aplicado a bloques de mensajes de 64 bits y luego un cifrado de todo el mensaje que usa
ba el modo de cadena de bloques de cifrado (CBC). El esquema se puede definir como
sigue: dado un mensaje que consiste en una secuencia de bloques de 64 bits X,
Xn, definir el cdigo hash C como el XOR bloque a bloque o todos los bloques y aa
dir el cdigo hash como bloque final:
C = Xn+\ = X\ X (B ... Xn
A continuacin, cifrar el mensaje completo y el cdigo hashusando el modo CBC
para producir el mensaje cifrado Y, Y2 ..., Yn+. [JUEN85] destaca varas formas de
manipular el texto cifrado de este mensaje para que no sea detectado por el cdigo hash
Por ejemplo, por la definicin de CBC (Figura 2.7), tenemos
X{ = W D k (Y{)
X= Y.\ Dk (Y}
Xn+i = &k Wn+ 1)
Bit 1 Bit 2 . . . Bit n
bu 21 bni
b\ 2 bu bn



b\m b b/un
Cx Ci
Cn
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Pero Xff+i es el cdigo hash.
Xj\/+1= X X2 0 ... Xn
= (IV 0 Dk (Y,)) (Y{ 0 Dk (V2)) 0 ... 0 (Ym 0 Qr (K^)
Debido a que se puede realizar el XOR con los trminos de la ecuacin anterior
siguiendo cualquier orden, sucede que el cdigo hash no cambiara si los bloques de tex
to cifrado fueran permutados.
LA FUNCIN HASH SEGURA SHA-1
El algoritmo hash seguro (SHA) fue desarrollado por el Instituto Nacional de Estnda
res y Tecnologa (NIST) y publicado en 1993 como un estndar federal de procesa
miento de la informacin (FIPS PUB 180); una versin revisada, a la que normalmente
se conoce como SHA-1, se public como FIPS PUB 180-1 en 1995.
Relleno Longitud d e mensaje
*
^ ------ 512 bits------m------ 512 bits------ <------ 512 bits------ *- 5 1 2 bits
de 160 bits
Figura 3.4 Generacin del resumen de un mensaje usando SHA-1
El algoritmo toma como entrada un mensaje con una longitud mxima menor que 264
bits y produce como salida un resumen de mensaje de 160 bits. La entrada se procesa en
bloques de 512 bits. La Figura 3.4 muestra el procesamiento general de un mensaje para
producir un resumen. El procesamiento consiste en los siguientes pasos:
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 65
Paso 1: Aadir bits d e rdlcsta El mensaje se rellena para que su longitud sea con
gruente con 448 mdulo 512 (longitud = 448 mod 512). Es decir, la longitud del men
saje relleno es 64 bits menor que un mltiplo de 512 bits. El relleno se aade aunque el
mensaje ya tenga la longitud deseada. As, el nmero de bits de relleno se encuentra
entre 1 y 512. El relleno est formado por un nico bit 1 seguido del nmero necesario
de bits 0.
Paso f t Aadir longitud. Se aade un bloque de 64 bits al mensaje. Este bloque se
trata como un entero sin signo de 64 bits (el byte ms significativo, primero) y contiene
la longitud del mensaje original (antes del relleno). La inclusin de un valor de longitud
dificulta un tipo de ataque conocido como ataque de relleno [TSUD92].
El resultado de los dos primeros pasos da lugar a un mensaje que es un entero ml
tiplo de 512 bits de longitud. En la Figura 3.4, el mensaje expandido se representa como
la secuencia de bloques de 512 bits Y0 Y_i, para que la longitud total del mensaje
expandido sea L x 512 bits. De la misma forma, el resultado es un mltiplo de 16 pala
bras de 32 bits. Sea 1] las palabras del mensaje resultante, con Nun entero
mltiplo de 16. Entonces, N = L x 16.
Paso 3fc IniaHzar el buffer MD. Un buffer de 160 bits se usa para tener resultados
intermedios y finales de la funcin hash El buffer puede representarse como cinco regis
tros de 32 bits (A, B, C, D, E). Estos registros se inicializan a los siguientes enteros de
32 bits (valores hexadecimales):
A = 67452301
B = EFCDAB89
C = 98BADCFE
D = 10325476
E= C3D2E1F0
Paso 4: Procesar d mensaje en bloques de 512 bits (16 palabras). El corazn del
algoritmo es un mdulo, conocido como fimein d e compresin, que consiste en cua
tro etapas de procesamiento de 20 pasos cada una. La lgica se ilustra en la Figura 3.5.
Las cuatro etapas tienen una estructura similar, pero cada una usa una funcin lgica
primitiva diferente, a las que nos referimos como fj, f2, 3, y U-
Cada etapa toma como entrada el bloque de 512 bits que se est procesando (Y^ y
el valor ABCDE del buffer de 160 bits y actualiza los contenidos del buffer. Cada etapa
tambin hace uso de una constante adicional Kt donde 0 ^ t<, 79 indica uno de los 80
pasos a lo largo de cinco etapas. De hecho, slo se usan cuatro constantes distintas. Los
valores en decimal y hexadecimal son los siguientes:
Nmero de paso Hexadecimal toma parte entera de:
0 <,t<, 19 Kt = 5A827999 [230 x V~2]
2 0 3 9 # , = 6ED9EBA1 [230 x V~3]
40 ^ ^ 59 A^= 8F1BBCDC [230 x VI]
6 0 f 7 9 Kt = CA62C1D6 [230 x VIO]
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
La salida de la cuarta etapa (octogsimo paso) se aade a la entrada de la primera eta
pa (CVJ) para producir CVn+j. La suma se hace independientemente para cada una de
las cinco palabras en el burfer con cada una de las palabras correspondientes en CVq,
usando suma mdulo 232.
512
160
CV.
q *1
Figura 3.5 Procesamiento SHA-1 de un nico bloque de 512 bits (funcin
de compresin SHA-1)
Paso 5: Salida Despus de que todos los bloques L de 512 bits han sido procesados,
la salida del L-simo estado es el resumen del mensaje de 160 bits.
El algoritmo SHA-1 tiene la propiedad por la cual cada bit del cdigo hash es una
funcin de cada bit de la entrada. La repeticin compleja de la funcin bsica ft produ
ce resultados bien mezclados; es decir, es poco probable que dos mensajes elegidos alea
toriamente, aun mostrando regularidades similares, tengan el mismo cdigo hash A
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 67
menos que haya alguna debilidad oculta en SHA-1, que hasta ahora no ha sido publica
da, la dificultad de dar con dos mensajes con el mismo resumen es del orden de 280 ope
raciones, mientras la dificultad de encontrar un mensaje con un resumen dado es del
orden de 2160 operaciones.
OTRAS FUNCIONES HASHSEGURAS
Como ocurra en el caso de los cifrados de bloque simtricos, los diseadores de fun
ciones hash seguras se han mostrado reticentes a partir de una estructura probada.
El DES se basa en el cifrado de Feistel. Prcticamente todos los cifrados de bloque
siguientes siguen el diseo de Feistel porque puede ser adaptado para resistir amenazas
criptoanalticas de nuevo descubrimiento. Si, en vez de ello, se usara un diseo total
mente nuevo para un cifrado de bloque simtrico, habra peligro de que la estructura
misma abriera nuevas vas de ataque an no imaginadas. De la misma manera, la fun
cin hash moderna ms importante sigue la estructura bsica de la Figura 3.4, a la que
se conoce como funcin hash repetida y fue propuesta inicialmente por Merlde
[MERK79, MERK89]. La razn de esta estructura repetitiva surge de la observacin de
Merkle [MERK89] y Damgard [DAMG89] por la que s la funcin de compresin es
resistente a la colisin, tambin lo ser la funcin hash repetida resultante. Por lo tanto,
la estructura puede usarse para producir una funcin hash segura para operar sobre un
mensaje de cualquier longitud. El problema a la hora de disear una funcin hash segu
ra se reduce al de disear una funcin de compresin resistente a la colisin que opere
en entradas de tamao fijo. Se ha demostrado que este es un enfoque muy profundo y
que los nuevos diseos slo mejoran la estructura y aaden longitud al cdigo hash
En esta seccin observamos otras dos funciones hash seguras que, junto con la SHA-1,
han obtenido gran aceptacin comercial. En la Tabla 3.1 se comparan algunas de las carac
tersticas principales.
ALGORITMO DE RESUMEN DE MENSAJE MD5
El algoritmo de resumen de mensaje MD5 (RFC 1321) fue desarrollado por Ron Rivest.
Hasta los ltimos aos, cuando surgi el inters tanto por la fuerza bruta como por el
criptoanlisis, el MD5 fue el algoritmo hash seguro ms usado. Este algoritmo toma
como entrada un mensaje de longitud arbitraria y produce como salida un resumen de
mensaje de 128 bits. La entrada se procesa en bloques de 512 bits.
Como la velocidad del procesador ha aumentado, la seguridad de un cdigo hash de
128 bits se ha puesto en tela de juicio. Se puede demostrar que la dificultad de dar con
dos mensajes teniendo el mismo resumen es del orden de 24 operaciones, mientras la
dificultad de encontrar un mensaje con un resumen dado es del orden de 2128 operacio
nes. La cifra anterior es demasiado pequea para garantizar la seguridad. Adems, se ha
desarrollado una serie de ataques criptoanalticos que sugieren la vulnerabilidad del
MD5 al criptoanlisis [BERS92, BOER93, DOBB96a].
RIPEMD-160
El algoritmo de resumen de mensaje RIPEMD-160 [DOBB96b, BOSS97] se desarroll
en el proyecto RIPE (European RACE Integrity Primitives Evaluation), de manos de un
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
grupo de investigadores que lanzaron ataques con xito parcial al MD4 y MD5. Origi
nalmente, el grupo desarroll una versin de RIPEM de 128 bits. Cuando el proyecto
RIPE hubo concluido, H. Dobbertin (que no formaba parte del proyecto) encontr ata
ques en dos etapas de RIPEMD, y ms tarde de MD4 y MD5. A causa de estos ataques,
algunos miembros del consorcio RIPE decidieron actualizar RIPEMD. Las tareas de
diseo fueron llevadas a cabo por ellos junto con Dobbertin.
El RIPEMD-160 tiene una estructura muy similar a la del SHA-1. El algoritmo toma
como entrada un mensaje de longitud arbitraria y produce como salida un resumen de
mensaje de 160 bits. La entrada se procesa en bloques de 512 bits.
Tabla 3.1 Comparacin de funciones h a s h seguras
M D 5 SHA-1 R I P E M D - 1 6 0
Longitud del resumen 128 bits 160 bits 160 bits
Unidad bsica de
procesamiento 512 bits 512 bits 512 bits
Nmero de pasos 64 (4 etapas 80 (4 etapas 160 (5 pares
de 16) de 20) de etapas de 16)
Tamao mximo del mensaje
oo
264- 1 bit
oo
Funciones lgicas primitivas 4 4 5
Constantes adicionales usadas 64 4
9
HMAC
En los ltimos aos ha aumentado el inters por el desarrollo de un MAC derivado de
un cdigo hash criptogrfico, como el SHA-1. Los motivos de este inters son los
siguientes:
Las funciones hash criptogrficas, generalmente, se ejecutan ms rpidamente en
software que los algoritmos de cifrado convencional como el DES.
Se encuentra disponible una librera para las funciones hash criptogrficas.
No existen restricciones de exportacin desde los Estados Unidos u otros pases
para las funciones hash criptogrficas, mientras que los algoritmos de cifrado con
vencional estn restringidos, incluso cuando se usan para MAC.
Una funcin hash como, por ejemplo, SHA-1 no se dise para su uso como MCA y no
puede usarse directamente con esa finalidad ya que no se basa en una clave secreta. Ha
habido una serie de propuestas para la incorporacin de una clave secreta en un algorit
mo hash existente. El enfoque que ha recibido ms apoyo ha sido el HMAC [BELL96a,
BELL96b]. El HMAC se lanz como RFC 2104, se ha elegido como el MAC de imple-
mentacin obligatoria para la seguridad IP, y se emplea en otros protocolos de Internet
comoTLS (TransportLayerSecurity, que pronto reemplazar Secure SocketsLayer) y
SET (Secure Electronic Transaction).
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 69
OBJETIVOS DEL DISEO DEL HMAC
El RFC 2104 presenta los siguientes objetivos del diseo del HMAC:
Usar, sin modificaciones, las funciones hash disponibles, concretamente las fun
ciones hash que se ejecutan bien en software, y para las cuales el cdigo es gratis
y fcil de conseguir.
Permitir la sustitucin fcil de la funcin hash empotrada en caso de que se
encuentren o se necesiten funciones hash ms rpidas o seguras.
Preservar el funcionamiento original de la funcin hash sin incurrir en una degra
dacin significativa.
Usar y manejar claves de forma sencilla.
Tener un anlisis criptogrfico comprensible de la robustez del mecanismo de auten
tificacin basado en suposiciones razonables sobre la funcin hash empotrada.
Los dos primeros objetivos son importantes para la aceptabilidad del HMAC, que trata
la funcin hash como una caja negra. Esto tiene dos ventajas: en primer lugar, una
implementacin existente de una funcin hash puede usarse como un mdulo en la
implementacin del HMAC. De esta forma, el grueso del cdigo HMAC se empaqueta
y est preparado para su uso sin modificacin. Segundo, si alguna vez se deseara reem
plazar una funcin hash dada en una implementacin del HMAC, todo lo que se nece
sita es quitar el mdulo de la funcin hash existente e introducir el nuevo mdulo. Esto
podra hacerse si se quisiera una funcin hash ms rpida. An ms importante, si la
seguridad de la funcin hash empotrada se viera comprometida, la seguridad del HMAC
podra conservarse sustituyendo la funcin hash empotrada por una ms segura.
El ltimo objetivo de diseo de la lista anterior es, de hecho, la principal ventaja del
HMAC sobre otros esquemas propuestos basados en hash El HMAC puede demostrar
ser seguro si la funcin hash empotrada tiene propiedades criptogrficas fuertes. Volve
remos a ese punto ms adelante en esta seccin, pero antes examinaremos la estructura
del HMAC.
ALGORITMO HMAC
La Figura 3.6 ilustra la operacin general del HMAC. Define los siguientes trminos:
H = funcin hash empotrada (SHA-1)
M= entrada de mensaje al HMAC (incluyendo el relleno especificado en la fun
cin hash empotrada)
Y = i-simo bloque de M, 0 ^ i <, (L - 1)
L = nmero de bloques en M
b = nmero de bits en un bloque
n = longitud del cdigo hash producido por la funcin hash empotrada
K = clave secreta; si la longitud de la clave es mayor que b, la clave se introduce
en la funcin hash para producir una clave de t? bits; la longitud recomenda
da es > n
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
K+= K relleno con ceros a la izquierda de forma que el resultado sea b bits de lon
gitud
ipad = 00110110 (36 en hexadecimal) repetidos t 8 veces
opad = 01011100 (5C en hexadecimal) repetidos tS veces
K* ipad
b bits b bits
--------
K* opad
L
n b i t s
I V ----------------
^ " b i t s
H(S, || M)
b bits
pad t o b bits
So
n bits
I V ----------------
bits
I HMACk(M)
b b i t s
s, Vo
*

-
Figura 3.6 Estructura del HMAC
Entonces el HMAC puede expresarse de la siguiente manera:
HMACk (M) = H[tf+ opad) || H[K+ ipad) || M\\
Es decir,
L Aadir ceros a la izquierda de K para crear una ristra K+de b bits. Por ejemplo,
si K tiene una longitud de 160 bits y b = 512, entonces K se aadir con 44 bytes
aO (0x00).
Z Aplicar el XOR (OR exclusivo bit a bit) a K+con ipad para producir el bloque
de b bits S.
3L Aadir Ma S.
4 Aplicar H a l a ristra generada en el paso 3.
5i Aplicar el XOR a K+con opad para producir el bloque de bits S^.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 71
6 Aadir el resultado hash del paso 4 a SQ
7. Aplicar H al flujo generado en el paso 6 y extraer el resultado.
Hay que tener en cuenta que el XOR con el ipad da como resultado la inversin de la
mitad de los bits de K De forma parecida, el XOR con el opad da como resultado la
inversin de la mitad de los bits de K, pero un grupo diferente de bits. En efecto, al pasar
Sjy S0 por el algoritmo hash, hemos generado de forma pseudoaleatora dos claves de K
El HMAC debera ejecutarse en aproximadamente el mismo tiempo que la funcin
hash empotrada para mensajes largos. El HMAC aade tres ejecuciones de la funcin
hash bsica (para S SQy el bloque producido por el hash interno).
3 . 3 PRINCIPIOS DE CRIPTOGRAFA DE CLAVE PBLICA
De igual importancia que el cifrado convencional es el cifrado de clave pblica, que se
emplea en autentificacin de mensajes y en distribucin de claves. Esta seccin analiza,
en primer lugar, el concepto bsico de cifrado de clave pblica e introduce aspectos pre
liminares de la distribucin de claves. La seccin 3.4 examina los dos algoritmos de cla
ve pblica ms importantes, el RSA y el Diffie-Hellman, y la 3.5 introduce las firmas
digitales.
ESTRUCTURA DEL CIFRADO DE CLAVE PBLICA
El cifrado de clave pblica, propuesto por primera vez por Diffie y Hellman en 1976
PIFF76], es el primer avance realmente revolucionario en el cifrado en miles de aos.
El motivo es que los algoritmos de clave pblica estn basados en funciones matemti
cas y no en simples operaciones sobre los patrones de bits. Adems, la criptografa de
clave pblica es asimtrica, lo que implica el uso de dos claves separadas, a diferencia
del cifrado simtrico convencional, que emplea slo una clave. El uso de dos claves tie
ne importantes consecuencias en el terreno de la confidencialidad, la distribucin de cla
ves y la autentificacin.
Antes de continuar, deberamos mencionar algunas confusiones comunes en lo rela
tivo al cifrado de clave pblica. La primera es la creencia de que el cifrado de clave
pblica es ms seguro ante el criptoanlisis que el cifrado convencional. De hecho, la
seguridad de cualquier esquema de cifrado depende de (1) la longitud de la clave y (2)
el coste computacional necesario para romper un cifrado. No hay nada sobre el cifrado
convencional ni de clave pblica que haga a uno superior al otro en lo que respecta a la
resistencia al criptoanlisis. Otra equivocacin la hallamos en la idea de que el cifrado
de clave pblica es una tcnica con propsitos generales que ha dejado desfasado el
cifrado convencional. Por el contrario, debido al coste computacional de los esquemas
actuales de cifrado de clave pblica, no parece que el cifrado convencional vaya a aban
donarse. Por ltimo, se piensa que la distribucin de claves no es importante cuando se
usa el cifrado de clave pblica, en comparacin con los incmodos acuerdos previos que
tienen lugar con los centros de distribucin de claves para el cifrado convencional. De
hecho, se necesita alguna forma de protocolo, que a menudo implica a un agente cen-
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
tral, y los procedimientos que tienen lugar no son ms sencillos ni ms eficientes que los
que se requieren para el cifrado convencional.
Un esquema de cifrado de clave pblica tiene seis componentes (Figura 3.7a):
Texto daros consiste en el mensaje o los datos legibles que se introducen en el
algoritmo como entrada.
Algoritmo de cifrados el algoritmo de cifrado realiza diferentes transformaciones
en el texto claro.
Clave pblica y privada: es una pareja de claves que han sido seleccionadas, de
las cuales una se usa para el cifrado y la otra para el descifrado. Las transforma
ciones exactas llevadas a cabo por el algoritmo de cifrado dependen de la clave
pblica o privada que se proporciona como entrada.
Texto cifrado: es el mensaje desordenado producido como salida. Depende del
texto claro y de la clave. Para un mensaje dado, dos claves diferentes producirn
dos textos cifrados diferentes.
Algoritmo de descifrado: este algoritmo acepta el texto cifrado y la clave corres
pondiente y produce el texto claro original.
Como los nombres sugieren, la clave pblica de dicha pareja de claves se hace pblica
para que otros la usen, mientras que la clave privada slo es conocida por su propieta
rio. Un algoritmo criptogrfico de clave pblica con propsito general se basa en una
clave para el cifrado y otra diferente, aunque relacionada, para el descifrado.
Los pasos fundamentales son los siguientes:
L Cada usuario genera una pareja de claves para el cifrado y el descifrado de men
sajes.
2. Cada usuario localiza una de las dos claves en un registro pblico u otro archi
vo accesible. Esta es la clave pblica. La otra clave no se revela. Como sugiere
la Figura 3.7a, cada usuario mantiene un grupo de claves pblicas que han obte
nido de otros.
3L Si Benito quiere enviar un mensaje privado a Alicia, cifra el mensaje usando la
clave pblica de Alicia.
4 Cuando Alicia recibe el mensaje, lo descifra usando su clave privada. Ningn otro
receptor puede descifrar el mensaje porque slo Alicia conoce su clave privada.
En este enfoque, todos los participantes tienen acceso a las claves pblicas, y las claves
privadas las genera cada participante de forma local y, por lo tanto, nunca necesitan ser
distribuidas.
Mientras el usuario proteja su clave privada, la comunicacin entrante es segura. En
cualquier momento un usuario puede cambiar la clave privada y publicar la clave pbli
ca que la acompaa para sustituir la clave pblica antigua.
La clave empleada en el cifrado convencional se denomina comnmente davesecre-
ta Las dos claves empleadas para el cifrado de clave pblica se denominan davepbli
ca y dave privada Invariablemente, la clave privada se mantiene en secreto, pero en
vez de llamarse clave secreta se llama clave privada para evitar confusiones con el cifra
do convencional.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentifcacin de mensajes 73
Alicia
Clave pblica
de Alicia
Clave privada
d e Alicia
Texto cifrado
transmitido
Entrada Algoritmo
d e texto d e C|frado
cl a ro (por ejemplo RSA)
Algoritmo de
descif rado (contrario
del algoritmo
d e cifrado)
Salida
d e texto claro
(a) Cifrado
Entrada Algoritmo
d e texto d e C|frado
claro ejemplo RSA)
Algoritmo de
descif rado (contrario
d e l algoritmo
d e cifrado)
Salida
d e texto claro
(b) Autentifcacin
Figura 3.7 Criptografa de clave pblica
APLICACIONES PARA CRIPTOSISTEMAS DE CLAVE PBLICA
Antes de continuar, es necesario aclarar un aspecto de los criptosistemas de clave pbli
ca que, de otro modo, podra llevar a confusin. Los sistemas de clave pblica se carac
terizan por el uso de un tipo de algoritmo criptogrfico con dos claves, una no se revela
y la otra s. Dependiendo de la aplicacin, el emisor usa su clave privada o la clave
pblica del receptor, o las dos, para realizar algn tipo de funcin criptogrfica. En tr
minos generales, podemos clasificar el uso de criptosistemas de clave pblica en tres
categoras:
Cifrado/descifrado: el emisor cifra un mensaje con la clave pblica del receptor.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Firma digital: el emisor firma un mensaje con su clave privada. Esto se consi
gue mediante un algoritmo criptogrfico aplicado al mensaje o a un pequeo blo
que de datos que es una funcin del mensaje.
Intercambio d e claves: dos partes cooperan para intercambiar una clave de sesin.
Hay distintas posibilidades que implican la clave privada de una o de las dos par
tes.
Algunos algoritmos son adecuados para las tres aplicaciones, mientras otros slo se
pueden usar para una o dos de ellas. La Tabla 3.2 indica las aplicaciones que soportan
los algoritmos que se tratan en este Captulo, RSA y Diffie Hellman. La tabla tambin
incluye el Estndar de Firma Digital (DSS) y la criptografa de curva elptica, que se tra
ta ms tarde en este Captulo.
Tabla 3.2 Aplicaciones para criptosistemas de clave pblica
Algoritmo Cifrado/descifrado Firma digital Intercambio de clave
RSA S S S
Diffie-Hellman No No S
DSS No S No
Curva elptica S S S
REQUISITOS PARA LA CRIPTOGRAFA DE CLAVE PBLICA
El criptosistema que se muestra en la Figura 3.7 depende de un algoritmo criptogrfico
basado en dos claves relacionadas. Diffie y Hellman postularon este sistema sin demos
trar que tales algoritmos existen. Sin embargo, s especificaron las condiciones que
deben cumplir [DIFF76]:
L Desde el punto de vista computacional, para una parte B es fcil generar una
pareja de claves (clave pblica KUb, clave privada KR).
2. En trminos computacionales, para un emisor A que conozca la clave pblica y el
mensaje que ha de cifrase, M, es fcil generar el texto cifrado correspondiente:
C = EKUb(M)
3. En trminos computacionales, para un receptor B es fcil descifrar el texto cifra
do resultante usando la clave privada para recuperar el mensaje original:
M = DxxQ = DKRb [E/(ub(M) ]
4 Desde el punto de vista computacional, es imposible que un oponente, cono
ciendo la clave pblica, KUb determine la clave privada KRb
5. Desde el punto de vista computacional, es imposible que un oponente, co
nociendo la clave pblica, KUb y un texto cifrado, C, recupere el mensaje ori
ginal, M
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 75
Podemos aadir un sexto requisito que, aunque til, no es necesario para todas las
aplicaciones de clave pblica:
6 Cualquiera de las dos claves relacionadas puede usarse para el cifrado, y la otra
para el descifrado.
M = DKRb [Efcub (M) ] = DKUb [EKRh(M])
3 . 4 ALGORITMOS DE CRIPTOGRAFA DE CLAVE PBLICA
Los dos algoritmos de clave pblica ms usados son el RSA y el Diffie-Hellman, que se
analizarn en esta seccin. Tambin se introducirn brevemente otros dos algoritmos3.
EL ALGORITMO DE CIFRADO DE CLAVE PBLICA RSA
Uno de los primeros esquemas de clave pblica fue desarrollado en 1977 por Ron
Rivest, Adi Shamr y Len Adleman en el MIT y se public en 1978 [RIVE78]. El
esquema RSA ha sido desde entonces el enfoque ms aceptado e implementado para el
cifrado de clave pblica. El RSA es un cifrado de bloque en el que el texto claro y el tex
to cifrado son enteros entre 0 y n - 1 para algn n.
Para algn bloque de texto claro M y un bloque de texto cifrado C, el cifrado y el
descifrado son de la siguiente forma:
C = A f mod n
M = O1 mod n = (Af) ^mod n = A f 0 mod n
Tanto el emisor como el receptor deben conocer los valores de n y e, y slo el recep
tor conoce el valor de d Este es un algoritmo de cifrado de clave pblica con una clave
pblica de KU = {e, n} y una clave privada de KR = {d, n}. Para que este algoritmo sea
satisfactorio para el cifrado de clave pblica, se deben cumplir los siguientes requisitos:
1. Que sea posible encontrar valores de e, d, n tal que AF1 = Ai mod n para todo
M< n.
2. Que sea relativamente fcil calcular A f y O1 para todos los valores de Ai < n
& Que sea imposible determinar d dados e y n.
Los dos primeros requisitos se cumplen fcilmente. El tercero se puede cumplir para
valores grandes de e y n
La Figura 3.8 resume el algoritmo RSA. Se empieza seleccionando dos nmeros pri
mos, p y q, y calculando su producto n, que es el mdulo para cifrado y descifrado. A
continuacin, se necesita la cantidad $ (n), conocida como tuncin totient de Euler de n,
que es el nmero de enteros positivos menor que n y primo relativo de n Luego, se
selecciona un entero e que sea primo relativo de $ (n) [el mayor comn divisor de e y <|)
3 Esta seccin emplea algunos conceptee elementales de la teora de numeres. Como repaso, vase el
apndice B.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Generacin clave
Seleccionar p, q p y q primos, p * q
Calcular n = p x q
Calcular <t>(n) = (p - 1 ){q - 1)
Seleccionar entero e gcc/fqln), e) = 1 ; 1< e < <|(n)
Calcular d de mod <J)(n) = 1
Clave pblica KU = {e, n}
Clave privada KR = { d , n}
Cifrado
Texto claro: M < n
Texto cifrado: C = Me (mod n)
Descifrado
Texto cifrado: C
Texto claro: M = C d {mod n )
Figura 3.8 El algoritmo RSA
(n) es 1]. Finalmente, se calcula d como el inverso multiplicativo de e, mdulo (h). Se
puede demostrar que d y e tienen las propiedades deseadas.
Supongamos que el usuario A ha publicado su clave pblica y que el usuario B quie
re enviar el mensaje Ma A. Entonces B calcula C = M6(mod r) y transmite C. Al reci
bir el texto cifrado, el usuario A descifra calculando M = C? (mod r).
En la Figura 3.9 se muestra un ejemplo de [SING99]. Para dicho ejemplo las claves
se generaron de la siguiente manera:
L Seleccionar dos nmeros primos, p= 17 y ^ = 11.
2 Calcular n = pq = 17 x11 = 187.
3 Calcular (J) (r) = ( p - 1 ) ( q - 1)= 16 x 10= 160.
4 Seleccionar e tal que e es primo relativo de <J) (r) = 160 y menor que (r)\ ele
gimos e = 7 .
& Determinar d tal que de mod 160 = 1 y d< 160. El valor correcto es d= 23, por
que 2 3 x 7 = 161= 10 x 160+1.
Las claves resultantes son la clave pblica KU = {7, 187} y la clave privada KR {23,
187}. El ejemplo muestra el uso de estas claves para una entrada de texto claro de
M= 88. Para el cifrado necesitamos calcular C = 887 mod 187. Teniendo en cuenta las
propiedades de la aritmtica modular, podemos realizarlo como sigue:
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 7 7
887 mod 187 = [(884 mod 187) x (882 mod 187) x (881 mod 187)] mod 187
881 mod 187 = 88
882 mod 187 = 7744 mod 187 = 77
884 mod 187 = 59,969,536 mod 187 =132
887 mod 187 = (88 x 77 x 132) mod 187 = 894,432 mod 187 = 11
Para el descifrado calculamos M= l l 23 mod 187:
1123 mod 187 = [(111mod 187) x ( l l 2 mod 187) x ( l l 4 mod 187) x ( l l 8 mod 187) x
x ( l l 8 mod 187)] mod 187
111 mod 187= 11
112 mod 187= 121
114 mod 187 = 14,641 mod 187 = 55
118 mod 187 = 214,358,881 mod 187 = 33
1123 mod 187 = (11 x 121 x 55 x 33 x 33) mod 187 = 79,720,245 mod 187 = 88
Hay dos enfoques posibles para romper al algoritmo RSA. El primero es el enfoque
de fuerza bruta: intentar todas las claves privadas posibles. As, cuanto mayor sea el
nmero de bits en e y d, ms seguro ser el algoritmo. Sin embargo, debido a que los
clculos que tienen lugar tanto en la generacin de clave como en el cifrado/descifrado
son complejos, cuanto mayor sea el tamao de la clave, ms lento ir el sistema.
La mayora de las discusiones sobre el criptoanlisis del RSA se han centrado en la
tarea de factorizar n en sus dos factores primos. Un nmero n producto de dos nme
ros primos grandes es difcil de factorizar, aunque no tanto como sola ser. Una ilustra
cin llamativa de ello ocurri en 1977; los tres inventores del RSA retaron a los lecto
res de Scientic American a descodificar un cifrado que publicaron en la columna de
juegos matemticos (Mathematical Gamed) de Martin Gardner [GARD77]. Ofrecieron
una recompensa de 100 dlares por la recuperacin de una frase de texto claro, algo
que, segn predijeron, no ocurrira durante unos 40 cuatrillones de aos. En abril de
1994, un grupo que trabajaba en Internet y que usaba unos 1.600 computadores consi
gui el premio despus de slo ocho meses de trabajo [LEUT94]. En este reto se us
un tamao de clave pblica (longitud de n) de 129 dgitos decimales, alrededor de 428
bits. Este resultado no invalida el uso del RSA; simplemente significa que debe usarse
un tamao de clave mayor. Actualmente, un tamao de clave de 1024 bits (300 dgitos
decimales aproximadamente) se considera lo suficientemente robusto para casi todas
las aplicaciones.
Cifrado Descifrado
KU = 7, 187 KR = 2 3 ,1 8 7
Figura 3.9 Ejemplo de algoritmo RSA
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
INTERCAMBIO DE CLAVE DIFFIE-HELLMAN
El primer algoritmo de clave pblica apareci en el artculo de Diffie y Hellman que
defina la criptografa de clave pblica (DEFF76] y que se conoce por intercambio de cla
ve de Diffie-Hellman. Una serie de productos comerciales emplearon esta tcnica de
intercambio de claves.
La finalidad del algoritmo es hacer posible que los usuarios intercambien de forma
segura una clave secreta que luego pueda ser usada para el cifrado posterior de mensa
jes. El algoritmo est limitado al intercambio de claves.
El algoritmo de Diffie-Hellman depende para su efectividad de la dificultad de com
putar logaritmos discretos. En resumen, podemos definir el logaritmo discreto de la
siguiente forma: primero, definimos una raz primitiva de un nmero primo p cuyas
potencias generan todos los enteros desde 1 a p - 1. Es decir, si a es una raz primitiva
del nmero primo p, entonces los nmeros
a mod /?, a 2 mod p ..., a^ 1 mod p
son distintos y consisten en los enteros desde 1 hasta p - 1 en alguna de sus permuta
ciones.
Para cualquier entero b menor que p y una raz primitiva a del nmero primo p, se
puede encontrar un nico exponente i tal que
b = a1 mod p donde 0 <><>(p- 1)
El exponente ; se conoce como el logaritmo discreto o ndice de b para la base a, mod
p. Este valor se representa como inda/7(>).
Con toda esta informacin se puede definir el intercambio de clave de Diffie-Hell
man, que se resume en la Figura 3.10. Para este esquema, hay dos nmeros conocidos
pblicamente: un nmero primo q y un entero a que es una raz primitiva de q. Supon
gamos que los usuarios A y B quieren intercambiar una clave. El usuario A selecciona
un entero aleatorio Xa < q y computa Ya = o.Xa mod q. De igual forma, el usuario B
selecciona independientemente un entero aleatorio < q y calcula Yg = aXB. Cada par
te mantiene el valor X en privado y hace pblico el valor Y a la otra parte. El usuario A
computa la clave como K = ( Y)Xa mod q y el usuario B computa la clave como
K = ( y ^ ^ m o d q. Estos dos clculos producen resultados idnticos:
K= (Yb)xmod q
= ( a XB mod q)XA mod q
= ( a x b ) x a mod q
= o.XbXa mod q
= (o.Xa)xb mod q
= ( a ^ mod q)xB mod q
= ( Ya ) x b mod q
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 79
Elementos pblicos globales
<7
nmero primo
a a < q y a una raz prima de q
Generacin de la clave del usuario A
Seleccionar XA privada XA< q
Calcular YA pblica YA = aXA mod q
Generacin de la clave del usuario B
Seleccionar XB privada XB< q
Calcular YB pblica YB = ax& mod q
Generacin de la clave secreta por el usuario A
K = (Yb)Xa mod q
Generacin de la clave secreta por el usuario B
K = {Ya)xb mod q
Figura 3.10 Algoritmo de intercambio de claves de Diffie-Hellman
As, las dos partes han Intercambiado una clave secreta. Adems, como XA y XB son
privadas, un oponente slo tiene los siguientes componentes para trabajar: q a, YA y YB
De esta forma, el oponente se ve obligado a tomar un logaritmo discreto para determinar
la clave. Por ejemplo, atacando la clave secreta del usuario B, el oponente debe computar
Aa - i n d ^
Entonces el oponente puede calcular la clave K de la misma manera que lo hace el
usuario.
La seguridad del intercambio de claves de Diffie-Hellman se basa en el hecho de que,
aunque es relativamente fcil calcular exponenciales mdulo un nmero primo, es muy
difcil calcular logaritmos discretos. Para nmeros primos grandes, la ltima tarea se
considera imposible.
Por ejemplo, seleccionar el nmero primo q= 71 y una raz primitiva de 71, en este
caso, a = 7. A y B seleccionan las claves privadas XA = 5 y XB = 12, respectivamente.
Cada uno computa su clave pblica:
Ya = 75 mod 71 = 51
Yb = 712 mod 71 = 4
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Despus de intercambiar sus claves pblicas, cada uno computa la clave secreta
comn:
K= ( Yb)xa mod 71 = 45 mod 71 = 30
K= ( Ya)Xb mod 71 = 5112 mod 71 = 30
Desde {51, 4}, un atacante no puede computar 30 fcilmente.
La Figura 3.11 muestra un protocolo simple que hace uso del clculo Diffie-Hell-
man. Supongamos que el usuario A quiere establecer una conexin con el usuario B y
usa una clave secreta para cifrar mensajes en esa conexin. El usuario A puede generar
una clave privada exclusiva XA, calcular YAt y enviarlo al usuario B. El usuario B res
ponde generando un valor privado Xg, calculando Yg y enviando K^al usuario A. Ahora
los dos usuarios pueden calcular la clave. Los valores pblicos necesarios q y a tendran
que ser conocidos con antelacin. Por otra parte, el usuario A podra tomar valores para
q y a e incluirlos en el primer mensaje.
Otro ejemplo del uso del algoritmo Diffie-Hellman es el siguiente: supongamos que
en un grupo de usuarios (por ejemplo, todos los usuarios de una red LAN) cada uno
genera un valor privado de larga duracin XA y calcula un valor pblico YA. Estos valo
res pblicos, junto con los valores pblicos globales para q y a, se almacenan en algn
directorio central. En cualquier momento, el usuario B puede acceder al valor pblico
del usuario A, calcular una clave secreta y usarla para enviar un mensaje cifrado al usua
rio A Si el directorio central es fiable, esta forma de comunicacin proporciona confi
dencialidad y un cierto grado de autentificacin. Como slo A y B pueden determinar la
clave, ningn otro usuario puede leer el mensaje (confidencialidad). El receptor A sabe
que slo el usuario B podra haber creado un mensaje usando esta clave (autentifica
cin). Sin embargo, la tcnica no protege contra ataques de repeticin.
U s u a r i o A U s u a r i o B
G e n e r a r n m e r o
a l e a t o r i o X A < q ;
C a lc u la r
YA = a XA m o d q
G e n e r a r n m e r o
a l e a t o r i o X B< q ;
C a l c u l a r
Yg = a Xe m o d q;
Vg
C a l c u l a r
C a lc u la r
K = ( Ya ) Xb m o d q
K = { Y b )x * m o d q
Figura 3.11 Intercambio de claves de Diffie-Hellman
OTROS ALGORITMOS CRIPTOGRFICOS DE CLAVE PBLICA
Otros dos algoritmos de clave pblica han hallado aceptacin comercial: el DDS y la
criptografa de curva elptica.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 81
ESTNDAR DE FIRMA DIGITAL
El NIST (NationalInsttute ofStandards and Technology ha publicado el Federal Infor
mation Processing Standard, FIPS PUB 186, conocido como DSS (Digital Signature
Standard). El DSS hace uso del SHA-1 y presenta una nueva tcnica de firma digital, el
Algoritmo de Firma Digital o DSA (Digital Signature Algorithni). El DSS fue propues
to originalmente en 1991 y revisado en 1993 como consecuencia de la respuesta del
pblico en lo relativo a la seguridad del esquema. Hubo otra revisin menor en 1996. El
DSS usa un algoritmo diseado para proporcionar slo la funcin de firma digital. A
diferencia del RSA, no puede usarse para el cifrado o el intercambio de claves.
CRIPTOGRAFA DE CURVA ELPTICA
La mayora de los productos y estndares que usan criptografa de clave pblica para el
cifrado y las firmas digitales usan RSA. La longitud de bit para el uso seguro del RSA
ha aumentado en los ltimos aos, y esto ha supuesto una mayor carga de procesamien
to en las aplicaciones que usan el RSA. Esta carga tiene ramificaciones, especialmente
para sitios de comercio electrnico que realizan grandes cantidades de transacciones
seguras. Recientemente, un sistema competidor ha empezado a retar al RSA: la cripto
grafa de curva elptica (ECC), que ya est haciendo esfuerzos de estandarizacin,
incluido el Estndar IEEE P1363 para la Criptografa de Clave Pblica.
La atraccin principal de la ECC en relacin al RSA es que parece ofrecer igual
seguridad por un tamao de bit mucho menor, reduciendo, con ello, los costes de pro
cesamiento. Por otra parte, aunque la teora de la ECC ha estado presente durante algn
tiempo, los productos empezaron a aparecer muy recientemente y ha habido un inters
prolongado por probar sus debilidades. As, el nivel de confianza en la ECC todava no
alcanza al del RSA.
La ECC es ms difcil de explicar que el RSA o el Diffie-Hellman, y una descripcin
matemtica exhaustiva sobrepasa el mbito de este libro. La tcnica se basa en el uso de
un constructor matemtico conocido como la curva elptica.
3 . 5 FIRMAS DIGITALES
El cifrado de clave pblica se puede usar de otra forma, como ilustra la Figura 3.7b.
Supongamos que Benito quiere enviar un mensaje a Alicia y, aunque no es necesario que
el mensaje se mantenga en secreto, quiere que Alicia se asegure de que el mensaje, efec
tivamente, proviene de l. En este caso Benito usa su propia clave privada para cifrar el
mensaje. Cuando Alicia recibe el texto cifrado, se encuentra con que puede descifrarlo
con la clave pblica de Benito, demostrando as, que el mensaje ha debido ser cifrado
por l. Nadie ms tiene la clave privada de Benito y, por lo tanto, nadie ms ha podido
crear un texto cifrado que pueda ser descifrado con su clave pblica. Por consiguiente,
el mensaje cifrado sirve como firma d ^ t a l Adems, es imposible alterar el mensaje
sin acceso a la clave privada de Benito, as que el mensaje queda autentificado tanto en
lo que respecta a la fuente como a la integridad de los datos.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
En el esquema anterior, se ha cifrado todo el mensaje, que, aunque valide el autor y
los contenidos, necesita una gran cantidad de almacenamiento. Tambin se debera
almacenar una copia en texto cifrado para que el origen y el contenido se puedan verifi
car en caso de desacuerdo. Una forma ms efectiva de lograr los mismos resultados es
cifrar un pequeo bloque de bits que sea una funcin de un documento. Este bloque, lla
mado autentificador, debe tener la propiedad por la cual es imposible cambiar el docu
mento sin cambiar el autentificador. Si el autentificador se cifra con la clave privada del
emisor, sirve como firma que verifica el origen, el contenido y la secuencia. Un cdigo
hash seguro como el SHA-1 puede realizar esta funcin, como muestra la Figura 3.2b.
Es importante resaltar que el proceso de cifrado que se acaba de describir no pro
porciona confidencialidad. Es decir, el mensaje que se est enviando es seguro contra
alteraciones pero no contra escuchas, lo que es obvio en el caso de una firma basada en
una parte del mensaje, porque el resto del mensaje se transmite en claro. Incluso en el
caso del cifrado completo, no hay proteccin de confidencialidad ya que cualquier
observador puede descifrar el mensaje usando la clave pblica del emisor.
3 .6 GESTIN DE CLAVES
Una de las funciones principales del cifrado de clave pblica es la de tratar el problema
de la distribucin de claves. Hay dos aspectos fundamentales sobre el uso del cifrado de
clave pblica en este sentido:
La distribucin de claves pblicas.
El uso de cifrado de clave pblica para distribuir claves secretas.
Vamos a examinar cada una de estas reas.
CERTIFICADOS DE CLAVE PBLICA
A la vista de todo esto, la base del cifrado de clave pblica se encuentra en el hecho de
que la clave pblica es pblica. As, si hay un algoritmo de clave pblica aceptado, como
el RSA, cualquier participante puede enviar su clave pblica a cualquier otro o difundir
la clave a la comunidad en general. Aunque este enfoque es conveniente, presenta una
debilidad fundamental: cualquiera puede falsificar ese dato pblico. Es decir, un usua
rio podra hacerse pasar por el usuario A y enviar una clave pblica a otro participante
o difundirla. Hasta el momento en que A descubre la falsificacin y alerta a los otros par
ticipantes, el falsificador puede leer todos los mensajes cifrados enviados a A y puede
usar las claves falsificadas para la autentificacin.
La solucin a este problema es el certificado de clave pblica. Bsicamente, un cer
tificado consiste en una clave pblica y un identificador o nombre de usuario del dueo
de la clave, con todo el bloque firmado por una tercera parte confiable. Comnmente, la
tercera parte es una autoridad de certificacin (CA, Certifcate A uthority) en la que con
fa la comunidad de usuarios, que podra ser una agencia gubernamental o una institu
cin financiera. Un usuario puede presentar su clave pblica a la autoridad de forma
segura, obtener un certificado y luego publicarlo. Cualquiera que necesite la clave pbli-
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 83
ca de este usuario puede obtener el certificado y verificar que es vlida por medio de la
firma fiable adjunta. La Figura 3.12 ilustra este proceso.
Certificado no firmado:
contiene e l identificador d e usuario,
la clave pbl lea del usuario Genera e| cd|go
hash del certificado
no firmado
Ll / / / / / / / .
n
V J
* ' / / / / / A
Cifra e l cdigo hash
con la clave privada
d e CA para formar
la firma
Certificado firmado:
e l receptor puede verificar
la firma usando la clave
pblica d e CA
Figura 3.12 Uso del certificado de clave pblica
El esquema que se ha aceptado mundialmente para el formateado de los certificados
de clave pblica es el estndar X.509, cuyos certificados se emplean en la mayora de
las aplicaciones de seguridad de redes, incluyendo la seguridad IP, las capas de conexin
segura (SSL), las transacciones electrnicas seguras (SET) y S/MIME, que se tratarn
en la Segunda Parte del libro. El X.509 se examina detalladamente en el Captulo 4.
DISTRIBUCIN DE CLAVES SECRETAS MEDIANTE CRIPTOGRAFA
DE CLAVE PBLICA
Con el cifrado convencional, un requisito fundamental para que las dos partes se comu
niquen de forma segura es que compartan la clave secreta. Supongamos que Benito quie
re crear una aplicacin de mensajes que le permita intercambiar correo electrnico de
forma segura con alguien que tiene acceso a Internet o a otra red que ambos comparten.
Supongamos, adems, que quiere hacerlo usando cifrado convencional. Con el cifrado
convencional, Benito y su interlocutor, Alicia, deben acordar una forma de compartir
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
una clave secreta que nadie ms conozca. Cmo van a hacerlo? Si Alicia se encuentra
en la habitacin contigua a la de Benito, ste podra generar una clave y anotarla en un
papel o guardarla en un disquete y entregarla a Alicia. Pero si Alicia est en el otro extre
mo del continente o del mundo, qu puede hacer Benito? Podra cifrar la clave usando
cifrado convencional y enviarla por correo electrnico a Alicia, pero esto significa que
ambos deben compartir una clave secreta para cifrar esta nueva clave secreta Adems,
Benito y todo aquel que use este nuevo paquete de correo electrnico se enfrenta al mis
mo problema con cada posible interlocutor: cada pareja de interlocutores debe compar
tir una clave secreta nica.
Un enfoque consiste en el uso del intercambio de clave de Diffie-Hellman, que, de
hecho, est muy extendido. Sin embargo, tiene la desventaja de que en su forma ms
simple el algoritmo de Diffie-Hellman no proporciona la autentificacin de las dos par
tes que se comunican.
Una alternativa vlida es el uso de los certificados de clave pblica. Cuando Benito
quiera comunicarse con Alicia, puede hacer lo siguiente:
L Preparar un mensaje.
Z Cifrar el mensaje usando cifrado convencional con una clave de sesin conven
cional.
3 Cifrar la clave de sesin utilizando el cifrado de clave pblica con la clave pbli
ca de Alicia.
4 Aadir la clave de sesin cifrada al mensaje y enviarlo a Alicia.
Slo Alicia puede descifrar la clave de sesin y, por lo tanto, recuperar el mensaje
original. Si Benito obtuvo la clave pblica de Alicia a travs del certificado de clave
pblica de Alicia, est seguro de que se trata de una clave vlida.
3 . 7 BIBLIOGRAFA Y SITIOS WEB RECOMENDADOS
En [STIN02] y [MENE97] se tratan en profundidad las funciones hash y los cdigos de
autentificacin de mensajes.
Los tratamientos recomendados de cifrado proporcionados en el Captulo 2 cubren
el cifrado de clave pblica y el cifrado convencional. [DIFF88] describe detalladamen
te los intentos realizados para crear algoritmos seguros de doble clave y la evolucin gra
dual de una serie de protocolos basados en ellos. Un buen tratamiento de la criptografa
de clave pblica se encuentra en [SAL096]. [CORMOl] proporciona un resumen con
ciso pero completo y claro de todos los algoritmos relevantes para la verificacin, la
computacin y el criptoanlisis del RSA.
CORMOl Cormen, T; Leserson, C.; Rivest, R.; y Stein, C. Introduction toAlgo-
rithms. Cambridge, MA: MIT Press, 2001.
DIFF88 Diffie, W. The First Ten Years of Public-Key Cryptography. Procee-
dings ofthe IEEE, mayo 1998. Reimpreso en [SIMM92].
MENE97 Menezes, A.; Oorschcot, P.; y Vanstone, S. Handbook o f Applied
Cryptography. Boca Ratn, FL: CRC Press, 1997.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 85
SAL096 Salomaa, A. Publc-Key Cryptography. New York: Springer-Verlag,
1996.
SIMM9B Simmons, G., ed. Contemporary Cryptology: The Science o f Informa
tion Integrity. Pscataway, NJ: IEEE Press, 1992.
STIN02 Stinson, D. Cryptography: Theory andPractice. Boca Ratn, FL: CRC
Press, 2002.
Sitios web recomendados:
RSA Laboratories: recopilacin exhaustiva de material tcnico sobre el RSA y
otros temas sobre criptografa.
NIST SecureHashmg Page: SHA FIPS y documentos relacionados.
3 . 8 TRMINOS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
TERMINOS CLAVE
Autentiflcacin de mensaje
Certificado de clave pblica
Cifrado de clave pblica
Clave privada
Clave pblica
Clave secreta
Cdigo de autentificacin
de mensaje (MAC)
Criptografa de curva elp
tica (ECC)
PREGUNTAS DE REPASO
Estndar de firma digital
(DSS)
Firma digital
Funcin hash segura
Funcin hash unidireccio
nal
HMAC
Intercambio de clave
Intercambio de clave de
Diffie-Hellman
MD5
Resumen de mensaje
RIPEMD-160
RSA
SHA-1
3 L Menciona tres enfoques para la autentificacin de mensajes.
3 3 Qu es un cdigo de autentificacin de mensajes?
3 3 Describe brevemente los tres esquemas que aparecen en la Figura 3.2.
3 4 Qu propiedades debe cumplir una funcin hash para que sea til para la
autentificacin de mensajes?
3 3 En el contexto de las funciones hash, qu es una funcin de compresin?
3 3 Cules son los componentes principales de un criptosistema de clave pblica?
3 7 . Menciona y define brevemente tres usos de un criptosistema de clave pblica.
3 3 Cul es la diferencia entre una clave privada y una clave secreta?
3 3 Qu es una firma digital?
3 1 3 Qu es un certificado de clave pblica?
3 1 L Cmo se puede usar el cifrado de clave pblica para distribuir una clave
secreta?
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
PROBLEMAS
3 L Uno de los MAC ms usados, conocido como Algoritmo de Autentificacin de
Datos, se basa en el DES. El algoritmo es una publicacin de FIPS (FIPS PUB
113) y un estndar ANSI (X9.17). El algoritmo usa el modo de operacin de
cadena de bloque de cifrado (CBC) del DES con un vector de inicializacin
con valor cero (Figura 2.7). Los datos (mensaje, registro, fichero o programa)
que han de autentificarse estn agrupados en bloques contiguos de 64 bits: P\,
P2,..., Pm En caso de ser necesario, el ltimo bloque se rellena a la derecha con
ceros para formar un bloque completo de 64 bits. El MAC est formado por el
bloque entero de texto cifrado Cn o por los A/bits ms a la izquierda del blo
que, con 16 < M <. 64. Demuestra que se puede obtener el mismo resultado
usando el modo de retroalimentacin de cifrado.
3 3 Considrese una funcin hash de 32 bits definida como la concatenacin de
dos funciones de 16 bits: XOR y RXOR, definidas en la Seccin 3.1 como
dos funciones hash simples.
a) Detectar esta suma de prueba todos los errores causados por un nmero
impar de bits de error? Explcalo.
b) Detectar esta suma de prueba todos los errores causados por un nmero
par de bits de error? Si la respuesta es negativa, caracteriza los patrones de
error que harn que falle la suma de prueba.
c) Comenta la efectividad de esta funcin para su uso como una funcin hash
para la autentificacin.
3 3 Es posible emplear una funcin hash para construir un cifrado de bloque con
una estructura similar al DES. Si una funcin hash es unidireccional y un
cifrado de bloque debe ser reversible (para descifrar), cmo es esto posible?
3 4 Antes del descubrimiento de los esquemas especficos de clave pblica, como
el RSA, se desarroll una prueba de existencia cuyo propsito era el de demos
trar que, en teora, el cifrado de clave pblica es posible. Considera las funcio
nes fj f e = z\ f2 f e y2 ) = z f3 f e y3 ) = z 3 donde todos los valores son ente
ros con \ <>xh yh z <, N. La funcin fj puede representarse por medio de un
vector MI de longitud N}en el que la -sima entrada es el valor de f t (k). De
igual forma, f2 y 3 pueden estar representados por matrices de N x N, M2 y M3.
El objetivo es representar el proceso de cifrado/descifrado mediante consultas
en tablas con valores muy altos de N. Dichas tablas seran innecesariamente
enormes pero, en principio, podran construirse. El esquema es como sigue:
construye MI con una permutacin aleatoria de todos los enteros entre \ y N,
es decir, cada entero aparece exactamente una vez en M1. Construye M2 de for
ma que cada fila contenga una permutacin aleatoria de los TVprimeros enteros.
Por ltimo, rellena M3 para que se den las siguientes condiciones:
h f t f i ($./?).$ = p para todo k, p con 1 <>k, p<>N
Es decir:
L MI toma una entrada k y produce una salida x.
2. M2 toma las entradas x y p dando la salida z
3 M3 toma las entradas z y k y produce p.
www.FreeLibros.org
Captulo 3 / Criptografa de clave pblica y autentificacin de mensajes 87
Las tres tablas, una vez construidas, se hacen pblicas.
a) Debera quedar claro que es posible construir M3 para cumplir la condi
cin anterior. A modo de ejemplo, rellena M3 para este caso sencillo:
MI = M2 =
5 2 3 4 1
4 2 5 1 3
1 3 2 4 5
3 1 4 2 5
2 5 3 4 1
M3 =
Convencin: el Asimo elemento de MI corresponde a k= i. La Asima
fila de M2 corresponde a x = i: l a / s i m a columna de M2 corresponde a
p=j . La sima fila de M3 corresponde a z= \ l a / s i m a columna de M3
corresponde a k=j.
b) Describe el uso de este grupo de tablas para realizar cifrado y descifrado
entre dos usuarios.
c) Razona que este es un esquema seguro.
3.5. Lleva a cabo el cifrado y el descifrado usando el algoritmo RSA, como en la
Figura 3.9, para lo siguiente:
a) p= 3; q= 11, e=7\ M= 5
b) p = q= 11, e=3; M= 9
c) p = 7; q = l l , e= 17; M= 8
d) p= 11; 7 = 13, e = 11; M= 7
e) p = 17; q = 31, e = 7; A/= 2. Consejo: El descifrado no es tan difcil
como piensas; usa tu astucia.
&& En un sistema de clave pblica que usa RSA, interceptas el texto cifrado
C= 10, enviado a un usuario cuya clave pblica es e = 5, n =35. Cul es el
texto claro M?
3.7. En un sistema RSA, la clave pblica de un usuario dado es e = 31, n = 3599.
Cul es la clave privada de este usuario?
3.8. Supongamos que tenemos un grupo de bloques codificados con el algoritmo
RSA y que no tenemos la clave privada. Supongamos que n = pq, e es la cla
ve pblica. Nos ayuda de alguna forma saber que uno de los bloques del tex
to claro tiene un factor comn con ni
3L9L Demuestra cmo se puede representar RSA por medio de las matrices MI,
M2 y M3 del Problema 3.4.
3l10l Considera el siguiente esquema:
L Tomar un nmero impar, E
& Tomar dos nmeros primos, P y Q, donde la divisin de (P - \ )( Q- 1) - 1
entre Ees un nmero par.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
3L Multiplicar P y Q para obtener N.
( P - 1 ) ( Q - 1 ) ( E - 1) +1
4 Calcular D =
E
Es este esquema equivalente a RSA? Justifica tu respuesta
3L11. Considera el empleo del RSA con una clave conocida para construir una
funcin hash unidireccional. Luego, procesa un mensaje formado por
una secuencia de bloques como sigue: cifrar el primer bloque, aplicar el XOR
al resultado con el segundo bloque y cifrar de nuevo, y as sucesivamente.
Demuestra que este esquema no es seguro resolviendo el siguiente problema.
Dado un mensaje de dos bloques Bl, B2 y su hash
RSAH(B1,B2) = RSA (RSA (Bl) B2)
Dado un bloque aleatorio Cl, elige C2 tal que RSAH(C 1, C2) = RSAH(B1, B2).
3L12. Considera un esquema de Diffie-Hellman con un factor primo comn q= 11
y una raz primitiva a = 2.
a) Si el usuario A tiene la clave pblica YA = 9, cul es la clave privada XA
de A?
b) S el usuario B tiene la clave pblica Yg = 3, cul es la clave secreta com
partida A?
www.FreeLibros.org
P A R T E II
APLICACIONES DE
SEGURIDAD EN REDES
CONTENIDO DE LA SEGUNDA PARTE
E
n la Segunda Parte del libro se estudian importantes herramientas y aplicaciones
de seguridad que pueden usarse en una sola red, en intranets o en Internet.
G U A PARA LA SEGUNDA PARTE
CAPTULO 4. APLICACIONES DE AUTENTIFICACIN
En el Captulo 4 se estudian dos de las especificaciones de autentificacin ms impor
tantes que se usan en la actualidad. Kerberos es un protocolo de autentificacin basado
en cifrado simtrico que ha recibido gran aceptacin general y se usa en una variedad de
sistemas. El estndar X.509 especifica un algoritmo de autentificacin y define un certi
ficado. Este ltimo permite que los usuarios obtengan certificados de clave pblica para
que una comunidad de usuarios pueda confiar en la validez de las claves pblicas. Esta
herramienta se emplea como bloque de construccin en una serie de aplicaciones.
CAPTULO 5. SEGURIDAD EN EL CORREO ELECTRNICO
La aplicacin distribuida que ms se usa es el correo electrnico, y existe un aumento
de inters en proporcionar servicios de autentificacin y confidencialidad como parte de
la herramienta de correo electrnico. En el Captulo 5 se tratan los dos enfoques que po
dran dominar la seguridad del correo electrnico en un futuro cercano. PGP (Pretty
Good Privacy) es un esquema de uso extendido que no depende de ninguna organiza
cin o autoridad, por lo que es tan adecuado para el uso individual y personal como para
la incorporacin en configuraciones de red gestionadas por organizaciones. S/MIME
www.FreeLibros.org
(Secure/Multipurpose Internet Mal Extensin) se desarroll concretamente para ser un
estndar de Internet.
CAPTULO 6. SEGURIDAD IP
El IP (Internet Protocol) es el elemento central de Internet y las intranets privadas. La
seguridad en el nivel IP, por lo tanto, es importante para el diseo de cualquier esquema
de seguridad basada en Internet. El Captulo 6 presenta el esquema de seguridad IP que
se ha desarrollado para operar con el actual IP y con el IP de nueva generacin que est
surgiendo y que se conoce como IPv6.
CAPTULO 7. SEGURIDAD DE LA WEB
El aumento drstico del uso de la World Wide Web en el comercio electrnico y para di
fundir informacin ha generado la necesidad de la seguridad en la Web. El Captulo 7
proporciona un estudio de este nuevo campo de la seguridad y se centra en dos estnda
res clave: el SSL (Secure Sockets Layei) y el SET (Secure Electronic Transacton).
CAPTULO 8. SEGURIDAD EN LA GESTIN DE REDES
El uso en aumento de los sistemas de gestin de redes para controlar redes que propor
cionan servicios de diversa ndole a un gran nmero de usuarios ha provocado, a su vez,
un aumento en la demanda de capacidades de seguridad. El Captulo 8 se centra en el
esquema de gestin de redes ms usado, el SNMP (Simple Network Management Pro
tocol). Mientras la versin 1 del SNMP slo tiene una herramienta de autentifcacin ru
dimentaria basada en contraseas, el SNMPv2 aporta funciones adicionales, y el
SNMPv3 proporciona una verdadera herramienta de seguridad para la confidencialidad
y la autentifcacin, que se puede usar junto con SNMP v i o SNMPv2.
www.FreeLibros.org
C A P T U L O 4
Aplicaciones
de autentificacin
4.1. Kerberos.
Motivacin
Versin 4 de Kerberos
Versin 5 de Kerberos
4.2. S e r v i c io d e a u t e n t i f i c a c i n d e X.509.
Certificados
Procedimientos de autentificacin
La versin 3 de X.509
4.3. Bibliografa y sitios web recomendados.
4.4. Trminos clave, preguntas de repaso y problemas.
Trminos clave
Preguntas de repaso
Problemas
Apndice 4A. Tcnicas de cifrado Kerberos
Transformacin de contrasea a clave
Propagacin del modo CBC I C i p h e r B l o c k C h a i n i n g )
www.FreeLibros.org
92 Fundamentos de seguridad en redes. Aplicaciones y estndares
No podemos aliamos con los prncipes vecinos hasta que estemos familiarizados con
sus diseos.
H arte dla g im a , S u n T z u
E
ste Captulo examina algunas de las funciones de autentificacin que se han
desarrollado para la autentificacin y las firmas digitales en el nivel de aplica
cin.
En primer lugar, estudiaremos uno de los servicios ms antiguos y de uso ms ex
tendido: Kerberos. Luego, examinaremos el servicio de autentificacin de directorio
del estndar X.509. Dicho estndar es importante como parte del servicio de directo
rio que soporta, pero tambin constituye un bloque bsico en la construccin de otros
estndares, como el S/MIME, que se trata en el Captulo 5.
4 .1 KERBEROS
Kerberos1es un servicio de autentificacin que se desarroll como parte del Proyecto
Athena en el MIT. Fue diseado para abordar el problema que plantea el hecho de que
en un entorno abierto distribuido, los usuarios de las estaciones de trabajo quieran acce
der a servicios de servidores distribuidos por toda la red. Sera conveniente que los
servidores pudiesen restringir el acceso a los usuarios autorizados y autentificar las so
licitudes de servicios. En este entorno no se puede confiar en que una estacin de traba
jo identifique a sus usuarios correctamente ante los servicios de red. Concretamente, se
pueden dar las tres amenazas que se exponen a continuacin:
Un usuario podra obtener acceso a una estacin de trabajo concreta y fingir ser otro
usuario que opera desde esa estacin de trabajo.
Un usuario podra alterar la direccin de red de una estacin de trabajo para que las
solicitudes enviadas desde dicha estacin parezcan proceder de la estacin que ha sido
suplantada.
Un usuario podra realizar escuchas en intercambios y usar un ataque de repeticin
para conseguir entrar en un servidor o interrumpir las operaciones.
En cualquiera de estos casos, un usuario no autorizado podra obtener acceso a servicios
y datos para los que no tenga autorizacin. En vez de crear protocolos elaborados de au
tentificacin en cada servidor, Kerberos proporciona un servidor centralizado de auten
tificacin cuya funcin es la de autentificar los usuarios al servidor y los servidores a los
usuarios. A diferencia de la mayora de los esquemas de autentificacin descritos en este
1 En la mitologa griega, Kerberos era un perro con varias cabezas, normalmente tres, y probablemen
te con cola de serpiente, que custodiaba la entrada del Hades {Dtctonary o f Subjects and Symbois in Art,
de James Hall, Harper & Row, 1979). Al igual que e l Kerberos griego tena tres cabezas, la idea inicial fue
que e l moderno tuviese tambin tres componentes para guardar la entrada a la red: (1) autentiflcacin, (2) re
gistro de operaciones y uso de recusrsos y (3) auditora. Las dos ltimas cabezas nunca llegaron a imple-
mentarse.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 93
libro, Kerberos se basa exclusivamente en cifrado simtrico, dejando de lado el cifrado
de clave pblica.
Las versiones ms comunes de Kerberos son dos: la versin 4 [MILL88, STEI88], muy
usada todava, y la versin 5 [KOHL94], que corrige algunas de las deficiencias de se
guridad de la versin 4 y se ha propuesto como Estndar de Internet (RFC 1510)2.
Esta seccin comienza con una breve discusin sobre la motivacin que origin el en
foque Kerberos. Luego, debido a la complejidad de Kerberos, es conveniente proceder a
una descripcin del protocolo de autentificacin empleado en la versin 4, lo que nos
permite observar la esencia de la estrategia de Kerberos sin tener en cuenta algunos de
los detalles necesarios para manejar amenazas sutiles a la seguridad. Por ltimo, exami
naremos la versin 5.
MOTIVACIN
Si un grupo de usuarios dispone de computadores personales sin conexin a la red, los
recursos y archivos de un usuario se pueden proteger asegurando fsicamente cada com
putador. Si, por el contrario, el servidor de estos usuarios consiste en un sistema de tiem
po compartido centralizado, es el sistema operativo de tiempo compartido el que debe
proporcionar la seguridad. El sistema operativo puede reforzar las polticas de control de
acceso basadas en la identidad del usuario y el uso de contraseas para identificar para
los usuarios.
Hoy en da, ninguno de estos casos es habitual. La arquitectura ms comn es la ar
quitectura distribuida formada por estaciones de trabajo de usuarios (clientes) y servi
dores distribuidos o centralizados. En este entorno, se pueden prever tres enfoques a la
seguridad:
1. Confiar en que cada estacin cliente individual asegure la identidad de su usua
rio o usuarios y en que cada servidor refuerce una poltica de seguridad que se
apoye en la identificacin del usuario (ID).
2. Exigir que los sistemas clientes se autentifiquen a los servidores, pero confiar en
el sistema cliente en lo que respecta a la identidad de su usuario.
3. Exigir que el usuario demuestre su identidad para cada servicio solicitado y que
los servidores tambin demuestren su identidad a los clientes.
En un entorno reducido y cerrado en el que todos los sistemas pertenecen a una nica
organizacin, la primera o, quizs, la segunda estrategia puede ser suficiente3. Pero en
un entorno ms abierto con conexiones de red a otras mquinas, se necesita el tercer en
foque para proteger la informacin y los recursos del usuario alojados en el servidor.
Kerberos admite este tercer enfoque. Adems, asume una arquitectura distribuida de
cliente/servidor y emplea uno o ms servidores Kerberos para proporcionar un servicio
de autentificacin.
El primer informe que se public sobre Kerberos [STEI88] presentaba los siguientes
requisitos para Kerberos:
2 Las versiones 1 a la 3 fueron versiones de desarrollo interno. La versin 4 e s e l Kerberos original.
3 Sin embargo, incluso un sistema cerrado se enfrenta a la amenaza del ataque por parte de un emplea
da descontento.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
Seglaridad: un observador de la red no debera poder obtener la informacin ne
cesaria para hacerse pasar por un usuario. Es decir, Kerberos debera ser lo sufi
cientemente robusto para que un posible oponente no lo considere un punto dbil.
Fiabilidad: para todos los servicios que utilizan Kerberos para el control de acce
so, la falta de disponibilidad del servicio de Kerberos implica la falta de disponi
bilidad de los servicios que se proporcionan. As, Kerberos debera ser muy fiable
y emplear una arquitectura de servidores distribuida en la que un sistema pudiera
disponer de copias de otro.
Transparencia: aparte del requisito de introducir una contrasea, es preferible que
el usuario no sea consciente de que est teniendo lugar la autentificacin.
Escalabifidad: el sistema debera poder dar cabida a un gran nmero de clientes y
servidores, lo cual sugiere una arquitectura distribuida modular.
Para lograr estos requisitos, el esquema general de Kerberos es el de un servicio de au
tentificacin de una tercera parte confiable. Es confiable en el sentido de que los clien
tes y los servidores confan en Kerberos para que medie en su autentificacin mutua. Su
poniendo que el protocolo de Kerberos est bien diseado, el servicio de autentificacin
es seguro si el servidor Kerberos es seguro en s mismo4.
VERSIN 4 DE KERBEROS
La versin 4 de Kerberos hace uso del DES, en un protocolo bastante elaborado, para
proporcionar el servicio de autentificacin. Considerando el protocolo en su conjunto,
es difcil entender la necesidad de muchos de los elementos que contiene. Por lo tanto,
adoptamos una estrategia empleada por Bill Bryant del Proyecto Athena [BRYA88] y
desarrollamos el protocolo completo observando primero varios dilogos hipotticos.
Cada dilogo sucesivo presenta una complejidad adicional a las vulnerabilidades a la se
guridad reveladas en el dilogo anterior.
Despus de examinar el protocolo, trataremos otros aspectos de la versin 4.
Un dilogo de autentificacin simple
En un entorno de red sin proteccin, cualquier cliente puede solicitar un servicio a cual
quier servidor. El riesgo ms evidente que corre la seguridad es el de la suplantacin.
Un oponente puede fingir ser otro cliente y obtener privilegios no autorizados en las
mquinas del servidor. Para contrarrestar esta amenaza, los servidores deben poder con
firmar las identidades de los clientes que soliciten el servicio. Se puede requerir que un
4 No debemos olvidar que la seguridad del servidor Kerberos no debera asumirse de forma automtica,
sino que debera ser vigilada cuidadosamente. Es conveniente recordar e l destino del Kerberos griego, a quien
Hrcules captur por orden de Eurystheus: Hrcules encontr al enorme perro encadenado y lo agarr por
el cuello. Enseguida las tres cabezas intentaron atacar, y Kerberos daba latigazos con su poderosa cola. Pero
Hrcules aguant con firmeza y Kerberos perdi la consciencia. Eurystheus pudo haber quedado sorprendi
do al ver a Hrcules vivo cuando l vio las tres cabezas babeantes y el enorme perro al que pertenecan se
aterroriz, y de un salto se refugi en su gran tinaja de bronce. {The Hamlyn Concise Dctonary ofGreek
and Romn Mythoiogy, efe Michael Stapleton, Hamlyn, 1982).
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 95
servidor realice esta tarea para cada interaccin cliente/servidor, pero en un entorno
abierto, este hecho supone una carga considerable en cada servidor.
Una alternativa consiste en el uso de un servidor de autentificacin (AS: Authentca-
ton Servei-) que conozca las claves de todos los usuarios y las almacene en una base de
datos centralizada. Adems, el AS comparte una nica clave secreta con cada servidor.
Estas claves han sido distribuidas fsicamente o de otra forma segura. Consideremos el
siguiente dilogo hipottico5:
(1) C - AS: E>c \ \Pc \\IDv
(2) AS -> C: Ticket
(3) C - V: IDC\\ Ticket
Ticket = E(v [IDq || ADq || TDp]
donde
C = cliente
AS = servidor de autentificacin (Authenticatin Servei)
V = servidor
IDc = identificador de usuario en C
ID/ = identificador de V
Pe = contrasea de usuario de C
ADc = direccin de red de C
Kv= clave secreta de cifrado compartida por AS y V
|| = concatenacin
En este marco hipottico, el usuario se conecta a una estacin de trabajo y solicita
acceso al servidor V. El mdulo del cliente C en la estacin de trabajo del usuario soli
cita la contrasea del usuario y luego enva al AS un mensaje que incluye el ID del usua
rio, el ID del servidor y la contrasea del usuario. El AS comprueba su base de datos
para verificar si el usuario ha dado la contrasea correspondiente a su ID de usuario y si
este usuario tiene permiso para acceder al servidor V. Si se superan las dos comproba
ciones, el AS acepta al usuario como autntico y debe convencer al servidor de dicha au
tenticidad. Para ello, el AS crea un ticket que contiene el ID y la direccin de red del
usuario y el ID del servidor. Este ticket se cifra usando la clave secreta que comparten
el AS y este servidor. Luego, este ticket se devuelve a C. Como el ticket est cifrado, no
puede ser alterado por C ni por ningn oponente.
Ahora, con este ticket C puede solicitar un servicio a V. C enva a V un mensaje que
contiene el ID de C y el ticket. V descrifra el ticket y verifica que el ID del usuario en
el ticket es el mismo que el ID sin cifrar en el mensaje. Si estos dos coinciden, el servi
dor considera al usuario autentificado y concede el servicio solicitado.
Cada uno de los componentes del mensaje (3) es significativo. El ticket se cifra para
evitar modificacin o falsificacin. El ID del servidor (IDfi est incluido en el ticket
para que el servidor pueda verificar que ha descifrado el ticket de forma correcta. El IDc
est incluido en el ticket para indicar que este ticket ha sido emitido por parte de C. Por
4 La parle de la Izquierda de los dos puntos se refiere al emisor y al receptor; la parte de la derecha in
dica los contenidos del mensaje; e l smbolo || indica concatenacin.
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
ltimo, el ADqsirve para cotrarrestar la siguiente amenaza: un oponente podra captu
rar el ticket transmitido en el mensaje (2), luego usar el nombre I Dcy transmitir un men
saje de la forma (3) desde otra estacin de trabajo. El servidor recibira un ticket vlido
que coincide con el ID del usuario y concede acceso al usuario en esa otra estacin de
trabajo. Para prevenir este ataque el AS incluye en el ticket la direccin de red desde
la que se envi la solicitud original y as el ticket es vlido slo si se transmite desde la
misma estacin de trabajo que inicialmente solicit el ticket.
Un dilogo d e autentifcacin m s seguro
Aunque el marco anterior resuelve algunos de los problemas de autentifcacin en un en
torno de red abierto, todava quedan problemas. Sobresalen especialmente dos de ellos.
En primer lugar, nos gustara reducir el nmero de veces que un usuario tiene que in
troducir la contrasea. Supongamos que cada ticket se puede usar una sola vez. Si el
usuario C se conecta a una estacin de trabajo por la maana y desea comprobar su co
rreo en un servidor de correo, debe proporcionar una clave de acceso para obtener un
ticket para dicho servidor. Si C desea comprobar su correo varias veces al da, cada in
tento exige volver a introducir la contrasea. Este hecho se puede mejorar si los tickets
son reutilizables. Para una sola sesin, la estacin de trabajo puede almacenar el ticket
del servidor de correo despus de recibirlo y usarlo en nombre del usuario para mlti
ples accesos al servidor de correo.
Sin embargo, en este esquema queda todava el caso en el que un usuario necesitara
un nuevo ticket para cada uno de los distintos servicios. Si un usuario quisiera acceder
a un servidor de impresin, un servidor de correo, un servidor de ficheros, etc., al prin
cipio de cada acceso se requerira un nuevo ticket y, por consiguiente, exigira que el
usuario introdujera la clave de acceso.
El segundo problema consiste en que el contexto descrito implica la transmisin de
la contrasea en texto claro [mensaje (1)]. Un escucha podra capturar la contrasea y
usar cualquier servicio accesible a la vctima.
Para resolver estos problemas adicionales, introducimos un esquema para evitar las
contraseas en texto claro, y un nuevo servidor, el servidor que concede el ticket, cono
cido como TGS (tcket-grantingserver). El nuevo marco hipottico es el siguiente:
Una vez por sesin d e usuarios
<DC- >AS: IDC\\ IDlgs
(2) A S -> C: EKc[Tcketgs)
Una v por tip o deservicio:
(3) C TGS: IDC\\ IDV\\ Ticketgs
TGS -> C: Tckety
Una vez por sesin deservicio:
(5) C V: IDC\\ TJckety
7cketlgs = EKtgs [IDd ADC\\ IDlgs || TS || Tiempo de vida]
71cketv = Exv [ c | | ADC\\ IDV|| TS2 1| Tiempo de vida]
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 97
El nuevo servicio, TGS, emite los tickets a los usuarios que han sido autentificados
al AS. As, el usuario primero solicita al AS unTGT (Tlcket-Granting Ticket) ticket que
concede un ticket (Ticket(g). El mdulo de cliente almacena este ticket en la estacin de
trabajo del usuario. Cada vez que el usuario requiera acceso a un nuevo servicio, el
cliente se dirige al TGS, usando el ticket para autentificarse a s mismo. Luego el TGS
concede el ticket para el servicio concreto. El cliente guarda cada ticket de servicio y lo
usa para autentificar su usuario a un servidor cada vez que se solicite un servicio en par
ticular. Veamos los detalles de este esquema:
1. El cliente solicita un TGT en nombre del usuario enviando al AS su ID de usua
rio junto con el ID del TGS, indicando una solicitud para usar el servicio del
TGS.
3 El AS responde con un ticket que est cifrado con una clave derivada de la con
trasea del usuario. Cuando esta respuesta llega al cliente, el cliente pide al usua
rio su contrasea, genera la clave e intenta descifrar el mensaje que llega Si se
proporciona la clave de acceso correcta, el ticket se recupera con xito.
Como slo el usuario correcto podra conocer la clave de acceso, slo el usuario
correcto puede recuperar el ticket. As, hemos usado la contrasea para obtener creden
ciales de Kerberos sin tener que transmitir la clave de acceso en texto claro. El ticket
consiste en el ID y la direccin de red del usuario y el ID del TGS. Esto corresponde al
primer contexto. La idea es que este ticket lo pueda usar el cliente para solicitar mlti
ples tickets que conceden servicios. Por lo tanto, el TGT ha de ser reutilizable. Sin em
bargo, no queremos que un oponente pueda capturar el ticket y usarlo. Consideremos el
siguiente caso: un oponente captura el ticket y espera hasta que el usuario haya desco
nectado su estacin de trabajo. Entonces, el oponente obtiene acceso a esa estacin de
trabajo o configura su estacin con la misma direccin de red que la vctima. El opo
nente podra reutilizar el ticket para burlar al TGS. Para contrarrestar esta posibilidad, el
ticket incluye un sello de tiempo (timestamp) con indicacin de la fecha y la hora en que
se emiti el ticket y un tiempo de vida que indica el perodo de validez del ticket (por
ejemplo, ocho horas). De esta forma, el cliente ahora tiene un ticket reutilizable y no tie
ne que pedir al usuario una contrasea para cada servicio que solicite. Por ltimo, hay
que tener en cuenta que el TGT se cifra con una clave secreta que slo conocen el AS y
el TGS, para evitar alteraciones en el ticket. El ticket se vuelve a cifrar con una clave ba
sada en la contrasea del usuario. Esto garantiza que el ticket puede ser recuperado ni
camente por el usuario correcto, proporcionando autentificacin.
Ahora que el cliente tiene un TGT, el acceso a cualquier servidor se puede obtener
por medio de los pasos 3 y 4:
3 El cliente solicita en nombre del usuario un ticket que concede un servicio. Con
este fin, el cliente transmite un mensaje al TGS que contiene el ID del usuario,
el ID del servicio deseado y el TGT.
4 El TGS descifra el ticket recibido y verifica el xito del descifrado con la pre
sencia de su ID. Comprueba que el tiempo de vida (Ufetim) no ha expirado.
Luego compara el ID del usuario y la direccin de red con la informacin reci
bida para autentificar al usuario. Si el usuario tiene permiso para acceder a V, el
TGS emite un ticket para conceder acceso al servicio solicitado.
El ticket que concede un servicio tiene la misma estructura que el TGT. De hecho, como
el TGS es un servidor, sera de esperar que se necesitaran los mismos elementos para au-
www.FreeLibros.org
Fundamentos de seguridad en redes. Aplicaciones y estndares
tentificar un cliente al TGS y para autentificar un cliente a un servidor de aplicaciones.
Nuevamente, el ticket contiene un sello de tiempo y un tiempo de vida. Si el usuario
quiere acceder ms tarde al mismo servicio, el cliente puede usar simplemente el ticket
que concede servicio que se obtuvo previamente y no tiene que pedir al usuario una con
trasea. Obsrvese que el ticket se cifra con una clave secreta ()Q que slo es conocida
por el TGS y el servidor, para evitar alteraciones.
Por ltimo, con un ticket concreto que conceda un servicio, el cliente puede acceder
al servicio correspondiente mediante el paso 5:
5l El cliente solicita acceso a un servicio en nombre del usuario. Con este fin, el
cliente transmite al servidor un mensaje que contiene el ID del usuario y el ticket
que concede el servicio. El servidor autentifica usando los contenidos del ticket.
Este marco satisface los dos requisitos: el de una nica contrasea por sesin de usua
rio y la proteccin de la contrasea del usuario.
El dilogo de autentificacin de la versin 4
Aunque el marco previo mejora la seguridad en relacin con el primer intento, quedan
por resolver dos problemas adicionales. La base del primer problema es el tiempo de
vida asociado al TGT. Si este tiempo de vida es muy corto (por ejemplo, unos minutos),
entonces se pedir al usuario la contrasea repetidamente. Si el tiempo de vida es largo
(por ejemplo, horas), entonces un oponente tiene muchas posibilidades de atacar por re
peticin. Un oponente podra tener escuchas en la red, capturar una copia del TGT y es
perar a que el usuario legtimo se desconecte. Entonces el oponente podra falsificar la
direccin de red del usuario legtimo y enviar el mensaje del paso (3) al TGS. Esto su
pondra para el oponente un acceso ilimitado a los recursos y archivos que estn dispo
nibles al usuario legtimo.
De la misma manera, si un oponente captura un ticket que concede un servicio y lo
usa antes de que expire, tendr acceso al servicio correspondiente.
As, llegamos a un requisito adicional. Un servicio de red (el TGS o un servicio de
aplicaciones) debe ser capaz de comprobar que la persona que usa el ticket es la misma
persona a la que se emiti ese ticket.
El segundo problema consiste en que podra existir el requisito de que los servidores
se autentificaran a s mismos a los usuarios. Sin esta autentificacin, un oponente podra
sabotear la configuracin para que los mensajes destinados a un servidor se dirigieran a
otra localizacin. El servidor falso estara entonces en situacin de actuar como un servi
dor real, capturar cualquier informacin del usuario y rechazar el servicio real al usuario.
Examinamos estos problemas y nos referimos a la Tabla 4.1, que muestra el proto
colo real de Kerberos.
En primer lugar, consideremos el problema de los TGT capturados y la necesidad de
determinar que el que presenta el ticket es el mismo que el cliente para el que se emiti
dicho ticket. La amenaza consiste en que un oponente puede robar el ticket y usarlo an
tes de que expire. Para solventar este problema, supongamos que el AS proporciona tan
to al cliente como al TGS una parte de informacin secreta de forma segura. Entonces
el cliente puede probar su identidad al TGS revelando la informacin secreta, nueva
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 99
mente de forma segura. Una manera eficaz de llevar esto a cabo es usar una clave de ci
frado como informacin segura, que en Kerberos se denomina clave de sesin.
La Tabla 4.1 muestra la tcnica para distribuir la clave de sesin. Como anterior
mente, el cliente enva un mensaje al AS solicitando acceso al TGS. El AS responde con
un mensaje, cifrado con una clave derivada de la contrasea del usuario (Kc) que con
tiene el ticket. El mensaje cifrado tambin contiene una copia de la clave de sesin,
donde los subndices indican que se trata de una clave de sesin para C y TGS.
Como esta clave de sesin est en el mensaje cifrado con Kc slo el cliente del usuario
puede leerla. La misma clave de sesin se incluye en el ticket, que slo podr leer el
TGS. Por lo tanto, la clave de sesin se ha distribuido de forma segura tanto a C como
a TGS.
Antes de continuar, obsrvese que a esta primera fase del dilogo se han aadido par
tes adicionales de informacin. El mensaje (1) incluye un sello de tiempo para que el AS
sepa que el mensaje es oportuno. El mensaje (2) incluye algunos elementos del ticket ac
cesibles a C. Esto permite a C confirmar que este ticket es para el TGS, as como cono
cer su fecha de expiracin.
Con el ticket y la clave de sesin, C est preparado para dirigirse al TGS. Como an
tes, C enva al TGS un mensaje que incluye el ticket y el ID del servicio solicitado [men
saje (3) en la Tabla 4.1b]. Adems, C transmite un autentificador que incluye el ID
Tabla 4.1 Resumen de los intercambios de mensajes de la versin 4
de Kerberos
(a) Intercambio de servicio de autentificacin: para obtener unTGT
(1) C AS: IDC|| IDtgs || TS,
(2) AS C: EKc [ K C/tgs || IDtgs || TS21| Tiempo d e vida2 1| Tickettgs]
Ticketfgs = EKtgs [Kcjgs || IDC\\ADC || IDtgs || TS2 1| Tiempo d e vida2]
(b) Intercambio de TGS: para obtener un ticket que concede un servicio
(3) C -> TGS: IDV || Tickettgs || A u t e n t if ic a d o r c
(4)TGS -4 C: EKC/tgs [ KCiV \\ IDV\\ TS4 \\ Ticketv]
TckettgS = E,<tgs [KCitgs || IDC || A D C || IDtgs || TS2 || Tiempo d e vida2]
Ticketv = EKv [KCiV || IDC || ADC || IDV || 7S4 1| Tiempo d e v i da4]
A u t e n t if ic a d o r c = EKctgsUDc II ADc \ \T S 3]
(c) Intercambio de autentificacin cliente/servidor: para obtener un servicio
(5) C - V: Ticketv || A u t e n t if ic a d o r c
(6) V C: EKC v,[TS5 + 1] ( p a r a a u t e n t i f i c a c i n m u t u a )
Ticketv = EKv [KCiV || IDC \ \ A D C \\ Dv || TS4 1| Tiempo d e vida4]
A u t e n t if ic a d o r c = KC/V [ IDC || ADC || 7S5]
www.FreeLibros.org
100 Fundamentos de seguridad en redes. Aplicaciones y estndares
y la direccin del usuario de C y un sello de tiempo. A diferencia del ticket, que es reuti-
lizable, el autentificador est destinado para un nico uso y tiene un tiempo de vida muy
corto. El TGS puede descifrar el ticket con la clave que comparte con el AS. Este ticket
indica que se ha proporcionado la clave de sesin Kc,tg* al usuario C. De hecho, el ticket
dice Cualquiera que use Kc,tgs* debe ser C. El TGS usa la clave de sesin para descifrar
el autentificador. El TGS, luego, puede comprobar el nombre y la direccin del autentifi
cador con el del ticket y con la direccin de red del mensaje recibido. Si todo coincide, en
tonces el TGS est seguro de que el emisor del ticket es el autntico propietario del ticket.
En efecto, el autentificador dice En la fecha TS$, uso Kc t^ . Obsrvese que el ticket no
prueba la identidad de nadie, sino que se trata de una forma segura de distribuir las claves.
Es el autentificador el que demuestra la identidad del cliente. Como el autentificador se
puede usar una sola vez y tiene un tiempo de vida corto, se contrarresta la amenaza de un
oponente que robe tanto el ticket como el autentificador para su posterior presentacin.
La respuesta desde el TGS, en el mensaje (4), sigue la forma del mensaje (2). El men
saje se cifra con la clave de sesin compartida por el TGS y C e incluye una clave de se
sin que ha de ser compartida por C y el servidor V, el ID de V, y el sello de tiempo del
ticket. El ticket incluye la misma clave de sesin.
Ahora C tiene un ticket que concede un servicio reutilizable para V. Cuando C presen
ta este ticket, como se muestra en el mensaje (5), tambin enva un autentificador. El ser
vidor puede descifrar el ticket, recuperar la clave de sesin y descifrar el autentificador.
Si se requiere autentificacin mutua, el servidor puede responder como se muestra
en el mensaje (6) de la Tabla 4.1. El servidor devuelve el valor del sello de tiempo del
autentificador, incrementado en 1 y cifrado en la clave de sesin. C puede descifrar este
mensaje para recuperar el sello de tiempo incrementado. Debido a que el mensaje fue
cifrado por la clave de sesin, C est seguro de que slo pudo haber sido creado por V.
Los contenidos del mensaje garantizan a C que no se trata de la repeticin de una res
puesta antigua.
Por ltimo, en la conclusin de este proceso, el cliente y el servidor comparten una
clave secreta. Esta clave puede usarse para cifrar futuros mensajes entre los dos o para
intercambiar una nueva clave de sesin aleatoria con ese propsito.
La Tabla 4.2 resume la justificacin para cada uno de los elementos del protocolo
Kerberos, y la Figura 4.1 proporciona una visin simplificada de la accia
Tabla 4.2 Base lgica para los elementos del protocolo de la versin 4
de Kerberos
(a) Intercambio del servicio de autentificacin
Mensaje (1) El cliente solicita elTGT
IDC: Dice al AS la identidad del usuario desde este cliente
IDtgs:
Dice a AS que el usuario solicita acceso al TGS
73,: Permite que AS verifique que el reloj del cliente est sin
cronizado con el del AS
(c o n t in a )
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 101
Tabla 4.2 Base lgica para los elementos del protocolo de la versin 4
de Kerberos ( c o n t i n u a c i n )
Mensaje (2)
e k
Kc,tgs-
ID,gs:
TS
Tiempo d e vida2:
Ticketfgs:
AS devuelve elTGT
El cifrado se basa en la contrasea del usuario, permi
tiendo que AS y el cliente verifiquen la contrasea, y pro
tegiendo los contenidos del mensaje (2)
Copia de la clave de sesin accesible al cliente; creada
por el AS para permitir un intercambio seguro entre el
cliente y el TGS sin exigirles que compartan una clave
permanente
Confirma que este ticket es para el TGS
Informa al cliente del momento en que este ticket fue
emitido
Informa al cliente sobre el tiempo de vida de este ticket
Ticket que va a usar el cliente para acceder al TGS
(b) Intercambio de TGS
Mensaje (3) El cliente solicita un ticket que concede un servicio
ID/ Dice alTGS que el usuario solicita acceso al servidorV
Ticket,gs. Garantiza al TGS que este usuario ha sido autentificado
por el AS
Autentiftador Generado por el cliente para validar el ticket
Mensaje (4) El TGS devuelve el ticket que concede un servicio
EKc,tgs:
Clave compartida slo por C yTGS; protege los conteni
dos del mensaje (4)
Kc,tgs:
Copia de la clave de sesin accesible al cliente; creada
por TGS para permitir un intercambio seguro entre el
cliente y el servidor sin exigirles que compartan una cla
ve permanente
DV.
Confirma que este ticket es para el servidorV
TS Informa al cliente del momento en que este ticket fue
emitido
Tickets Ticket que ha de usar el cliente para acceder al servidorV
Ticket^ : Reutilizable para que el usuario no tenga que volver a in
troducir una clave de acceso
EKtgs:
El ticket se cifra con una clave que es conocida slo por
AS yTGS, para evitar falsificacin
Kc,tgs:
Copia de la clave de sesin accesible a TGS; usada para
descifrar el autentificador, autentificando por lo tanto el
ticket
IDC:
Indica el propietario correcto de este ticket
( contina)
www.FreeLibros.org
102 Fundamentos de seguridad en redes. Aplicaciones y estndares
Tabla 4.2 Base lgica para los elementos del protocolo de la versin 4
de Kerberos ( c o n t i n u a c i n )
ADc'. Evita que el ticket se use desde otra estacin de trabajo
que no sea la que inicialmente lo solicit
IDtgs: Garantiza al servidor que ha descifrado el ticket correcta
mente
TS2: Informa al TGS del momento en que este ticket fue emi
tido
Tiempo d e vida Evita la repeticin una vez que el ticket ha expirado
A ut e nt if ic ad or Garantiza al TGS que el que presenta el ticket es el mis
mo que el cliente para el cual se emiti el ticket; tiene un
tiempo de vida muy corto para evitar repeticiones
(b) Intercambio de TGS ( conti nuacin)
EKc,tgs:
El autentificador se cifra con una clave conocida slo por
el cliente y elTGS, para evitar falsificaciones
IDC:
Debe coincidir con el ID que aparece en el ticket para au
tentificar el ticket
A D q. Debe coincidir con la direccin que aparece en el ticket
para autentificar el ticket
TS2: Informa al TGS del momento en que se gener este au
tentificador
(c) Intercambio de autentificacin cliente/servidor
Mensaje (5) El cliente solicita un servicio
Ticketv Garantiza al servidor que este usuario ha sido autentifi
cado por AS
A ut e nt if ic ad or Generado por el cliente para validar el ticket
Mensaje (6) Autentificacin opcional del servidor al cliente
Ekcv-
Garantiza a C que este mensaje proviene de V
TS5+I: Garantiza a C que no se trata de una repeticin de una
respuesta antigua
Ticket- Reutilizable para que el cliente no tenga que solicitar un
nuevo ticket al TGS para cada acceso al mismo servidor
Ekv'
B ticket se cifra con una clave conocida slo por el TGS
y el servidor, para evitar falsificacin
Kc
Copia de la clave de sesin accesible al cliente; usada
para descifrar el autentificador, autentificando por lo tan
to el ticket
IDC:
Indica el propietario correcto de este ticket
(c o n t in a )
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 103
Tabla 4.2 Base lgica para los elementos del protocolo de la versin 4
de Kerberos ( c o n t i n u a c i n )
ADC: Evita el uso del ticket desde una estacin de trabajo que
no sea la que inicialmente lo solicit
ID\a Garantiza al servidor que ha descifrado el ticket correcta
mente
TS Informa al servidor del momento en que se emiti el tic
ket
Tiempo d e vida4. Evita repeticiones una vez que el ticket ha expirado
A ut e nt if ic ad or Garantiza al servidor que el que presenta el ticket es el
mismo que el cliente para el cual se emiti; tiene un
tiempo de vida muy corto para evitar repeticiones
E Kc,
El autentificador se cifra con una clave conocida slo por
el cliente y el servidor, para evitar falsificaciones
ID Debe coincidir con el ID que aparece en el ticket para au
tentificar el ticket
ADC: Debe coincidir con la direccin que aparece en el ticket
para autentificar el ticket
TS Informa al servidor del momento en que se gener este
autentificador
2 . El AS verif ica e l acceso del usuario en la base de datos,
crea elTGT y la clave de sesin. Los resultados se cifran
usando una clave derivada de la contrasea del usuario.
Kerberos
p or
t i p o de servicio
3. La estacin de
b contrasea y la usa
para descifrar el
mensaje recibido.
Luego enva alTGS el
ticket y el autentificador Una vez por
que contiene el n om b r e sesin
de usuario, la direccin ^ s e r v i c i o
de red y la fecha.
5. La estacin d e trabajo
enva el t i cke t y el
aut entificador al servidor.
4 . EITGS descifra el ticket y el autentificador,
verifica la solicitud y l uego crea el ticket para el
ser vid o r solicitado.
6 . El se r vid o r verifica que el t i c
ket y el aut entificador coinciden,
l uego concede acceso al servicio.
Si se requiere autentificacin mu
tua, el se r vid o r devuelve un au
tentificador.
1. El usuario se
conecta a una
estacin de tr a b a
ja y solicita un
servicio en el host.
Una vez
p or sesin
Figura 4.1 Esquema general de Kerberos
www.FreeLibros.org
104 Fundamentos de seguridad en redes. Aplicaciones y estndares
DOMINIOS DE KERBEROS Y KERBEROS MULTIPLES
Un entorno de Kerberos con todo tipo de servicios formado por un servidor Kerberos,
una serie de clientes y un grupo de servidores de aplicaciones necesitan lo siguiente:
L El servidor Kerberos debe tener el ID de usuario y la contrasea de todos los
usuarios en esta base de datos. Todos los usuarios estn registrados con el servi
dor Kerberos.
Z El servidor Kerberos debe compartir una clave secreta con cada servidor. Todos
los servidores estn registrados con el servidor Kerberos.
Un entorno como este se conoce como domara Las redes de clientes y servidores per
tenecientes a diferentes organizaciones administrativas constituyen comnmente
distintos dominios. Es decir, en general no es prctico, o no se ajusta a la poltica admi
nistrativa, tener usuarios y servidores en un dominio administrativo registrados con un
servidor Kerberos de otro dominio. Sin embargo, los usuarios de un dominio pueden
necesitar acceso a servidores en otros dominios, y algunos servidores pueden estar dis
puestos a proporcionar el servicio a usuarios de otros dominios si dichos usuarios se au
tentifican.
Kerberos proporciona un mecanismo para permitir la autentificacin entre domi
nios. Para que dos dominios permitan la autentificacin entre ellos, se aade un tercer
requisito:
3L El servidor Kerberos en cada uno de los dominios que interoperan comparte una
clave secreta con el servidor del otro dominio. Los dos servidores Kerberos se
registran entre s.
El esquema requiere que el servidor Kerberos de un dominio confe en el servidor Ker
beros del otro dominio para autentificar sus usuarios. Adems, los servidores en el se
gundo dominio tambin deben estar dispuestos a confiar en el servidor Kerberos del pri
mer dominio.
Teniendo en cuenta estas normas, podemos describir el mecanismo de la siguiente
manera (Figura 4.2): un usuario que quiera un servicio de un servidor en otro dominio
necesita un ticket para ese servidor. El cliente del usuario sigue los procedimientos ha
bituales para acceder al TGS local y luego solicita un TGT para un TGS remoto (un TGS
en otro dominio). Luego, el cliente puede solicitar al TGS remoto un ticket que conce
de un servicio para el servidor deseado en el dominio del TGS remoto.
Los detalles de los intercambios ilustrados en la Figura 4.2 son los siguientes (com
parar con la Tabla 4.1):
(1) C - AS: IDC\\ IDlgs || TS{
(2) AS -> C: EKc [Kcgs || IDtgs || TS || Tiempo de vida21| Ticket^
(3) C -> TGS: IDgsnn || Ticket^ || Autentifcadorc
(4) TGS C: EKctgs I^c,tgsrem II Igsrem II ^ 4 II ^^l/gsrem]
(5) C - TGSrem: I D ^ W Ticket^m || Autentifcadorc
(6) TGSrem > C: EKC'tgsiem [Kc,vrem II ^vrem II TSq|| Ticket^n,]
(7) C-Vrem: Ticket^n, || Autenticadorc
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 105
Figura 4.2 S o l i c i t u d d e s e r v i c i o e n o t r o d o m i n i o
El ticket presentado al servidor remoto ( V^m) indica el dominio en el que el usuario
fue autentificado originalmente. El servidor decide si acepta la solicitud remota.
Un problema que presenta el enfoque anterior es que no puede abarcar muchos do
minios. Si hay TVdominios, entonces debe haber N( N- l)/2 intercambios de clave segu
ros para que cada dominio de Kerberos pueda interoperar con todos los dems dominios.
VERSIN 5 DE KERBEROS
La versin 5 de Kerberos se especifica en el RFC 1510 y proporciona una serie de me
joras con respecto a la versin 4 [KOHL94]. En primer lugar, consideraremos una visin
general de los cambios producidos desde la versin 4 a la 5 y posteriormente nos cen
traremos en el protocolo de la versin 5.
www.FreeLibros.org
106 Fundamentos de seguridad en redes. Aplicaciones y estndares
Diferencias entre las versiones 4 y 5
La versin 5 est diseada para superar las limitaciones de la versin 4 en dos reas de
terminadas: deficiencias de entorno y deficiencias tcnicas. Vamos a resumir brevemen
te las mejoras realizadas en cada rea6.
La versin 4 de Kerberos se desarroll para su uso en el entorno del proyecto Athe-
na y, por consiguiente, no cubra del todo la necesidad de ser de propsito general. Esto
origin los siguientes fallos d e o t o o :
L Dependencia d d sistema d e cifrado: la versin 4 requiere el uso del DES. La
restriccin de exportacin del DES y las dudas sobre su robustez son, por ello,
aspectos de inters. En la versin 5, al texto cifrado se le aade un dentificador
del tipo de cifrado para que pueda usarse cualquier tcnica de cifrado. A las
claves de cifrado se les aade un tipo y una longitud, permitiendo que la misma
clave se emplee en diferentes algoritmos y haciendo posible la especificacin de
diferentes variaciones en un algoritmo dado.
Z Dependencia dd protocolo de Internet: la versin 4 requiere el uso de direccio
nes IP (Internet Pwtocol). Otros tipos de direcciones, como la direccin de red
ISO, no tienen cabida. En cambio, las direcciones de red de la versin 5 estn mar
cadas con tipo y longitud, permitiendo as el uso de cualquier tipo de direccin.
3 Ordenacin d e los bytes del mensaje en la versin 4, el emisor de un mensa
je emplea un orden de bytes de su eleccin y aade al mensaje un indicador del
byte menos significativo en la direccin ms baja o el byte ms significativo en
la direccin ms baja. Esta tcnica funciona pero no sigue convenciones esta
blecidas. En la versin 5, todas las estructuras de mensaje se definen usando
ASN.l (Abstract SyntaxNotation One) y BER (Basic EncodingRule$ , que pro
porcionan una ordenacin de bytes sin ambigedad.
4 Tiempo de vida dd ticket: los valores del tiempo de vida en la versin 4 se co
difican en cantidades de ocho bits en unidades de cinco minutos. As, el tiempo
de vida mximo que puede expresarse es 28 x 5 = 1280 minutos, o algo ms de
21 horas. Esto puede ser inadecuado para algunas aplicaciones (por ejemplo, una
simulacin de larga ejecucin que requiera credenciales vlidas de Kerberos a lo
largo de la ejecucin). En la versin 5, los tickets incluyen una fecha explcita de
comienzo y de fin, permitiendo que los tickets tengan tiempos de vida arbitrarios.
Envo d e aitffltfcadn: la versin 4 no permite que las credenciales emitidas a
un cliente sean enviadas a otro hosty usadas por otro cliente. En cambio, la ver
sin 5 s permite que un cliente tenga acceso a un servidor y que ese servidor ten
ga acceso a otro servidor en nombre del cliente. Por ejemplo, un cliente enva una
solicitud a un servidor de impresin que luego accede al fichero del cliente desde
un servidor de ficheros, usando las credenciales del cliente para acceder.
6 Autentificacin entre dominios: en la versin 4, la interoperabilidad entre N
dominios necesita del orden de N2 relaciones Kerberos a Kerberos, como se des
cribi anteriormente. En la versin 5 se requieren menos relaciones.
Adems de estas limitaciones de entorno, hay deficiencias t a ik a s en el protocolo de
la versin 4. La mayora de estas deficiencias se documentaron en [BELL90], y la ver
sin 5 intenta superarlas. Dichas deficiencias son las siguientes:
6 La siguiente discusin sigue la presentacin en [KOHL94].
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentifcacin 107
L Cifrado doble: obsrvese en la Tabla 4.1 [mensajes (2) y (4)] que los tickets
proporcionados a los clientes se cifran dos veces, una vez con la clave secreta
del servidor meta y luego otra vez con la clave secreta conocida por el cliente.
El segundo cifrado no es necesario y es intil computacionalmente.
2. Cifrado PCBC: el cifrado en la versin 4 hace uso de un modo no estndar del
DES conocido como PCBC (Propagating Cipher Block Chaning) 7. Se ha de
mostrado que este modo es vulnerable a un ataque que implica el intercambio de
bloques de texto cifrado [KOHL89]. El PCBC fue diseado para la comproba
cin de la integridad como parte de la operacin de cifrado. La versin 5 pro
porciona mecanismos explcitos de integridad, permitiendo el uso del modo es
tndar CBC para el cifrado.
3L Claves de sesin: cada ticket incluye una clave de sesin que usa un cliente para
cifrar el autentificador enviado al servicio asociado con ese ticket. Adems, la
clave de sesin pueden usarla posteriormente el cliente y el servidor para prote
ger los mensajes que pasen durante esa sesin. Sin embargo, debido a que el
mismo ticket podra usarse repetidamente para obtener servicio de un servidor
particular, existe el riesgo de que un oponente reenve mensajes de una sesin
antigua al cliente o al servidor. En la versin 5 es posible que un cliente y un ser
vidor negocien una clave de subsesin, que ha de usarse slo para esa conexin.
Un nuevo acceso por parte del cliente dara como resultado el uso de una nueva
clave de subsesin.
4 Ataques d e contrasea: las dos versiones son vulnerables al ataque de contra
sea. El mensaje que enva el AS al cliente incluye material cifrado con una cla
ve basada en la contrasea del cliente8. Un oponente puede capturar este men
saje e intentar descifrarlo probando varias contraseas. Si el resultado de un
descifrado de prueba es adecuado, entonces el oponente ha descubierto la con
trasea del cliente y puede usarla posteriormente para obtener credenciales de
autentifcacin de Kerberos. Este es el mismo tipo de ataque de contrasea des
crito en el Captulo 9, al que se aplica el mismo tipo de contramedidas. La ver
sin 5 ofrece un mecanismo conocido como preautentifcacin, que debera di
ficultar los ataques de contrasea, aunque no los evita.
EL DILOGO DE AUTENTIFCACIN DE LA VERSIN 5
La Tabla 4.3 resume el dilogo bsico de la versin 5. Se explica mejor por compara
cin con la versin 4 (Tabla 4.1).
En primer lugar, consideremos el intercambio d e servido de autentifcacin El
mensaje (1) es la solicitud de unTGT realizada por un cliente. Como antes, incluye el
ID del usuario y el TGS. Se aaden los siguientes elementos:
Dominio: indica el dominio del usuario.
Opciones: se usan para solicitar que se fijen determinados indicadores en el ticket
de regreso.
7 Descrito en el Apndice 4 A.
8 El Apndice 4 A describe la correspondencia entre las contraseas y las claves de cifrado.
www.FreeLibros.org
108 Fundamentos de seguridad en redes. Aplicaciones y estndares
Tabla 4.3 Resumen de los intercambios de mensajes de la versin 5 de Kerberos
(a) Intercambio de servicio de autentificacin: para obtener el TGT
(1) C AS: Opciones || IDq || Do m in i o c || IDtgs || Tiem pos || Nonce\
(2) AS - C: Dominioc || IDC || Ticket& || EKc[ K CitgS || Tiempos || Nonce*] || Dom iniotgs
II IDtgs
TickettgS = E,<fgs [ In di c ado r es || KC/lgs || D o m i n i o c || IDC || A D C || Tiempos]
(b) Intercambio deTGS: para obtener un ticket que concede un servicio
(3) C - TGS: Opciones || IDV || Tiempos || Nonce2 1| T i c k e t || A u t e n t if ic a d o r c
(4) TGS C: Dom inioc || IDC || Ticketv || EKq [KCrV || Tiempos || Nonce2 1| Do m in i o v
II IDv\
Tickettgs = EK{gs [ In di c ado r es i i ' W i i Dom ini oc || IDC || ADC\\ Tiempos]
Ticketv = EKv[ ln d ic a d o r e s || KctV || D o m i n i o c || IDC || ADC|| Tiempos]
A u t e n t i f i c a d o r c = Ef<c ^ [IDq || Do m in i o c || TSd
(c) Intercambio de autentificacin cliente/servidor: para obtener servicio
(5) C V: Opciones || Ticketv || A u t e n t i f i c a d o r c
(6) V - C: EKcv [TS2 || Sub cla ve || Seq#]
Ticketv = EKv[ ln d ic a d o r e s || Kc v || D o m i n i o c || IDC || ADC|| Tiempos]
A u t e n t i f i c a d o ^ = E< [IDq || Do m i n i o c || TS2 || Sub cla ve]] Seq#]
c,v
Tionpos: los usa el cliente para solicitar los siguientes valores de tiempo para el
ticket:
ronr. la fecha de comienzo deseada para el ticket solicitado.
til}, la fecha de expiracin deseada para el ticket solicitado.
rtme. la nueva fecha de expiracin solicitada.
Nance un valor aleatorio que se debe repetir en el mensaje (2) para garantizar que
la respuesta es reciente y no ha sido capturada y reenviada por ningn oponente
El mensaje (2) devuelve un TGT, informacin de identificacin del cliente y un blo
que cifrado por medio de la clave de cifrado basada en la contrasea del usuario. Este
bloque incluye la clave de sesin que ha de usarse entre el cliente y el TGS, los tiempos
especificados en el mensaje (1), el nonce del mensaje (1) e informacin de identifica
cin del TGS. El ticket incluye la clave de sesin, informacin de identificacin del
cliente, los valores de tiempo requeridos y los indicadores que reflejan el estado de este
ticket y las opciones solicitadas. Aunque estos indicadores aaden mayor funcionalidad
a la versin 5, por el momento postergamos la discusin sobre estos indicadores y nos
concentramos en la estructura general del protocolo de la versin 5.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 109
Comparemos ahora el mtercambio deTGS para las versiones 4 y 5. Se observa que
el mensaje (3) para las dos versiones incluye un autentificador, un ticket y el nombre del
servicio requerido. Adems, la versin 5 incluye los tiempos y las opciones solicitados
para el ticket y un nonce, todos con funciones similares a las del mensaje (1). El auten
tificador es el mismo que el que se usa en la versin 4.
El mensaje (4) tiene la misma estructura que el mensaje (2), devolviendo un ticket e
informacin que necesita el cliente. Dicha informacin se ha cifrado con la clave de se
sin que ahora comparten el cliente y el TGS.
Por ltimo, en la versin 5 aparecen nuevas caractersticas para el intercambio de
autentificacin dknteteervidflr. En el mensaje (5), el cliente puede solicitar de forma
opcional que se requiera autentificacin mutua. El autentificador incluye los nuevos
campos que se exponen a continuacin:
Subdarves una clave de cifrado elegida por el cliente que se usar para proteger
esta sesin concreta de la aplicacin. Si se omite este campo, se usa la clave de se
sin (KCJ suministrada en el ticket del mensaje (4).
Nmero de secuencia: un campo opcional que especifica el nmero inicial de se
cuencia que va a usar el servidor para los mensajes enviados al cliente durante esta
sesin. Los mensajes se pueden numerar secuencalmente para detectar ataques de
repeticin.
Si se requiere autentificacin mutua, el servidor responde con el mensaje (6). El mensa
je incluye el sello de tiempo que contena el autentificador. Obsrvese que en la ver
sin 4, el sello de tiempo se incrementaba en uno. Esto no es necesario en la versin 5
porque la naturaleza del formato de los mensajes no permite que un oponente cree el
mensaje (6) sin conocer las claves de cifrado apropiadas. En caso de estar presente, el
campo de subclave invalida, si estuviera presente, al campo de subclave del mensaje (5).
El campo opcional de nmero de secuencia especifica el nmero inicial de secuencia
que va a usar el cliente.
Indicadores del ticket
El campo de indicadores incluido en los tickets en la versin 5 ofrece mayor funciona
lidad, en comparacin con la versin 4. La Tabla 4.4 resume los indicadores que pueden
incluirse en un ticket.
El indicador INITIAL indica que este ticket fue emitido por el AS, no por el TGS.
Cuando un cliente solicita al TGS un ticket que concede un servicio, presenta un TGT
obtenido del AS. En la versin 4, ste era el nico modo de obtener un ticket que con
cede un servicio. La versin 5 proporciona la capacidad adicional de que el cliente pue
de obtener dicho ticket directamente del AS. La utilidad de este hecho reside en que un
servidor como, por ejemplo, un servidor de cambio de contrasea, puede querer saber
que la contrasea del cliente se ha comprobado recientemente.
El indicador PRE-AUTHENT, si se ha utilizado, indica que cuando el AS recibi la
solicitud inicial [mensaje (1)], autentific al cliente antes de emitir un ticket. La forma
exacta de esta preautentificacin queda sin especificar. Un ejemplo de ello lo tenemos en
que la implementacin MIT de la versin 5 dispone de preautentificacin cifrada de se
llo de tiempo, habilitada por defecto. Cuando un usuario quiere obtener un ticket, tiene
www.FreeLibros.org
Tabla 4 .4 Indicadores de la versin 5 de Kerberos
110 Fundamentos de seguridad en redes. Aplicaciones y estndares
I N I T I A L E ste t ic k e t s e e m i t i u s a n d o el p r o t o c o l o del A S , y n o b a s a
do e n u n TGT.
P R E - A U T H E N T D u r a n t e l a a u t e n t i f i c a c i n i n i c i a l , e l c l i e n t e f u e a u t e n t i f i c a
do p o r el KDC a n t e s d e q u e s e e m i t i e r a u n t i c k e t .
H W - A U T H E N T El p r o t o c o l o e m p l e a d o p a r a l a a u t e n t i f i c a c i n i n i c i a l r e q u i
ri el us o de l h a r d w a r e q u e se e s p e r a b a q u e p o s e y e r a slo
el c l i e n t e e n c u e s t i n .
RENEWABLE D i c e a l T G S q u e e s t e t i c k e t s e p u e d e u s a r p a r a o b t e n e r un
t i c k e t n u e v o q u e e x p i r a e n u n a f e c h a p o s t e r i o r .
MAY-POSTDATE D i c e al T G S q u e se p u e d e e m i t i r u n t ic k e t co n f e c ha p o s t e
r i o r b a s a d o e n es teT GT.
POSTDATED I n d i c a q u e l a f e c h a d e este t i c k e t h a s i d o p o s p u e s t a ; el s e r
v i d o r f i n a l p u e d e c o m p r o b a r el c a m p o a u t h t i m e p a r a v e r
c u n d o s e p r o d u j o l a a u t e n t i f i c a c i n o r i g i n a l .
I N V A L I D E s t e t i c k e t n o es v l i d o y d e b e se r v a l i d a d o p o r el K DC a n
t e s d e s e r u s a d o .
PROXI ABLE L e d i c e a l T G S q u e se p u e d e e m i t i r u n n u e v o t i c k e t q u e o t o r
g a s e r v i c i o s co n u n a d i r e c c i n d e r e d d i f e r e n t e , b a s a d o en
e l t ic k e t p r e s e n t a d o .
P R O X Y I n d i c a q u e e s t e t ic k e t es u n p r o x y .
FORWAR DABLE Le d i c e al T G S q u e s e p u e d e e m i t i r un n u e v o T G T co n un a
d i r e c c i n d e r e d d i f e r e n t e , b a s a d o e n es teT GT.
FORWARDED I n d i c a q u e e s t e t i c k e t se h a r e e n v i a d o o qu e s e h a e m i t i d o
b a s n d o s e e n l a a u t e n t i f i c a c i n q u e i m p l i c a u n T G T r e e n
v i a d o .
que enviar al AS un bloque de preautentificacin que contenga un valor aleatorio, un n
mero de versin y un sello de tiempo, cifrado en la clave basada en la contrasea del usua
rio. El AS descifra el bloque y no entregar el TGT solicitado a menos que el sello de
tiempo del bloque de preautentificacin se encuentre dentro de los mrgenes de tiempo
permitidos (intervalo de tiempo para dar cuenta de fallos de reloj y retardos de red). Otra
posibilidad es el uso de una tarjeta inteligente que genera contraseas que cambian con
tinuamente y que se incluyen en los mensajes preautentificados. Las contraseas genera
das por la tarjeta pueden estar basadas en la contrasea de un usuario pero pueden ser
transformadas por la tarjeta para que, en efecto, se usen contraseas arbitrarias, lo cual
evita los ataques basados en contraseas fciles de adivinar. El uso de una tarjeta inteli
gente o de un dispositivo similar quedara reflejado mediante el indicador HW-AU-
THENT.
Cuando un ticket tiene un tiempo de vida largo, existe la posibilidad de que un opo
nente lo robe y lo use durante un perodo de tiempo considerable. Sin embargo, fijar un
tiempo de vida corto para reducir la amenaza implica un alto coste en la adquisicin de
nuevos tickets. En el caso de un TGT, el cliente tendra que almacenar la clave secreta
del usuario, lo cual es arriesgado, o pedirle repetidamente una contrasea. Un esquema
intermedio consiste en el uso de tickets renovables. Un ticket con el indicador RENE-
WABLE incluye dos tiempos de caducidad: uno para este ticket especfico y otro que es
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 1 1 1
el ltimo valor permitido para un tiempo de expiracin. Un cliente puede renovar el tic
ket presentndolo al TGS con un nuevo tiempo de expiracin solicitado. Si el nuevo
tiempo se encuentra dentro del lmite del ltimo valor permitido, el TGS puede emitir
un nuevo ticket con un nuevo tiempo de sesin y un tiempo de expiracin especfico pos
terior. La ventaja de este mecanismo es que el TGS podra denegar la renovacin de un
ticket si tiene constancia de que ha sido robado.
Un cliente puede solicitar que el AS proporcione un TGT con el indicador MAY-
POSTDATE. Luego el cliente puede usar este ticket para solicitar al TGS un ticket con
el indicador POSTDATED e INVALID. A continuacin, el cliente puede someter a va
lidacin el ticket cuya fecha se ha pospuesto. Este esquema puede ser til para ejecutar
una tarea batch larga en un servidor que requiere un ticket de forma peridica. El clien
te puede obtener de una sola vez un nmero de tickets para esta sesin, con valores de
tiempo diferentes. Inicialmente son invlidos todos menos el primer ticket. Cuando la
ejecucin alcanza el momento en que se necesita un ticket nuevo, el cliente puede obte
ner la validacin del ticket apropiado. Con este enfoque, el cliente no tiene que usar re
petidamente su TGT para obtener un ticket que otorga servicios.
En la versin 5 un servidor puede actuar como proxyen nombre de un cliente, adop
tando, efectivamente, las credenciales y los privilegios del cliente para solicitar un ser
vicio de otro servidor. Si un cliente desea usar este mecanismo, solicita un TGT con el
indicador PROXIABLE. Cuando este ticket se presenta al TGS, el TGS tiene permiso
para emitir un ticket que otorga servicio con una direccin de red diferente; este ltimo
ticket tendr su indicador PROXY. Una aplicacin que reciba tal ticket podra aceptarla
o exigir autentificacin adicional para proporcionar un informe de auditora.
El concepto proxyes un caso limitado del procedimiento ms potente de reenvo. Si
a un ticket se le aade el indicador FORWARDABLE, un TGS puede emitir al solici
tante un TGT con una direccin de red diferente y con el indicador FORWARDED. Este
ticket, luego, puede presentarse a un TGS remoto. Esta capacidad permite a un cliente
acceder a un servidor de otro dominio sin que sea necesario que cada Kerberos manten
ga una clave secreta con los servidores Kerberos en cada uno de los dems dominios.
Por ejemplo, los dominios podran estructurarse jerrquicamente. Entonces un cliente
podra ascender por el diagrama de rbol hasta llegar a un nodo comn y luego volver
atrs para llegar a un dominio meta. Cada paso del recorrido implicara el reenvo de un
TGT al siguiente TGS en la ruta.
4 . 2 SERVICIO DE AUTENTIFICACIN DE X . 5 0 9
El estndar X.509 de la recomendacin ITU-T es parte de la serie de recomendaciones
X.500 que definen un servicio de directorio. El directorio es, en efecto, un servidor o un
grupo distribuido de servidores que mantiene una base de datos con informacin sobre
los usuarios. La informacin incluye la correspondencia entre nombre de usuario y di
reccin de red, as como otros atributos e informacin acerca de los usuarios.
X.509 define un marco para la provisin de servicios de autentificacin por parte del
directorio X.500 a sus usuarios. El directorio puede servir como depsito de certificados
de clave pblica. Cada certificado contiene la clave pblica de un usuario y est firma
do con la clave privada de una autoridad de certificacin confiable. Adems, X.509 de-
www.FreeLibros.org
112 Fundamentos de seguridad en redes. Aplicaciones y estndares
fine protocolos alternativos de autentifcacin basados en el uso de certificados de clave
pblica.
El X.509 es un estndar importante debido a que la estructura del certificado y los
protocolos de autentifcacin definidos en l se usan en una variedad de contextos. Por
ejemplo, el formato del certificado X.509 se usa en S/MIME (Captulo 5), seguridad IP
(Captulo 6) y SSL/TLS y SET (Captulo 7).
El X.509 se public por primera vez en 1988. El estndar se revis posteriormente
para cubrir algunos de los aspectos de seguridad documentados en [IANS90] y
[MITC90]; en 1993 se emiti una recomendacin revisada. Una tercera versin se lan
z en 1995 y se revis en 2000.
El X.509 se basa en el uso de criptografa de clave pblica y firmas digitales. El es
tndar no indica el uso de un algoritmo especfico pero recomienda el RSA. El esquema
de firma digital requiere el uso de una funcin hash. Nuevamente, el estndar no indica
un algoritmo hash especfico. La recomendacin de 1988 inclua la descripcin de un
algoritmo hash recomendado, que desde entonces ha demostrado ser inseguro y fue re
tirado de la recomendacin de 1993.
CERTIFICADOS
La base del esquema de X.509 es el certificado de clave pblica asociado a cada usua
rio. Estos certificados de usuario los crea alguna autoridad de certificacin confiable
(AC), y dicha autoridad o el usuario los colocan en el directorio. El servidor de directo
rio no es el responsable de la creacin de claves pblicas ni de la funcin de certifica
cin; simplemente proporciona una ubicacin de fcil acceso para que los usuarios ob
tengan certificados.
La Figura 4.3a muestra el formato general de un certificado, que incluye los si
guientes elementos:
Versin: distingue entre versiones sucesivas del formato de certificado; la versin
por defecto es la 1. Si el identificador nico del emisor del certificado o el identi-
ficador nico del sujeto estn presentes, el valor debe ser la versin 2. Si estn pre
sentes una o ms extensiones, la versin debe ser la versin 3.
Nmero de seres un valor entero, nico en la CA que emite el certificado, que
est asociado sin ambigedad a este certificado.
Identificador del algoritmo de l a firma: el algoritmo que se emplea para firmar
el certificado junto con parmetros asociados. Debido a que esta informacin se re
pite en el campo Firma al final del certificado, este campo tiene muy poca o nin
guna utilidad.
Nombre del e n o r del certificados el nombre X.509 de la CA que cre y firm
este certificado.
Periodo de validez: consiste en dos fechas: la fecha inicial y la fecha final de va
lidez del certificado.
Nombre del sujetos el nombre del usuario a quien se remite este certificado. Es
decir, este certificado asegura la clave pblica del sujeto que tiene la clave privada
correspondiente.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 113
I d e n ti f i c a d o r
del a l g o r i t m o
d e la f i r m a
Fterodo
de valide z
I n f o r m a c i n de
la clave p blica
del sujet o
Firma
{
V ersin
N m e r o d e serie
del c er tificado
A l g o r i t m o
Parmetros
N o m b r e d e l e m is o r
del c er tificado
No antes
o despus
N o m b r e
del sujet o
Algo ritmos ____
Parmetros
Z Z I .
I d e n t i f i c a d o r n ic o de
e m is o r d e c er tificado
I d e n t i f i c a d o r n ico
del sujet o_______
Extensiones
A j g o r f r m _ o s
Pa/nietros
C i f r a d o
w S
A - c
T o
r f s
I d e n t i f i c a d o r
del
a l g o r i t m o |
de la f i r m a
Certif ica do
revocado \
Cert if ica do
revocado
Rrma
A l g o r i t m o
Parmetros
N o m b r e del e m is o r
del c er tificado
Fecha actualizada
S i g u i e n t e fecha
actualizada
M d e ser i e d e certificado d e usuario
Fecha de revocacin
N.0de ser i e d e certificado de usuario
Fcha d e revocacin
Al go r i tm o s
Parmetros
Cifrado
(b) Lista d e re v o c a c i n
de c e r ti f i cados
(a) C e rt if ic a d o X.509
Figura 4.3 Formatos X.509
Informacin d l a clave pblica d d sujeto: la clave pblica del sujeto y un iden
tificador del algoritmo para el cual se usa esta clave, junto con cualquier parme
tro asociado.
Identificador nico d d emisor d d calificado: un campo opcional de ristras de
bits que se usa para identificar nicamente a la CA que emite el certificado en el
caso de que el nombre del X.500 haya sido reutilizado para distintas entidades.
Mistificador nico de sujeto: un campo opcional de ristras de bits que se usa
para identificar nicamente al sujeto en el caso de que el nombre del X.500 haya
sido reutilizado para distintas entidades.
Extensiones: un grupo de uno o ms campos de extensin. Las extensiones se aa
dieron en la versin 3 y se tratan ms adelante en esta seccin.
Firma: cubre todos los dems campos del certificado; contiene el cdigo hash de
los otros campos, cifrado con la clave privada de la CA. Este campo incluye el
identificador del algoritmo de la firma.
Los campos de identificador nico se aadieron en la versin 2 para tratar la posible reu
tilizacin de los nombres de sujeto y/o emisor de certificado durante ms tiempo, pero
rara vez se usan.
El estndar emplea la siguiente notacin para definir un certificado:
C A A = CA {V, SN, AI, CA, TA, A, Ap}
www.FreeLibros.org
114 Fundamentos de seguridad en redes. Aplicaciones y estndares
Donde
Y X = el certificado del usuario X emitido por la autoridad de certificacin Y
Y {1} = la firma de I por parte de Y. Est formado por I con un cdigo hash cifrado
aadido
La CA firma el certificado con su clave privada. Si la clave pblica correspondiente
es conocida por un usuario, entonces ese usuario puede verificar que un certificado fir
mado por la CA es vlido. Este es el enfoque ms comn de firma digital que se mues
tra en la Figura 3.2 c.
Obtencin de un certificado de usuario
Los certificados de usuario generados por una CA tienen las siguientes caractersticas:
Cualquier usuario con acceso a la clave pblica de la CA puede verificar la clave
pblica del usuario que fue certificada.
Slo la CA puede modificar el certificado sin que esto se detecte.
Debido a que los certificados no son falsificables, pueden colocarse en un directorio sin
que sea necesario tomar medidas especiales de proteccin.
Si todos los usuarios se suscriben a la misma autoridad, entonces hay una confianza
comn en esa CA. Todos los certificados de usuario se pueden situar en el directorio para
el acceso de todos los usuarios. Adems, un usuario puede transmitir su certificado di
rectamente a otros usuarios. En cualquier caso, una vez que B est en posesin del cer
tificado de A, B confa en que los mensajes que cifra con la clave pblica de A estn a
salvo de escuchas y que los mensajes firmados con la clave privada de A no son falsifi
cables.
Si hay una comunidad amplia de usuarios, puede no ser prctico que todos los usua
rios se suscriban a la misma C A. Como es la autoridad la que firma los certificados, cada
usuario participante debe tener una copia de la clave pblica de la autoridad para verifi
car las firmas. Esta clave pblica debe suministrarse a cada usuario de una forma total
mente segura (con respecto a la integridad y la autenticidad) para que el usuario confe
en los certificados asociados. As, con muchos usuarios, sera ms prctico que hubiese
un nmero de autoridades de certificacin, y que cada una de ellas proporcionara de ma
nera segura su clave pblica a una parte de los usuarios.
Ahora supongamos que A ha obtenido un certificado de la autoridad de certificacin
y B ha obtenido un certificado de la autoridad X2. Si A no conoce de forma segura la
clave pblica de X2, entonces el certificado de B, emitido por X2, es intil para A.
A puede leer el certificado de B, pero A no puede verificar la firma. Sin embargo, si las
dos autoridades han intercambiado de forma segura sus propias claves pblicas, el si
guiente procedimiento permitir que A obtenga la clave pblica de B:
L A obtiene del directorio el certificado de X2 firmado por X\. Como A conoce
de forma segura la clave pblica de Ai, A puede obtener la clave pblica de X2
a partir de su certificado y verificarlo por medio de la firma de X\ en el certi
ficado.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 115
2. Luego, A vuelve al directorio y obtiene el certificado de B firmado por X. Como
A tiene ahora una copia confiable de la clave pblica de X2, A puede verificar la
firma y obtener de forma segura la clave pblica de B.
A ha empleado una cadena de certificados para obtener la clave pblica de B. En la no
tacin de X.509, esta cadena se expresa de la siguiente manera:
X\ X X B
De la misma forma, B puede obtener la clave pblica de A con la cadena inversa:
X X\ X A
Este esquema no tiene que limitarse a una cadena de dos certificados. Se puede se
guir una ruta de longitud arbitraria de las autoridades de certificacin para producir una
cadena. Una cadena con jVelementos se expresara as:
X X X2 X ... A j y B
En este caso, cada pareja de CA en la cadena (X, A}+1) debe haber creado certifica
dos para intercambiarlos entre s.
Todos estos certificados de las autoridades de certificacin por parte de las mismas
necesitan aparecer en el directorio, y el usuario necesita conocer cmo estn enlazadas
para seguir una ruta hacia el certificado de clave pblica de otro usuario. El estndar
X.509 sugiere que las CA se organicen de forma jerrquica para facilitar la navegacin.
La Figura 4, extrada de X.509, es un ejemplo de jerarqua. Los crculos conectados
indican la relacin jerrquica entre las CA; las cajas asociadas indican los certificados
mantenidos en el directorio para cada entrada de CA. La entrada del directorio para cada
CA incluye dos tipos de certificados:
Certificadas fem a r certificados de X generados por otras CA.
Certificadas reversa certificados generados por X que son los certificados de
otras CA.
En este ejemplo, el usuario A puede adquirir los siguientes certificados del directorio
para establecer una ruta de certificacin hacia B:
X W W V V Y Y Z Z B
Cuando A ha obtenido estos certificados se puede retroceder en la ruta de certifi
cacin secuencialmente para recuperar una copia confiable de la clave pblica de B.
Usando esta clave pblica, A puede enviar mensajes cifrados a B. Si A desea recibir
mensajes cifrados de B, o firmar mensajes enviados a B, entonces B necesitar la clave
pblica de A, que se puede obtener de la siguiente ruta de certificacin:
Z Y Y V V W W X X A
B puede obtener este grupo de certificados del directorio, o A puede proporcionarlos
como parte de su mensaje inicial a B.
www.FreeLibros.org
116 Fundamentos de seguridad en redes. Aplicaciones y estndares
Figura 4.4 Jerarqua de X.509: un ejemplo hipottico
Revocacin de certificados
Como reflejaba la Figura 4.3, cada certificado incluye un perodo de validez, parecido
al de una tarjeta de crdito. Normalmente, un certificado nuevo se emite justo antes de
la expiracin del anterior. Adems, a veces puede ser preferible revocar un certificado
antes de que expire, por una de las siguientes razones:
L Se sospecha que la clave privada del usuario est comprometida.
2. El usuario ya no est certificado por esa CA.
3 Se sospecha que el certificado de la CA est comprometido.
Cada CA debe mantener una lista de todos los certificados emitidos por ella que han sido
revocados pero que no han expirado, incluidos tanto los emitidos a los usuarios como a
otras autoridades. Estas listas tambin deberan aadirse al directorio.
Cada lista de revocacin de certificados agregada al directorio es firmada por el emi
sor de certificado e incluye (Figura 4.3b) el nombre del emisor, la fecha de creacin de
la lista, la fecha en que se va a emitir la nueva lista y una entrada para cada certificado
revocado. Cada entrada est formada por el nmero de serie de un certificado y la fecha
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentifcacin 117
de revocacin de ese certificado. Como los nmeros de serie son nicos en una CA, el
nmero de serie es suficiente para identificar el certificado.
Cuando un usuario recibe un certificado en un mensaje, el usuario debe determinar
si el certificado ha sido revocado. El usuario podra comprobar el directorio cada vez que
se reciba un certificado. Para evitar los retrasos (y posibles costes) asociados a las bs
quedas en directorios, el usuario puede mantener una cach local de certificados y listas
ae certificados revocados.
PROCEDIMIENTOS DE AUTENTIFCACIN
El X.509 tambin incluye tres procedimientos alternativos de autentifcacin diseados
para su uso en una gran variedad de aplicaciones. Todos estos procedimientos hacen uso
de firmas de clave pblica. Se supone que cada una de las dos partes conoce la clave p
blica de la otra, obteniendo del directorio el certificado de la otra parte o porque el cer
tificado est incluido en el mensaje inicial de cada parte.
1. A { f A rAl I D * sgnData, BKUb[Kab]}
1. A { t A, rA IDb, sgnData, EKUb[Kab]}
La Figura 4.5 ilustra los tres procedimientos.
www.FreeLibros.org
118 Fundamentos de seguridad en redes. Aplicaciones y estndares
Autentificacin unidireccional
La autentificacin unidireccional implica una sola transferencia de informacin desde
un usuario (A) a otro (B), y establece:
L La identidad de A y que el mensaje fue generado por A.
2. Que el mensaje iba dirigido a B.
3L La integridad y la originalidad del mensaje (no se ha enviado varias veces).
Obsrvese que en este proceso slo se verifica la identidad de la entidad iniciadora, no
la de la entidad que responde.
Como mnimo, el mensaje incluye un sello de tiempo ( 4 , un nonce r, y la identidad
de B, y est firmado con la clave privada de A. El sello de tiempo consiste en una fecha
opcional de generacin y una fecha de expiracin. Esto evita retrasos en el envo de
mensajes. El nonce puede usarse para detectar ataques de repeticin. El valor del nonce
debe ser nico en el tiempo de expiracin del mensaje. As, B puede almacenar el non-
ce hasta que expire y rechazar cualquier mensaje nuevo con el mismo nonce.
Para la autentificacin, el mensaje se usa simplemente para presentar credenciales a
B. El mensaje tambin puede incluir informacin que haya que transmitir. Esta infor
macin, sgnData, se incluye en el mbito de esta firma, garantizando su autenticidad e
integridad. El mensaje puede usarse tambin para transportar una clave de sesin a B,
cifrada con la clave pblica de B.
Autentificacin bidireccional
Adems de los tres elementos mencionados, la autentificacin bidireccional establece
los siguientes elementos:
4 La identidad de B y que el mensaje de respuesta fue generado por B.
5l Que el mensaje se cre para A.
& La integridad y la originalidad de la respuesta.
As, la autentificacin bidireccional permite que cada una de las dos partes involucradas
en la comunicacin verifiquen la identidad de la otra.
El mensaje de respuesta incluye un nonce de A para validar la respuesta. Tambin in
cluye un sello de tiempo y un nonce generado por B. Como antes, el mensaje puede incluir
informacin firmada adicional y una clave de sesin cifrada con la clave pblica de A.
Autentificacin tridireccional
En la autentificacin tridireccional se incluye un mensaje final de A a B, que contiene
una copia firmada del nonce /#. El propsito de este diseo es que los sellos de tiempo
no tengan que ser comprobados: como ambos nonces son devueltos por el otro lado,
cada lado puede comprobar el nonce devuelto para detectar ataques de repeticin. Este
enfoque es necesario cuando no se dispone de relojes sincronizados.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 119
LA VERSIN 3 DE X.509
Segn la experiencia actual en diseo e implementacin, el formato de la versin 2 de
X.509 no transmite toda la informacin necesaria. En [FORD95] se presentan los si
guientes requisitos que no satisface la versin 2:
1. El campo Sujeto no es adecuado para transmitir la identidad del propietario de
una clave a un usuario de clave pblica. Los nombres de X.509 podran ser re
lativamente cortos y carecer de datos obvios de identificacin que pueda necesi
tar el usuario.
2. El campo Sujeto tambin es inadecuado para muchas aplicaciones, ya que nor
malmente reconocen entidades mediante una direccin de correo electrnico,
una URL u otro tipo de identificacin relacionada con Internet.
3. Existe la necesidad de indicar informacin sobre la poltica de seguridad. Esto
permite que una aplicacin o funcin de seguridad, como IPSec, relacione un
certificado X.509 con una poltica determinada.
4 Es necesario limitar el dao que pueda resultar de una CA defectuosa o malinten
cionada, imponiendo restricciones a la aplicabilidad de un certificado particular.
5l Es importante poder identificar por separado diferentes claves usadas por el mis
mo propietario en momentos diferentes. Esta caracterstica beneficia la gestin
del ciclo de vida de la clave, particularmente la habilidad de actualizar parejas
de claves para usuarios y autoridades de certificacin de forma regular y en cir
cunstancias excepcionales.
En vez de continuar aadiendo campos a un formato fijo, los desarrolladores de es
tndares pensaron que era necesario un enfoque ms flexible. As, la versin 3 incluye
una serie de extensiones opcionales que se pueden aadir al formato de la versin 2.
Cada extensin est formada por un identificador de extensin, un indicador de riesgo y
un valor de extensin. El indicador de riesgo seala si una extensin se puede ignorar
sin peligro. Si el indicador tiene un valor de TRUE y una implementacin no reconoce
la extensin, debe considerar el certificado como no vlido.
Las extensiones del certificado se dividen en tres categoras: informacin sobre cla
ves y poltica, atributos de sujeto y emisor de certificado y limitaciones en la ruta de cer
tificacin.
INFORMACIN SOBRE CLAVES Y POLTICA
Estas extensiones aportan informacin adicional sobre las claves del sujeto y del emisor,
as como los indicadores de poltica de certificados. Una poltica de certificados es una
serie de normas que indican la aplicabilidad de un certificado a una comunidad particu
lar y/o clase de aplicacin con requisitos comunes de seguridad. Por ejemplo, una pol
tica podra ser aplicable a la autentificacin de transacciones de intercambio de datos
electrnicos (EDI: Electronic Data Interchange) para el comercio de productos en una
escala dada de precios.
Incluye lo siguiente:
Identificador de clave d e autoridad: identifica la clave pblica que ha de usarse
para verificar la firma de ese certificado o la lista de revocacin de certificados.
Permite diferenciar distintas claves de la misma CA. Uno de los usos de este cam
po se halla en la actualizacin de parejas de claves de CA.
www.FreeLibros.org
120 Fundamentos de seguridad en redes. Aplicaciones y estndares
IdoriMfaador d e d a v e d e s u d o : identifica la clave pblica que se est certifican
do. Es til para la actualizacin de parejas de clave de sujeto. Tambin un sujeto
puede tener varias parejas de claves y, por lo tanto, diferentes certificados para di
ferentes propsitos (por ejemplo, firma digital y negociacin de clave de cifrado).
Uso de claves indica la imposicin de una restriccin a los propsitos para los que
se pueda usar la clave pblica certificada y a la poltica que la regula. Puede in
dicar uno o ms de los siguientes: firma digital, no repudio, cifrado de clave, ci
frado de datos, acuerdo de clave, verificacin de firma de CA en los certificados,
verificacin de firma de CA en la lista de revocacin de certificados.
Periodo de uso d l a dave privada: indica el perodo de uso de la clave privada
correspondiente a la clave pblica. Normalmente, la clave privada se usa durante
un perodo diferente de la validez de la clave pblica. Por ejemplo, con claves de
firma digital, el perodo de uso para la clave privada de firma es generalmente me
nor que para la clave pblica de verificacin.
Polticas de certificados: los certificados pueden usarse en entornos donde se apli
quen diversas polticas. Esta extensin presenta las polticas que el certificado ad
mite, junto con informacin opcional del calificador.
Correspondencias de polticas: se usa slo en certificados para CA emitidos por
otras CA. Permiten que una CA que emite indique que una o ms polticas de ese
emisor de certificado se puedan considerar equivalentes a otra poltica usada en el
dominio de CA del sujeto.
Sujeto de certificado y atributos de emisor de certificado
Estas extensiones permiten nombres alternativos en formatos alternativos para un suje
to de certificado o emisor de certificado, y pueden aportar informacin adicional sobre
ste, para convencer al usuario de un certificado de que el sujeto del certificado es una
persona o entidad particular. Por ejemplo, se puede necesitar informacin como la di
reccin postal, el puesto en una empresa o una foto.
Los campos de extensin en esta rea incluyen:
Nombre alternativo de sujeta contiene uno o ms nombres alternativos, usando
cualquiera de una variedad de formas. Este campo es importante para ciertas apli
caciones, como correo electrnico, EDI e IPSec, que pueden emplear sus propias
formas de nombre.
Nombre alternativo de anisar: contiene uno o ms nombres alternativos, usando
cualquiera de una variedad de formas.
Atributos de directorio de sujeto: aporta cualquier valor deseado de atributo del
directorio X.500 para el sujeto de este certificado.
Limitaciones en la ruta de certificacin
Estas extensiones permiten incluir especificaciones sobre limitaciones en los certifica
dos emitidos por autoridades de certificacin a otras. Las limitaciones pueden restringir
los tipos de certificados que puede emitir la CA del sujeto o que puedan producirse pos
teriormente en una cadena de certificacin.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentifcacin 121
Los campos de extensiones que se incluyen son:
Limitaciones bsicas indica s el sujeto puede actuar como una CA. De ser as,
se podra especificar una limitacin en la longitud de la ruta de certificacin.
Lnmtariones de nombre: indica un espacio para nombre en el que deben colo
carse todos los nombres del sujeto en certificados siguientes.
Limitaciones d e poltica: especifica las limitaciones que pueden requerir identifi
cacin explcita de poltica de certificado o impedir la correspondencia de polti
cas para el resto de la ruta de certificacin.
4 . 3 BIBLIOGRAFA Y SITIOS WEB RECOMENDADOS
[BRYA88] ayuda a entender los conceptos de Kerberos de forma sencilla. Uno de los
mejores tratamientos de Kerberos se encuentra en [KOHL94]. [TUNG99] describe Ker
beros desde el punto de vista del usuario.
BRYA88 Bryant, W. Designing an Authentication System: A Dialogue in Four
Scenes. Project Athena document, February 1988. Disponible en
http://web.mit.edu/kerberos/www/dialogue.html.
K0HLS1 Kohl, J.; Neuman, B.; andTso, T. The Evolution of the Kerberos Au
thentication Service. In Brazier, F., and Johansen, D. Distributed Open
Systems. Los Alamitos, CA: IEEE Computer Society Press, 1994. Dis
ponible en http://web.mit.edu/kerberos/www/papers.html
TUNG9B Tung, B. Kerberos: A Network Authentication System. Reading, MA:
Addison-Wesley, 1999.
Sitios web recomendados:
MTT Kerberos S it e informacin sobre Kerberos que incluye FAQ, artculos, do
cumentos y enlaces a sitios de productos comerciales.
U S C / I S I Keifaros Page: otra buena fuente con material sobre Kerberos.
PubBcKey I n f r a r t r a r t u r e YVoridng Group: grupo de la IETF que desarrolla es
tndares basados en X.509v3.
Verisigji: vendedor lder de productos relacionados con X.509; en este sitio se en
cuentran documentos y material valioso.
4 . 4 TRMINOS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
TERMINOS CLAVE
Autentifcacin
certificado de clave pblica
certificado X.509
dominio
Dominio de Kerberos
Kerberos
modo PCBC
nonce
nmero de secuencia
Servidor de autentifcacin
subclave
TGS (Kcket-GrantngServer)
ticket
tiempo de vida
www.FreeLibros.org
122 Fundamentos de seguridad en redes. Aplicaciones y estndares
PREGUNTAS DE REPASO
4 1 . Kerberos se dise para resolver un problema cul?
4 2 . Cules son las tres amenazas asociadas a la autentificacin de usuario en una
red o en Internet?
4 3 Enumera los tres enfoques que aseguran la autentificacin de usuario en un
entorno distribuido.
4 4 Qu cuatro requisitos se definieron para Kerberos?
4 5 . Qu entidades constituyen un entorno de servicio completo de Kerberos?
4 6 En el contexto de Kerberos, qu es un dominio?
4 7 . Cules son las diferencias principales entre la versin 4 y la versin 5 de
Kerberos?
4 6 Cul es la finalidad del estndar X.509?
4 6 Qu es una cadena de certificados?
4 1 6 Cmo se revoca un certificado X.509?
PROBLEMAS
4 1 . Demuestra que un error aleatorio en un bloque de texto cifrado se propaga a
todos los bloques siguientes en el modo PCBC (Figura 4.7).
42. Imagina que, en el modo PCBC, los bloques Ci y Cil 1 se intercambian durante
la transmisin. Demuestra que esto afecta slo a los bloques descifrados Pi y
Pi 11 pero no a los bloques siguientes.
4 3 El procedimiento original de autentificacin tridireccional para X.509 que se
ilustra en la Figura 4.5c tiene un fallo en la seguridad. La base del protocolo
es la siguiente:
A - B : A {tA, rA, ID$
B A: B { tB, rB, IDA, rA}
A- > B: A {rB)
El texto de X509 afirma que comprobar los sellos de tiempo tA y tBes opcional
para la autentificacin tridireccional. Pero considera el siguiente ejemplo: ima
gina que A y i? han utilizado en ocasiones anteriores el protocolo mencionado, y
un oponente C ha interceptado los tres mensajes anteriores. Adems, imagina
que los sellos de tiempo no se usan y estn fijados a 0. Por ltimo, imagina tam
bin que C quiere suplantar a A ante B. Inicialmente, C enva el primer mensaje
capturado a B:
C - B: A{0, rA, ID
B responde a C creyendo que se comunica con A:
B -> C: {0, r B, IDA, rA}
Mientras tanto Chace que A inicie la autentificacin con C. Como resultado,
A enva a Co siguiente:
A- > B: A{0, r A, 1DC}
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 123
C responde a A usando el mismo nonce que B le proporcion.
C- A: C{0, r B, A, r A}
A responde con
A- > C: A{ r B}
Esto es exactamente lo que C necesita para convencer a B de que est hablan
do con A, por lo que C ahora reenva el mensaje entrante a B.
C - >B: A {r'B}
As, B creer que est hablando con A cuando realmente lo hace con C. Pre
senta una solucin simple a este problema que no implique el uso de sellos de
tiempo.
4 4 La versin del X.509 de 1988 enumera las propiedades que las claves RSA de
ben poseer para ser seguras, conociendo la dificultad que plantea factorizar n
meros grandes. La discusin concluye con una limitacin en el exponente p
blico y el mdulo n:
Debe asegurarse que e >log2(/?) para prevenir un ataque tomando la e-sima
raz mod n para revelar un texto claro.
Aunaue la limitacin es correcta, la razn por la que se pide es incorrecta.
Cul es el error en la razn dada y cul es la razn correcta?
APNDICE 4 A TCNICAS DE CIFRADO KERBEROS
Kerberos incluye una librera de cifrado que permite diferentes operaciones relaciona
das con el cifrado.
TRANSFORMACIN DE CONTRASEA A CLAVE
En Kerberos, las contraseas se limitan al uso de caracteres que pueden representarse en
un formato ASCII de 7 bits. Esta contrasea, de longitud arbitraria, se convierte en una
clave de cifrado que se almacena en la base de datos de Kerberos. La Figura 4.6 ilustra
el procedimiento.
En primer lugar, la ristra de caracteres, s, se empaqueta en una ristra de bits, b, de
forma que el primer carcter se almacena en los primeros siete bits, el segundo carcter
en los segundos siete bits, y as sucesivamente. Se puede expresar como sigue:
Z>[0] = bit 0 de s[0]
Z?[6] = bit 6 de s[0]
b[7] = bit 0 de s\ 1]
b[7i -h 777] = bit 77?de s[i] 0 ^ m <>6
www.FreeLibros.org
124 Fundamentos de seguridad en redes. Aplicaciones y estndares
1 c a r c t e r
Cont rase a en SI I ^ ---------- *
ASCII d e 7 b i t s
(/? caracteres)
Ristra c o n ti n u a
de b i t s ( 7 x n bits)
(a) C o n v i e r t e con t rase a en r i s t r a d e b i t s
- - -
u V u V u V
I...I ... ...

m u
Desdoble
en secciones
de 56 bits
XOR bit a bit
Clave
d e 64 b i t s
(b) C o n v i e r te r i s t r a d e b i t s en contrasea
s[8] a s[15] s [ n - 8 ] a s [ n - 1]
Clave d e salida
Kc
(c) Genera suma d e p r u e b a d e la con t rase a u s a ndo el m o d o CBC del DES
Figura 4.6 Generacin de clave de cifrado a partir de contrasea
Luego, la ristra de bits se compacta a 56 bits alineando los bits desdoblando en secciones
y realizando un XOR bit a bit. Por ejemplo, si la ristra de bits es de longitud 59, entonces
b[55] = b[55] b [56]
b[54] = b[54] b [57]
b[53] = b[53] 0 b [58]
Esto crea una clave DES de 56 bits. Para ajustarse al formato de clave esperado de
64 bits, la ristra se trata como una secuencia de ocho bloques de siete bits y se mapea en
ocho bloques de ocho bits para formar una clave de entrada Kpw
Por ltimo, la contrasea original se cifra usando el modo CBC del DES con la cla
ve Kpw. El ltimo bloque de 64 bits que se origina de este proceso, conocido como la
suma de prueba del CBC, es la clave de salida asociada a esta contrasea.
www.FreeLibros.org
Captulo 4 / Aplicaciones de autentificacin 125
El algoritmo completo se puede ver como una funcin hash que mapea una contra
sea arbitraria con un cdigo hash de 64 bits.
PROPAGACIN DEL MODO PCBC ( CIPHER BLOCK CHAINING)
Recordemos del Captulo 2 que, en el modo CBC del DES, la entrada al algoritmo DES
en cada fase consiste en el XOR del bloque actual de texto claro y el bloque de texto ci
frado anterior, usando la misma clave para cada bloque (Figura 3.12). La ventaja de este
modo con respecto al modo ECB, en el que cada bloque de texto claro se cifra indepen
dientemente, es la siguiente: con el CBC, el mismo bloque de texto claro, si se repite,
produce diferentes bloques de texto cifrado.
El CBC tiene la propiedad de que si se produce un error en la transmisin del bloque
de texto cifrado C, entonces este error se propaga a los bloques de texto claro recupe
rados P y Pj+\.
La versin 4 de Kerberos usa una extensin del CBC, denominada modo PCBC
[MEYE82]. Este modo tiene la propiedad de que un error en un bloque de texto ci
frado se propaga a todos los bloques descifrados siguientes del mensaje, inutilizando
cada bloque. As, el cifrado y la integridad de los datos se combinan en una sola ope
racin.
Ti empo = 1
Tiempo = 2
Pn -
C/v_-
Tiempo = N
Pn
DES
cifrar
CN
(a) Cifrado
IV
(b) Descifrado
Figura 4.7 Modo PCBC
www.FreeLibros.org
126 Fundamentos de seguridad en redes. Aplicaciones y estndares
El PCBC se ilustra en la Figura 4.7. En este esquema, la entrada al algoritmo de ci
frado es el XOR del bloque actual de texto claro, el bloque anterior de texto cifrado y el
bloque anterior de texto claro:
Cn = ECn- 1 Pn- 1
En el descifrado, cada bloque de texto cifrado pasa por el algoritmo de descifrado.
Entonces a la salida se le aplica el XOR con el bloque anterior de texto cifrado y el blo
que anterior de texto claro. Se puede demostrar de la siguiente forma que este esquema
funciona:
A r f C J = DK[EfCn_ j Pn_ i 0 Pn]\
Cn- i Pn - XD Cn]=Pn
www.FreeLibros.org
C A P T U L O 5
Seguridad en el correo
electrnico
5.1 Pretty Good Privacy
N o t a c i n
D e s c r i p c i n o p e r a t i v a
C l a v e s c r i p t o g r f i c a s y f i c h e r o s d e c l a v e s
G e s t i n d e c l a v e p b l i c a
5.2 S / M I M E
R F C 8 2 2
M I M E ( M u l t i p u r p o s e I n t e r n e t M a i l E x t e n s i o n s )
F u n c i o n a l i d a d S / M I M E
M e n s a j e s S / M I M E
P r o c e s a m i e n t o d e c e r t i f i c a d o s S / M I M E
S e r v i c i o s d e s e g u r i d a d a v a n z a d a
5.3 Sitios w e b recomendados
5.4 Trminos clave, preguntas de repaso y problemas
T r m i n o s c l a v e
P r e g u n t a s d e r e p a s o
P r o b l e m a s
Apndice 5A Compresin de datos usando Zip
A l g o r i t m o d e c o m p r e s i n
A l g o r i t m o d e d e s c o m p r e s i n
Apndice 5B Conversin RADIX 64
Apndice 5C Generacin de nmeros aleatorios de PGP
N m e r o s a l e a t o r i o s
N m e r o s p s e u d o a l e a t o r i o s
www.FreeLibros.org
128 Fundamentos de seguridad en redes. Aplicaciones y estndares
A pesar de la negativa de VADM Poindexter y LtCol North a estar presentes, el acceso
de la Cmara a otras fuentes de informacin cubri gran parte de este vaco. El FBf
aport documentos extrados de los archivos del Asesor de Seguridad Nacional y miem
bros importantes del personal de NSC, incluyendo los mensajes del sistema PROF entre
VADM Poindexter y LtCol North Los mensajes de PROF eran conversaciones por com
putador, escritos en el momento en que ocurran los acontecimientos y como crean sus
autores, protegidos de ser revelados. En este sentido, proporcionaron un informe de los
hechos actual y de primera mano.
El informe d e la Comisin Tower
al predoite Reagan sobre el caso Irn-contra, 1987
Bless the man who made it,
And pray that he ain t dead
He couldve made a millon
Ifh e d sold t to the feds,
But he was hot for freedom;
He ga ve t out for free.
Now every common Citizen s got PGP1
D e l a c a n d n P.G.P. de L es l ie F ish
E
n casi todos los entornos distribuidos, el correo electrnico es la aplicacin de red
ms usada. Tambin es la nica aplicacin distribuida que se utiliza en todas las
arquitecturas y plataformas. Los usuarios esperan poder enviar correo, y de hecho
lo hacen, a otros que se encuentren conectados directa o indirectamente a Internet, inde
pendientemente del sistema operativo del host y de la suite de comunicaciones.
A medida que aumenta nuestra dependencia del correo electrnico con cualquier
finalidad imaginable, aumenta tambin la demanda de servicios de autentificacin y
confidencialidad. Los dos esquemas que se analizan en este Captulo son PGP (Pretty
Good Prvacfi y S/MIME, que constituyen los dos enfoques de uso ms extendido.
PRETTY GOOD PRIVACY
PGP es un fenmeno singular y el resultado del esfuerzo, en gran parte, de un sola per
sona, Phil Zimmermann. PGP proporciona un servicio de confidencialidad y de autenti
ficacin que se puede usar para correo electrnico y aplicaciones de almacenamiento de
ficheros. Bsicamente, Zimmermann ha hecho lo siguiente:
1 Bendice a quien lo cre / y reza porque an viva /un milln pudo hacer/y a los federales vender/pero
tena ansias de libertad/y lo dio por nada a cambio/ahora cualquier hombre de a pie tiene PGP.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 129
1. Seleccionar, como base, los mejores algoritmos criptogrficos existentes.
2. Integrar estos algoritmos en una aplicacin de propsito general independiente
del sistema operativo y del procesador, y que se basa en un grupo reducido de
comandos fciles de usar.
3. Ofrecer gratuitamente el paquete y su documentacin, incluido el cdigo fuen
te, por medio de Internet, tablones de anuncios y redes comerciales como la AOL
(America onLine).
4 Llegar a un acuerdo con una compaa (Viacrypt, ahora Network Associates)
para proporcionar una versin comercial de PGP totalmente compatible y de
bajo coste.
PGP ha crecido rpidamente y est muy extendido, lo cual se debe a las siguientes ra
zones:
1. Est disponible de forma gratuita en versiones que se ejecutan en una gran varie
dad de plataformas, incluidas Windows, UNIX, Macintosh y muchas ms. Ade
ms, la versin comercial satisface a los usuarios que quieren un producto con
asistencia del fabricante.
2. Se basa en algoritmos que han sobrevivido a revisiones exhaustivas y se consi
deran sumamente seguros. Concretamente, el paquete incluye RSA, DSS y
Diffie-Hellman para cifrado de clave pblica; CAST-128, IDEA y 3DES para
cifrado simtrico; y SHA-1 para codificacin hash
3. Tiene un amplio mbito de aplicabilidad, desde corporaciones que desean selec
cionar y reforzar un esquema normalizado para cifrar archivos y mensajes, has
ta particulares que desean comunicarse de forma segura con usuarios de todo el
mundo por medio de Internet y otras redes de computadores.
4 No fue desarrollado por ninguna organizacin gubernamental o de estndares, ni
lo controlan en la actualidad. Esto hace que PGP sea atractivo para aquellas per
sonas que desconfan instintivamente del sistema.
5l En la actualidad, PGP est propuesto como estndar de Internet (RFC 3156). Sin
embargo, todava lo rodea un aura de resistencia a lo establecido.
Empezaremos ofreciendo una visin general del funcionamiento de PGP. Luego, exa
minaremos la forma en que se crean y se almacenan las claves criptogrficas, para pasar
a continuacin al aspecto fundamental relativo a la gestin de claves pblicas.
NOTACIN
La mayor parte de la notacin que se emplea en este Captulo se ha usado anteriormen
te, pero se introducen algunos trminos nuevos. Lo mejor ser resumirlos al principio.
Se usan los siguientes smbolos:
Ks = clave de sesin usada en el esquema de cifrado simtrico
KRa = clave privada del usuario A, utilizada en el esquema de cifrado de clave pblica
KUa = clave pblica del usuario A, empleada en el esquema de cifrado de clave pblica
EP = cifrado de clave pblica
www.FreeLibros.org
130 Fundamentos de seguridad en redes. Aplicaciones y estndares
DP = descifrado de clave pblica
EC = cifrado simtrico
DC = descifrado simtrico
H = funcin hash
|| = concatenacin
Z = compresin usando el algoritmo ZIP
R64 = conversin al formato ASCII radix 64
La documentacin de PGP usa con frecuencia el trmino clave secreta para referir
se a una clave emparejada con una clave pblica en un esquema de cifrado de esta cla
ve. Como se apunt con anterioridad, este hecho puede llevar a confusin con la clave
secreta que se utiliza en el cifrado simtrico. Por este motivo, en este libro se emplea el
trmino clave privada.
DESCRIPCIN OPERATIVA
La operacin real de PGP, al contrario que la gestin de claves, consiste en cinco servi
cios: autentificacin, confidencialidad, compresin, compatibilidad con correo electr
nico y segmentacin (Tabla 5.1). Examinemos cada uno de ellos.
Autentificacin
La Figura 5. l a ilustra el servicio de firma digital suministrado por PGP. Este es el esque
ma de firma digital que se estudi en el Captulo 3 y se mostr en la Figura 3.2c. La
secuencia es la siguiente:
L El emisor crea un mensaje.
2. Se usa SHA-1 para generar un cdigo hash del mensaje de 160 bits.
3 El cdigo hash se cifra con RSA usando la clave privada del emisor y el resul
tado se aade antepuesto al mensaje.
4 El receptor usa RSA con la clave pblica del emisor par descifrar y recuperar el
cdigo hash
5l El receptor genera un nuevo cdigo hash para el mensaje y lo compara con el
cdigo hash descifrado. Si los dos coinciden, el mensaje se considera autntico
y se acepta.
La combinacin de SHA-1 y RSA ofrece un esquema eficaz de firma digital. Por una
parte, debido a la robustez del RSA, el receptor est seguro de que slo el poseedor de
la clave privada correspondiente puede generar la firma; por otra, debido a la robustez
de SHA-1, el receptor est seguro de que nadie ms puede generar un nuevo mensaje
que coincida con el cdigo hash y, por lo tanto, con la firma del mensaje original.
Una alternativa para la generacin de firmas podra ser el uso de DSS/SHA-1.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 131
Tabla 5.1 Resumen de los servicios de PGP
Funcin A l g o r i t m o s u s a d o s Desc ri p ci n
Fi r m a d i g i t a l
D S S / S H A
o R S A / S H A
S e cr ea u n c d i g o ha s h d e u n m e n s a j e
u s a n d o S HA- 1 . El r e s u m e n d e l m e n s a
j e s e c i f r a u s a n d o D S S o R S A co n la
c l a v e p r i v a d a de l e m i s o r , y s e i n c l u y e
e n e l m e n s a j e .
C i f r a d o d e m e n s a j e
CAST o I D E A
o
T r i p l e D E S d e tr e s
c l a v e s
con
D i f f i e - H e l l m a n
o R S A
S e ci f ra u n m e n s a j e u s a n d o C A S T -1 2 8 ,
I D E A o 3 D E S co n u n a c l a v e d e se si n
d e u n s o l o us o g e n e r a d a p o r el e m i
sor. La c l a v e d e s e s i n se c i f r a u s a n d o
D i f f i e - H e l l m a n o R S A co n l a c l a v e
p b l i c a de l r e c e p t o r , y se i n c l u y e e n el
m e n s a j e .
C o m p r e s i n Z I P
U n m e n s a j e s e p u e d e c o m p r i m i r u s a n
d o Z I P p a r a s u a l m a c e n a m i e n t o o
t r a n s m i s i n .
C o m p a t i b i l i d a d con
corr eo e l e c t r n i c o
C o n v e r s i n
r a d i x 6 4
Para p r o p o r c i o n a r t r a n s p a r e n c i a pa ra
las a p l ic a c i on e s d e c o r r e o e le c tr n i c o ,
un m e n s a j e c i f ra do s e p u e d e conve rt i r
en u n a ristra A S CI I u s a n d o c o nve rs i n
r a d i x 64.
S e g m e n t a c i n
P ar a a j u s t a r s e a l a s l i m i t a c i o n e s de
t a m a o d e m e n s a j e , P GP r e a l i z a la
s e g m e n t a c i n y el r e e n s a m b l a d o .
Aunque las firmas se encuentran normalmente adjuntas al mensaje o el fichero que
firman, no siempre es as: tambin pueden encontrase separadas. Una firma puede alma
cenarse y transmitirse separada del mensaje que firma, lo cual es til en varios contex
tos. Un usuario podra desear mantener un fichero de seguimiento (lof con las firmas
separadas de todos los mensajes enviados y recibidos. Adems, una firma separada de
un programa ejecutable puede detectar un virus. Por ltimo, las firmas separadas se pue
den usar cuando ms de una parte debe firmar un documento, como ocurre, por ejem
plo, en un contrato legal. La firma de cada persona es independiente y, por lo tanto, se
aplica slo al documento. De no ser as, las firmas tendran que anidarse, con lo cual el
segundo firmante firma el documento y la primera firma, y as sucesivamente.
CONFIDENCIALIDAD
Otro servicio bsico que proporciona PGP es la confidencialidad, lo cual se consigue
cifrando los mensajes que van a transmitirse o a almacenarse localmente como ficheros.
En ambos casos se puede usar el algoritmo de cifrado simtrico CAST-128 y, como
alternativa, IDEA o 3DES, utilizando siempre el modo CFB de 64 bits.
www.FreeLibros.org
1 3 2 Fundamentos de seguridad en redes. Aplicaciones y estndares
Origen A-
KRa
M
EP
d >
EkrsIHM) i
Destino B-
KUa
------------
M
(a) Slo autentificacin
M
Ks
i
BKUb\Ks\

Comparacin
j
- ( c ) ( I
(b) Slo confidencialidad
KRt
EiajKsl
M
KRa
KRb EKRa[ H (M )]
I
* s ! EP
EP) - ( i j ) - * - [ ^ ) | | C ] ( ! I
(c) Confidencialidad y autentificacin
Figura 5 . 1 F u n c i o n e s c r i p t o g r f i c a s d e PGP
M
Compa
racin
[H p
Como es habitual, se debe afrontar el problema de la distribucin de claves. En PGP,
cada clave simtrica se usa una sola vez. Es decir, una nueva clave se genera como un
nmero aleatorio de 128 bits para cada mensaje. As, aunque a sta se le conoce en la
documentacin como clave de sesin, en realidad se trata de una clave de un solo uso.
Como ha de usarse una sola vez, la clave de sesin se aade al mensaje y se transmite
con l. Para proteger la clave, se cifra con la clave pblica del receptor. La Figura 5.1b
muestra la secuencia, que se puede describir de la siguiente manera:
L El emisor genera un mensaje y un nmero aleatorio de 128 bits para usarlo como
clave de sesin slo para este mensaje.
2 . El mensaje se cifra, usando CAST-128 (o IDEA o 3DES) con la clave de sesin.
3 La clave de sesin se cifra con RSA, usando la clave pblica del receptor, y se
aade antepuesta al mensaje.
4 El receptor usa RSA con su clave privada para descifrar y recuperar la clave de
sesin.
& La clave de sesin se usa para descifrar el mensaje.
Como alternativa al uso de RSA para el cifrado de la clave, PGP proporciona la opcin
conocida como Diffie-Hellman. Tal y como se explic en el Captulo 3, Diffie-Hellman
es un algoritmo de intercambio de claves. De hecho, PGP usa una variante de Diffie-
Hellman que proporciona cifrado/descifrado, conocido como ElGamal.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 133
Se pueden hacer algunas observaciones al respecto. En primer lugar, para reducir el
tiempo de cifrado es preferible usar la combinacin de cifrado simtrico y de clave
pblica que usar simplemente RSA o ElGamal para cifrar el mensaje directamente:
CAST-128 y los dems algoritmos simtricos son sensiblemente ms rpidos que RSA
o ElGamal. Por otra parte, el uso del algoritmo de clave pblica resuelve el problema de
la distribucin de las claves de sesin, porque slo el receptor puede recuperar la clave
de sesin que va unida al mensaje. Cada mensaje consiste en un elemento nico e inde
pendiente con su propia clave. Adems, dado que el correo electrnico se almacena y se
reenva, no son prcticas las negociaciones para garantizar que las dos partes que se
comunican tienen la misma clave de sesin. Por ltimo, el empleo de claves simtricas
de un solo uso refuerza lo que ya es un enfoque robusto de cifrado simtrico. Slo se
cifra una pequea cantidad de texto claro con cada clave y no existe relacin entre las
claves. As, hasta donde el algoritmo de clave pblica es seguro, el esquema total es
seguro. Con este fin, PGP proporciona al usuario una gama de opciones de tamao de
clave, desde 768 hasta 3072 bits (la clave DSS para firmas se limita a 1024 bits).
CONFIDENCIALIDAD Y AUTENTIFCACIN
Como muestra la Figura 5.1c, ambos servicios se pueden usar para el mismo mensaje.
Primero, se genera una firma para el mensaje en texto claro y se adjunta antepuesta a
dicho mensaje. Luego, se cifra el mensaje en texto claro y la firma usando CAST-128 (o
DEA o 3DES), y la clave de sesin se cifra usando RSA (o ElGamal). Esta secuencia
es preferible a la secuencia inversa, que consistira en cifrar el mensaje y luego generar
una firma para el mensaje cifrado. Generalmente, es ms conveniente almacenar una fir
ma con una versin en texto claro del mensaje. Adems, para la verificacin de la ter
cera parte, si la firma se lleva a cabo en primer lugar, la tercera parte no necesita ocu
parse de la clave simtrica al verificar la firma.
En resumen, cuando se usan los dos servicios, primero el emisor firma el mensaje
con su propia clave privada, luego cifra el mensaje con una clave de sesin y a conti
nuacin cifra la clave de sesin con la clave pblica del receptor.
COMPRESIN
De forma predeterminada, PGP comprime el mensaje despus de aplicar la firma, pero
antes del cifrado. Esto tiene la ventaja de ahorrar espacio tanto para la transmisin de
correo electrnico como para el almacenamiento de ficheros.
La ubicacin del algoritmo de compresin, indicado en la Figura 5.1 con Z para com
presin y Z_I para descompresin, es crtica:
1. La firma se genera antes de la compresin debido a dos razones fundamentales:
a) Es preferible firmar un mensaje descomprimido para poder almacenar sola
mente el mensaje descomprimido junto con la firma para su verificacin
posterior. S se firma un documento comprimido, sera necesario almacenar
una versin comprimida del mensaje para su posterior verificacin o volver
a comprimir el mensaje cuando se requiera verificacin.
www.FreeLibros.org
134 Fundamentos de seguridad en redes. Aplicaciones y estndares
b) Incluso si se estuviese dispuesto a generar de forma dinmica un mensaje
que se ha vuelto a comprimir para su verificacin, el algoritmo de compre
sin de PGP presenta una dificultad. El algoritmo no es determinista; dis
tintas implementaciones del algoritmo permiten diferentes compromisos
entre la velocidad de ejecucin y el ratio de compresin y, como resultado,
producen distintas formas comprimidas. Sin embargo, los distintos algorit
mos de compresin pueden operar entre s, ya que cualquier versin del
algoritmo puede descomprimir correctamente la salida ae cualquier otra
versin. Aplicar la fxincin hash y la firma despus de la compresin res
tringira todas las implementaciones de PGP a la misma versin del algo
ritmo de compresin.
2. El cifrado del mensaje se aplica despus de la compresin para reforzar la segu
ridad criptogrfica. Como el mensaje comprimido tiene menos redundancia que
el texto claro original, el criptoanisis presenta ms dificultades.
El algoritmo de compresin que se utiliza es ZIP, que se describe en el Apndi
ce 5a.
COMPATIBILIDAD CON CORREO ELECTRNICO
Cuando se usa PGP, se cifra al menos una parte del bloque que se va a transmitir. Si slo
se usa el servicio de firma, se cifra el resumen del mensaje (con la clave privada del emi
sor). Si se usa el servicio de confidencialidad, se cifran (con una clave simtrica de un
solo uso) el mensaje y la firma (si estuviese presente). Por consiguiente, parte del blo
que resultante consiste en una ristra de octetos arbitrarios de ocho bits. Sin embargo,
muchos sistemas de correo electrnico slo permiten el uso de bloques de texto ASCII.
Para ajustarse a esta restriccin, PGP proporciona el servicio de convertir la ristra bina
ria de ocho bits en una ristra de caracteres ASCII imprimibles.
El esquema que se usa para ello es la conversin radix 64. A partir de cada grupo de
tres octetos de datos binarios se obtienen cuatro caracteres ASCII. Este formato tambin
aade un CRC para detectar errores de transmisin. El Apndice 5B ofrece la descripcin.
El uso de radix 64 expande un mensaje un 33%. Afortunadamente, las partes del
mensaje correspondientes a la clave de sesin y a la firma son relativamente compactas,
y el mensaje en texto claro ha sido comprimido. De hecho, la compresin debera ser
ms que suficiente para compensar la expansin de radix 64. Por ejemplo, en [HELD96]
se presenta un promedio del ratio de compresin de 2.0 usando ZIP. Si ignoramos los
componentes relativamente pequeos de la firma y la clave, el efecto global habitual de
la compresin y la expansin de un archivo de longitud A'sera 1.33 x 0.5 x X= 0.665
x X As, todava hay una compresin general de un tercio aproximadamente.
Un aspecto destacable del algoritmo radix 64 es que convierte la ristra de entrada a
formato radix 64 independientemente del contenido, incluso si la entrada es texto ASCII.
Por consiguiente, si un mensaje est firmado, pero no cifrado, y la conversin se aplica
al bloque completo, la salida ser ilegible al observador casual, lo cual proporciona un
cierto grado de confidencialidad. De manera opcional, PGP puede configurarse para
convertir a formato radix 64 slo la parte de la firma de los mensajes firmados en texto
claro. Esto permite que el receptor humano lea el mensaje sin usar PGP. Sin embargo,
an tendra que usarse PGP para verificar la firma.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 135
La Figura 5.2 muestra la relacin entre los cuatro servicios tratados hasta ahora. En
la transmisin, si es necesario, se genera una firma usando un cdigo hash del texto cla
ro descomprimido. Luego se comprime el texto claro y, si est presente, tambin la fir
ma. A continuacin, si se necesita confidencialidad, se cifra el bloque (texto claro com
primido o firma comprimida ms texto claro) y se aade antepuesto con la clave de
cifrado simtrico cifrada con clave pblica. Por ltimo, el bloque completo se convierte
a formato radix 64.
En la recepcin, el bloque que se recibe se convierte de formato radix 64 nuevamen
te a binario. Luego, si el mensaje est cifrado, el receptor recupera la clave de sesin y
descifra el mensaje. El bloque resultante, luego, se descomprime. Si el mensaje est fir
mado, el receptor recupera el cdigo hash transmitido y lo compara con su propio cl
culo del cdigo hash
SEGMENTACIN Y REENSAMBLADO
Las herramientas de correo electrnico se limitan con frecuencia a una longitud mxi
ma de mensaje. Por ejemplo, muchas de las herramientas accesibles a travs de Internet
imponen una longitud mxima de 50.000 octetos. Cualquier mensaje mayor debe sub-
dividirse en segmentos ms reducidos, cada uno de los cuales se enva por separado.
Para ajustarse a esta restriccin, PGP subdivide automticamente los mensajes dema
siado largos en segmentos lo suficientemente cortos para ser enviados por correo elec
trnico. La segmentacin se lleva a cabo despus de todo el procesamiento, incluida la
conversin de radix 64. Por lo tanto, el componente clave de sesin y el componente fir
ma aparecen una sola vez, al principio del primer segmento. En el extremo receptor,
PGP debe retirar todas las cabeceras del correo electrnico y reensamblar el bloque ori
ginal completo antes de realizar los pasos que se muestran en la Figura 5.2b.
CLAVES CRIPTOGRFICAS Y FICHEROS DE CLAVES
PGP hace uso de cuatro tipos de claves: claves simtricas de sesin de un solo uso, cla
ves pblicas, claves privadas y claves simtricas basadas en frases clave (que se expli
carn ms adelante). Con respecto a estas claves, se pueden identificar tres requisitos:
1. Se necesita un medio para la generacin imprevisible de claves de sesin.
2. Nos gustara permitir que un usuario tenga mltiples parejas de clave pblica/cla
ve privada. El motivo de esto es que el usuario podra querer cambiar su pareja de
claves de vez en cuando. Cuando esto ocurre, cualquier mensaje en proceso se
crear con una clave obsoleta. Adems, los receptores slo conocern la clave
pblica antigua hasta recibir una actualizacin. Aparte de la necesidad de cambiar
las claves de vez en cuando, un usuario podra querer tener mltiples parejas de
claves en un momento dado para interactuar con diferentes grupos de interlocu
tores o simplemente para mejorar la seguridad limitando la cantidad de material
cifrado con una de las claves. El resultado de todo esto es que no hay una corres
pondencia de uno a uno entre los usuarios y sus claves pblicas. Por lo tanto, se
necesita algn medio para identificar claves particulares.
www.FreeLibros.org
X
<
-

f
i
c
h
e
r
o

C
o
n
v
e
r
t
i
r

d
e

r
a
d
i
x

6
4
X
<
-

R
6
4
'
1
[
X
]
136 Fundamentos de seguridad en redes. Aplicaciones y estndares
s
i
x 2
1 5
s
IJ*
S*
r-
<3
F
i
g
u
r
a

5
.
2

T
r
a
n
s
m
i
s
i

n

y
r
e
c
e
p
c
i

n

d
e

m
e
n
s
a
j
e
s

P
G
P
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 137
3. Cada entidad PGP debe mantener un archivo con sus propias parejas de claves y
otro con las claves pblicas de los interlocutores.
Examinemos cada uno de estos requisitos.
GENERACIN DE CLAVES DE SESIN
Cada clave de sesin est asociada a un solo mensaje y se usa slo con el fin de cifrar y
descifrar ese mensaje. Recordemos que el cifrado/descifrado de mensajes se realiza con
un algoritmo de cifrado simtrico. CAST-128 e IDEA usan claves de 128 bits; 3DES usa
una de 168 bits. Para lo que se expone a continuacin, adoptamos CAST-128.
Se generan nmeros aleatorios de 128 bits usando CAST-128. La entrada al genera
dor de nmeros aleatorios consiste en una clave de 128 bits y dos bloques de 64 bits que
se tratan como texto claro que se va a cifrar. Usando el modo de realimentacin de cifra
do (CFB), el cifrador CAST-128 produce dos bloques de texto cifrado de 64 bits, que se
concatenan para formar la clave de sesin de 128 bits. El algoritmo que se usa se basa
en el que se especifica en ANSI X12.17.
La entrada texto claro al generador de nmeros aleatorios, que consiste en dos blo
ques de 64 bits, procede de una ristra de nmeros generados de forma aleatoria de 128
bits. Estos nmeros se basan en entradas de pulsaciones de teclas por parte del usuario.
El tiempo de pulsacin y las teclas pulsadas se usan para generar la ristra aleatoria. Por
lo tanto, si el usuario pulsa teclas arbitrarias a su ritmo normal, se generar una entrada
razonablemente aleatoria. Esta entrada aleatoria tambin se combina con la salida de
la clave de sesin anterior de CAST-128 para formar la entrada de la clave al generador.
El resultado de la alteracin de CAST-128 es producir una secuencia de claves de sesin
efectivamente impredecible.
El Apndice 5C trata ms detalladamente las tcnicas de generacin de nmeros
aleatorios de PGP.
IDENTIFICADORES DE CLAVE
Como hemos dicho, un mensaje cifrado est acompaado de una forma cifrada de la
clave de sesin que se emple. La clave de sesin se cifra con la clave pblica del recep
tor. As, slo el receptor podr recuperar la clave de sesin y, por consiguiente, el men
saje. Si cada usuario utiliz una nica pareja de claves pblica/privada, el receptor debe
ra saber automticamente qu clave usar para descifrar la clave de sesin: la clave
privada nica del receptor. Sin embargo, no olvidemos el requisito de que cualquier
usuario dado podra tener mltiples parejas de claves.
Entonces, cmo sabe el receptor cul de sus claves pblicas se us para cifrar la cla
ve de sesin? Una solucin simple sera transmitir la clave pblica con el mensaje.
Entonces, el receptor podra verificar que efectivamente se trata de una de sus claves
pblicas, y continuar. Este esquema funcionara, pero constituye un gasto innecesario de
espacio. Una clave pblica RSA podra tener una longitud de cientos de dgitos deci
males. Otra solucin sera asociar un identificador a cada clave pblica que sea nica al
menos en un usuario. Es decir, la combinacin del identificador de usuario (user ID) y
www.FreeLibros.org
138 Fundamentos de seguridad en redes. Aplicaciones y estndares
el identificador de clave (key ID) sera suficiente para identificar una clave en especial.
Entonces, slo sera necesario transmitir el identificador de clave ms corto. Sin embar
go, esta solucin trae consigo un problema de gestin y de costes adicionales: los iden-
tificadores de clave deben ser asignados y almacenados para que tanto el emisor como
el receptor puedan establecer la relacin entre identificador de clave y clave pblica.
Esto parece una carga innecesaria.
La solucin adoptada por PGP es la de asignar un identificador de clave a cada cla
ve pblica que, con un gran ndice de probabilidad, es nica en el identificador de un
usuario. El identificador de clave asociado con cada clave pblica consiste en sus 64 bits
menos significativos. Es decir, el identificador de clave de clave pblica KUa es (KUa
mod 264). Esta es una longitud suficiente para que la probabilidad de duplicacin de
identificadores de clave sea muy pequea.
Tambin se necesita un identificador de clave para la firma digital PGP. Como un
emisor puede usar una clave privada, de una serie de claves privadas, para cifrar el resu
men del mensaje, el receptor debe saber qu clave pblica se debe usar. Por lo tanto, el
componente firma digital de un mensaje incluye el identificador de clave de 64 bits de
la clave pblica que se requiere. Cuando se recibe el mensaje, el receptor verifica que el
identificador de clave es el de una clave pblica para ese emisor y entonces procede a
verificar la firma.
Ahora que se ha introducido el concepto de identificador de clave, podemos obser
var en profundidad el formato de un mensaje transmitido, que se muestra en la Figu
ra 5.3. Un mensaje est formado por tres componentes: el componente de mensaje, el
componente de firma (opcional) y el componente de clave de sesin (opcional).
El componente mensaje incluye los datos reales que se van a almacenar o trans
mitir, as como un nombre de archivo y un sello de tiempo que especifica el momento
de creacin.
El componente firma incluye lo siguiente:
Sello d e tksnpo: el momento en que se cre la firma.
Resumen d e mensaje: el resumen SHA-1 de 160 bits, cifrado con la clave de fir
ma privada del emisor. El resumen se calcula con el sello de tiempo de la firma
concatenado con la parte de datos del componente de mensaje. La inclusin del
sello de tiempo de la firma en el resumen evita los ataques de repeticin. La exclu
sin de las partes del nombre del archivo y sello de tiempo del componente de
mensaje garantiza que las firmas adjuntas son exactamente las mismas que las fir
mas adjuntas antepuestas al mensaje. Las firmas separadas se calculan en un fiche
ro separado que no tiene ninguno de los campos ae cabecera del componente de
mensaje.
Dos octetos iniciales del resumen de! mensaje: para permitir que el receptor
determine si se us la clave pblica correcta para descifrar el resumen del mensa
j e para la autentifcacin, se compara la copia en texto claro de los dos primeros
octetos con los dos primeros octetos del resumen descifrado. Estos octetos tambin
sirven de comprobacin del marco de 16 bits para el mensaje.
Modificador d e clave de la clave pblica d d amsor: identifica la clave pblica
que debera usarse para descifrar el resumen del mensaje y, por lo tanto, identifica
la clave privada que se utiliz para cifrar el resumen del mensaje.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 139
Contenido
Componente
clave
de sesin
Firma
Mensaje
Identificador de clave
de la clave pblica
del receptor[KUbl
Clave de sesin (Ks)
Sello de tiempo
Identificador de clave
de la clave pblica
del emisor (KUa)
Dos octetos iniciales del
resumen del mensaje
Resumen del mensaje
Nombr e de archivo
Sello de tiempo
Datos
Notacin:
EKUb = cifrado con clave pblica del usuario b
EKRa = cifrado con clave privada del usuario a
Eks= cifrado con clave de sesin
Operacin
KUb
KRa
ZIP
Eks
R64
ZIP = funcin de compresin de ZIP
R64 = funcin de conversin de radix 64
Figura 5 . 3 F o r m a t o g e n e r a l d e l m e n s a j e P G P ( d e A a B)
El componente de mensaje y el componente opcional de firma pueden comprimirse
usando ZIP y pueden cifrarse usando una clave de sesin.
El componente clave descrita incluye la clave de sesin y el identificador de la cla
ve pblica del receptor que utiliz el emisor para cifrar la clave de sesin.
El bloque entero se codifica normalmente con radix 64.
FICHEROS DE CLAVES
Hemos comprobado que los identificadores de clave son crticos para la operacin de
PGP y que en cualquier mensaje PGP que proporcione confidencialidad y autentifica
cin se incluyen dos identificadores de clave. Es necesario almacenar y organizar estas
claves de forma sistemtica para que todas las partes las usen de forma eficaz y efecti-
www.FreeLibros.org
140 Fundamentos de seguridad en redes. Aplicaciones y estndares
va. El esquema usado en PGP es el de proporcionar un par de estructuras de datos en
cada nodo, una para almacenar las parejas de claves pblica/privada pertenecientes a ese
nodo, y otra para almacenar las claves pblicas de otros usuarios conocidos en ese nodo.
Estas estructuras de datos se conocen, respectivamente, como fichero de claves privadas
y fichero de claves pblicas.
La Figura 5.4 muestra la estructura general de un fichero d e claves p rivad Pode
mos ver el fichero como una tabla en la que cada fila representa una de las parejas de
claves pblica/privada que posee ese usuario. Cada fila contiene las siguientes entradas:
Sello d e tksnpo: fecha y hora en que se gener la pareja de claves.
Idaitificador de daves los 64 bits menos significativos de la clave pblica para
esa entrada.
Clave pblica: la parte de clave pblica de la pareja en cuestin.
Clave privada: la parte de clave privada de la pareja en cuestin; este campo est
cifrado.
Idaitficador d e usuario: normalmente, ser la direccin de correo electrnico del
usuario (por ejemplo, stallings@acm.org). Sin embargo, el usuario puede elegir aso
ciar un nombre diferente a cada pareja (por ejemplo, Stalllings, WStallings, William
Stallings, etc.) o reutilizar el mismo identificador de usuario ms de una vez.
Fichero de claves privadas
Sello
d e t i e m p o
I d e n t i f i c a d o r
d e c l a v e
C l a v e p b l ic a C l a v e p r i v a d a
c i f r a d a
I d e n t i f i c a d o r
d e u s u a r i o *



T
KU m o d 2 * * KU
E H(P)[KR]
U s u a r i o i



Fichero de claves pblicas
Sello Identificador Clave Confianza Identificador Legitimidad Firmis) Confianza
de d e cla ve* pblica en el de d e clave e n la
tiempo dueo usuario* firma

T KU m o d 24 KU] tr u s _ f l a g i Usuario i tr u s _ fla g

* c a m p o u t i l i z a d o p a r a i n d e x a r l a t a b l a
Figura 5.4 E s t r u c t u r a g e n e r a l d e l o s f i c h e r o s d e c l a v e s p b l i c a s y p r i v a d a s
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 141
El fichero de claves privadas se puede indexar por el identificador de usuario o el iden
tificador de clave; ms adelante veremos la necesidad de los dos medios de indexacin.
Aunque se intenta que el fichero de claves privadas se almacene slo en la mquina
del usuario que cre y posee la pareja de claves, y que slo ese usuario pueda acceder a
l, tiene sentido hacer que el valor de la clave privada sea lo ms seguro posible. Por lo
tanto, la clave privada no se almacena en el fichero de claves. En vez de eso, esta clave
se cifra usando CAST-128 (o IDEA o 3DES). El procedimiento es el siguiente:
1. El usuario elige una frase clave para el cifrado de claves privadas.
2. Cuando el sistema genera una nueva pareja de claves pblica/privada usando
RSA, pide la frase clave al usuario. Usando SHA-1, se genera un cdigo hash de
160 bits a partir de la frase clave, y la frase clave se descarta.
3. El sistema cifra la clave privada usando CAST-128 con los 128 bits del cdigo
hash como clave. Luego el cdigo hash se descarta, y la clave privada cifrada se
almacena en el fichero de claves privadas.
Posteriormente, cuando un usuario accede al fichero de claves privadas para recuperar
una clave privada, debe suministrar la frase clave. PGP recuperar la clave privada cifra
da, generar el cdigo hash de la frase clave y descifrar la clave privada cifrada usan
do CAST-128 con el cdigo hash.
Este es un esquema muy compacto y eficaz. Como en cualquier sistema que se base
en contraseas, la seguridad de este sistema depende de la seguridad de la contrasea.
Para evitar la tentacin de escribirla, el usuario debera utilizar una frase clave que no
sea fcil de adivinar, pero s fcil de recordar.
La Figura 5.4 tambin presenta la estructura general de un archivo de claves pbli
cas. Esta estructura de datos se usa para almacenar claves pblicas de otros usuarios
conocidos por este usuario. Por el momento, dejamos pendientes algunos de los campos
que se muestran en la tabla y describiremos los siguientes:
Sello d e tkmpoc fecha y hora en que se gener la entrada.
Identificador de clave: los 64 bits menos significativos de la clave pblica para
esta entrada.
Clave pblica: clave pblica para esta entrada.
Identificador de usuario: identifica al propietario de l a clave. Varios identifica-
dores de usuario pueden estar asociados a una sola clave pblica.
El fichero de claves pblicas se puede indexar por identificador de usuario o identifica
dor de clave; veremos posteriormente que los dos medios de indexacin son necesarios.
Ahora podemos observar cmo se usan estos ficheros de claves en la transmisin y
la recepcin de mensajes. Para simplificar la explicacin, dejaremos de lado la compre
sin y la conversin de radix 64. En primer lugar, consideremos la transmisin del men
saje (Figura 5.5) y asumamos que el mensaje debe firmarse y cifrarse. La entidad PGP
emisora realiza los siguientes pasos:
1. Firmar el mensaje
a) PGP recupera la clave privada del emisor del fichero de claves privadas usan
do tujdentificador de usuario (your_userid) como ndice. Si tu-identificador
www.FreeLibros.org
142 Fundamentos de seguridad en redes. Aplicaciones y estndares
de ususario no se proporcion en el comando, se recupera la primera clave
del fichero.
b) PGP solicita al usuario la frase clave para recuperar la clave privada que no
est cifrada.
c) Se construye el componente de firma del mensaje.
Cifrar el mensaje
a) PGP genera una clave de sesin y cifra el mensaje.
b) PGP recupera la clave pblica del receptor del fichero de calves pblicas
usando sujdentificador de usuario (her-userid) como ndice.
c) Se construye el componente de clave de sesin del mensaje.
Frase clave
H
Fichero de claves
privadas
ID A
Elige
Clave privada v
cifrada
D C
Identificador
de clave
Clave privada
KRa
Resumen
de
mensaje
H E P I I
Mensaje
Fichero de claves
pblicas
ID,
Elige
Clave ID
Clave pblica
KUb
RNG
Clave de sesin
Ks
Firma +
Mensaje
e n ^ 1 1
L l l ^ 1 1
Salida
E C
Firma cifrada
+mensaje
Figura 5.5 G e n e r a c i n d e m e n s a j e P G P ( d e l u s u a r i o A a l u s u a r i o B;
s in c o m p r e s i n n i c o n v e r s i n d e r a d i x 6 4 )
La entidad PGP receptora realiza los siguientes pasos (Figura 5.6):
L Descifrar el mensaje
a) PGP recupera la clave privada del receptor seleccionada del fichero de claves
privadas, usando como ndice el campo identificador de clave del compo
nente clave de sesin del mensaje.
b) PGP pide al usuario la frase clave para recuperar la clave privada sin cifrar.
c) Luego, PGP recupera la clave de sesin y descifra el mensaje.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 143
Fichero de claves privadas
Elige
Frase clave
H
Identificado
de clave del
receptor
Mensaje
cifrado
firma
L_L
Clave privada v
cifrada
Clave privada
KRb
D P
Clave de sesin
Ks
- D P
Fichero
de claves
pblicas
Figura 5.6 R e c e p c i n P G P ( d e l u s u a r i o A a l u s u a r i o B; s i n c o m p r e s i n ni c o n v e r s i n
d e r a d i x 6 4 )
2. Autentificar el mensaje
a) PGP recupera la clave pblica del emisor del fichero de claves pblicas,
usando como ndice el campo identificador de clave en el componente clave
de firma del mensaje.
b) PGP recupera el resumen del mensaje transmitido.
c) PGP calcula el resumen de mensaje para el mensaje recibido y lo compara
con el resumen de mensaje transmitido para autentificar.
GESTIN DE CLAVE PBLICA
Como se ha podido observar, PGP contiene una serie de funciones y formatos inteli
gentes y eficientes entrelazados para proporcionar un servicio efectivo de confidenciali
dad y autentificacin. Para completar el sistema, es necesario tratar un aspecto final, el
de la gestin de claves pblicas. La documentacin PGP presenta la importancia de este
aspecto:
Toda l a cuestin sobre la proteccin de claves pblicas ante l a posible falsificacin o irrup
cin e s e l problema ms dif ci l en las aplicaciones prcticas d e clave pblica. Es el taln de Aqui-
les de la criptografa de clave pblica, y e l software s e hace cada v e z ms complejo para resolver
e ste problema.
www.FreeLibros.org
144 Fundamentos de seguridad en redes. Aplicaciones y estndares
PGP ofrece una estructura para resolver este problema, para lo cual se pueden tener
en cuenta algunas opciones. Como PGP est diseado para su uso en diferentes entor
nos formales e informales, no se establece un esquema rgido de gestin de claves pbli
cas, como veremos que ocurre en S/MEME en este Captulo.
ENFOQUES PARA LA GESTIN DE CLAVES PBLICAS
La esencia del problema es la siguiente: el usuario A debe crear un fichero de claves
pblicas que contenga las claves pblicas de otros usuarios para interoperar con ellos
usando PGP. Supongamos que el fichero de claves de A contiene una clave pblica atri
buida a B pero que, de hecho, pertenece a C. Esto podra ocurrir s, por ejemplo, A ob
tuvo la clave de un sistema de tabln de anuncios que fue usado por B para publicar la
clave pblica y que, a su vez, se vio comprometido por C. Esto da como resultado dos
amenazas. En primer lugar, C puede enviar mensajes a A y falsificar la firma de B, de
forma que A aceptar el mensaje como si proviniese de B. En segundo lugar, cualquier
mensaje cifrado de A a B puede ser ledo por C.
Existen algunos enfoques para reducir el riesgo de que el fichero de claves pblicas
de un usuario contenga claves pblicas falsas. Supongamos que A quiere obtener una
clave pblica fiable para B. A continuacin se exponen algunos de los enfoques que pue
den usarse:
L Obtener la clave de B fsicamente. B podra almacenar su clave pblica {KU$
en un disquete y entregarla a A. Luego A podra cargar la clave en su sistema
desde el disquete. Este es un mtodo seguro pero tiene limitaciones prcticas
obvias.
Z Verificar una clave por telfono. Si A puede reconocer a B al telfono, A podra
llamar a B y pedirle que le dicte la clave, en formato radix 64. Como alternativa
ms prctica, B podra transmitir su clave por correo electrnico a A. El usuario
A podra hacer que PGP genere un resumen SHA-1 de la clave de 160 bits y
mostrarlo en formato hexadecimal; esto se conoce como la huella de la clave.
A podra, luego, llamar a B y pedirle que le dicte la huella por telfono. Si las
dos huellas coinciden, se verifica la clave.
& Obtener la clave pblica de B a partir de un usuario D de confianza mutua, o pre
sentador. Con este fin, D crea un certificado firmado. El certificado incluye la
clave pblica de B, la fecha de creacin de la clave y el perodo de validez de la
misma. D genera un resumen SHA-1 de este certificado, lo cifra con su clave pri
vada y aade la firma al certificado. Como slo D poda haber creado la firma,
nadie ms puede crear una clave pblica falsa y hacer creer que fue firmada por
D. El certificado firmado podra ser enviado directamente a A por B o D, o
podra publicarse en un tabln de anuncios.
4 Obtener la clave pblica de B a partir de una autoridad de certificacin confia
ble. De nuevo, un certificado de clave pblica lo crea y firma la autoridad.
Entonces, A podra acceder a la autoridad, proporcionando un nombre de usua
rio y recibiendo un certificado firmado.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 145
Para los casos 3 y 4, A ya tendra que tener una copia de la clave pblica de D y confiar
en que dicha clave sea vlida. Por ltimo, confiar en quien acte como presentador es
decisin de A.
EL USO DE LA CONFIANZA
Aunque PGP no incluye ninguna especificacin para establecer autoridades de certifi
cacin o para establecer la confianza, s que proporciona un medio conveniente de usar
la, asocindola a las claves pblicas y explotando la informacin de confianza.
La estructura bsica es la siguiente: cada entrada en el fichero de claves pblicas es
un certificado de clave pblica, tal y como se describi en el apartado anterior. Asocia
do con cada entrada hay un campo de legitimidad d e la clave, que indica hasta qu
punto PGP confiar en que se trata de una clave pblica vlida para este usuario; cuan
to mayor sea este nivel de confianza, mayor ser la relacin del identificador de usuario
con esta clave. Este campo es calculado por PGP. Tambin asociadas con la entrada hay
varias firmas, o ninguna, recopiladas por el propietario del fichero de claves y que fir
man este certificado. A su vez, un campo de confianza <n la firma se asocia con cada
firma. Este campo indica hasta qu punto este usuario de PGP confa en el firmante para
certificar claves pblicas. El campo de legitimidad de la clave se deriva del grupo de
campos de confianza en la firma en la entrada. Por ltimo, cada entrada define una cla
ve pblica asociada con un propietario particular, y se incluye un campo d e confianza
en d dueo que indica hasta qu punto se confa en esta clave pblica para firmar otros
certificados de clave pblica; este nivel de confianza lo asigna el usuario. Podemos con
siderar los campos de confianza en la firma como copias ocultas del campo de confian
za en el dueo de otra entrada.
Los tres campos mencionados estn incluidos en una estructura conocida como byte
indicador de conanza. En la Tabla 5.2 se muestra el contenido del indicador de con
fianza para cada uno de estos tres usos. Supongamos que se trata del fichero de claves
pblicas del usuario A. Podemos describir la operacin del procesamiento de confianza
como sigue:
1. Cuando A inserta una nueva clave pblica en el fichero de claves pblicas, PGP
debe asignar un valor al indicador de confianza que est asociado con el dueo
de esta clave pblica. Si el propietario es A y, por lo tanto, esta clave pblica apa
rece tambin en el fichero de claves privadas, entonces se asigna un valor de con
anza denitiva (ultmate trust) al campo de confianza. Si no, PGP pide a A su
valoracin de la confianza que ha de asignarse al propietario de esta clave, y A
debe introducir el nivel deseado. El usuario puede especificar que este usuario
es desconocido, no fiable, ligeramente fiable o absolutamente fiable.
2. Cuando se introduce la nueva clave pblica, se pueden unir a ella una o varias
firmas. Posteriormente se pueden aadir ms firmas. Cuando se inserta una fir
ma en la entrada, PGP busca el fichero de claves pblicas para comprobar si el
autor de esa firma se encuentra entre los propietarios conocidos. Si es as, se
asigna el valor OWNERTRUST (confianza en el propietario) para ese propieta
rio al campo SIGTRUST (confianza en la firma) para esa firma. De no ser as,
se asigna el valor usuario desconocido (unknown usei).
www.FreeLibros.org
146 Fundamentos de seguridad en redes. Aplicaciones y estndares
T a b l a 5 . 2 C o n t e n i d o s d e l b y t e i n d i c a d o r d e c o n f i a n z a
( a ) C o n f i a n z a a s i g n a d a al
d u e o d e u n a c l a v e
p b l i c a ( a p a r e c e d e s
pu s d e l p a q u e t e d e
cla ves ; d e f i n i d o p o r el
u s u a r i o )
(b ) C o n f i a n z a a s i g n a d a a
l a p a r e j a d e c l a v e
p b l i c a / I D d e u s u a r i o
( a p a r e c e d e s p u s del
p a q u e t e ID d e u s u a
r i o ; c a l c u l a d o p o r
PGP)
(c) Con fi a n z a a s i g n a d a a
la f i r m a ( a p a r e c e d e s
pus de l p a q u e t e d e la
f i r m a ; c o pia oc ul t a del
O W N E R T R U S T p a r a
este f i r m a n t e )
C a m p o O W N E R T R U S T
c o n fi a n z a i n d e f i n i d a
us uar io de s c o n o c id o
n o r m a l m e n t e n o f i a
b l e p a r a f i r m a r ot ra s
c l a v e s
n o r m a l m e n t e f i a b l e
para f i r m a r otras claves
s i e m p r e f i a b l e p a r a
f i r m a r o t r a s c l a v e s
esta cla ve est e n el
fichero d e cla ves s e
cr e ta s (c o n f i a n z a d e
f i n i t i v a )
Bit B U C K S T O P
s e f i j a si l a c l a v e a p a
r e c e e n el f i c h e r o d e
c l a v e s se cre tas
C a m p o KE YL EG IT
d e s c o n o c i d o o c o n
fi a nza i n d e f i n i d a
p r o p i e d a d d e l a cl a ve
no f i a b l e
c o n fi a n z a in cier ta e n la
p r o p i e d a d d e la cl a ve
confi anza a b s ol uta en
la p r o p i e d a d d e la cla
ve
B i t W A R N O N L Y
se f i j a si el u s u a r i o
q u i e r e s e r a v i s a d o
slo c u a n d o u n a clave
q u e n o est t o t a l m e n
te v a l i d a d a se us a pa ra
cif ra r
C a m p o S I G T R U S T
c o n f i a n z a i n d e f i n i d a
us uar i o de s c o n o c i d o
n o r m a l m e n t e n o f i a
bl e p a r a f i r m a r ot ra s
cl a ves
n o r m a l m e n t e f i a b l e
p a r a f i r m a r ot ra s cla
ves
s i e m p r e f i a b l e p a r a
f i r m a r o t r a s cla ves
e s t a c l a v e e s t e n el
f i c h e r o d e c l a v e s
s e c r e t a s ( c o n f i a n z a
d e f i n i t i v a )
Bit C O N T I G
se fij a si la f i r m a ll e v a a
un a r u ta c o n ti g u a de
certi ficacin f i a b l e h a s
t a el p r o p i e t a r i o l tim o
del fichero de claves
c o n f i a b l e
3L El valor del campo de legitimidad de la clave se calcula partiendo de los campos
de confianza en la firma presentes en esa entrada. Si al menos una firma tiene un
valor de confianza en la firma de definitivo, entonces el valor de legitimidad de la
clave se fija en absoluto. Si no, PGP calcula una suma ponderada de los valores de
confianza. A las firmas que son siempre fiables se les da un peso de \/X, y a las
que lo son con frecuencia, 1/ Y, donde X e Y son parmetros configurables por el
usuario. Cuando el total de los pesos de los que introducen una combinacin de
clave/identificador de usuario alcanza 1, la relacin se considera digna de con
fianza, y el valor de legitimidad de la clave se fija en absoluto. As, en ausencia
de confianza absoluta, se necesitan al menos ATirmas siempre fiables, o Y firmas
frecuentemente fiables o una combinacin de ellas.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 147
Peridicamente, PGP procesa el fichero de claves pblicas para alcanzar consistencia.
Bsicamente, este es un proceso de descenso. Para cada campo OWNERTRUST, PGP
busca en el fichero todas las firmas creadas por un propietario y actualiza el campo SIG-
TRUST para igualarlo al campo OWNERTRUST. Este proceso empieza con claves para
las cuales hay confianza definitiva. Entonces, todos los campos KEYLEGIT se calculan
basndose en las firmas adjuntas.
La Figura 5.7 proporciona un ejemplo de la forma en que se relacionan la confianza en
la firma y la legitimidad de la clave2. La figura muestra la estructura de un fichero de cla
ves pblicas. El usuario ha adquirido una serie de claves pblicas, algunas directamente de
sus propietarios y otras de una tercera parte como, por ejemplo, un servidor de claves.
El nodo con la etiqueta You se refiere a la entrada en el fichero de claves pblicas
correspondiente a ese usuario. Esta clave es legtima y el valor OWNERTRUST es con
fianza definitiva. Cada uno de los dems nodos del fichero de claves tiene un valor
OWNERTRUST de indefinido a menos que el usuario asigne otro valor. En este ejemplo,
este usuario ha especificado que siempre confa en los siguientes usuarios para firmar otras
claves: D, E, F, L, y que confa parcialmente en los usuarios A y B para firmar otras claves.
Por lo tanto, el sombreado, o la ausencia de sombreado, de los nodos de la Figura 5.7
indican el nivel de confianza asignado por este usuario. La estructura de rbol indica qu
claves han sido firmadas y qu usuarios las han firmado. Si una clave est firmada por
un usuario cuya clave tambin se encuentra en este fichero de claves, la flecha va de la
clave firmada al firmante. Si la clave est firmada por un usuario cuya clave no se
encuentra en el fichero de claves, la flecha une la clave firmada a un signo de interroga
cin, indicando que el firmante es desconocido para el usuario.
En la Figura 5.7 se ilustran varios aspectos:
1. Obsrvese que todas las claves cuyos propietarios son total o parcialmente fia
bles para el usuario han sido firmadas por ese usuario, a excepcin del nodo L.
La firma del usuario no siempre es necesaria, como indica la presencia del nodo
L, pero en la prctica, la mayora de los usuarios tienden a firmar las claves para
la mayora de los propietarios en los que confan. As, por ejemplo, aunque la
clave de E ya est firmada por un presentador confiable F, el usuario decide fir
mar la clave de E directamente.
2. Asumimos que dos firmas parcialmente confiables son suficientes para certificar
una clave. Por consiguiente, PGP considera legtima la clave para el usuario H
porque est firmada por A y B, que son parcialmente fiables.
3. Se puede determinar que una clave es legtima porque est firmada por un fir
mante absolutamente fiable o por dos parcialmente fiables, pero su usuario puede
no ser fiable para firmar otras claves. Por ejemplo, la clave de N es legtima por
que est firmada por E, en quien confa este usuario, pero N no es fiable para fir
mar otras claves porque este usuario no ha asignado a N ese valor de confianza.
Por lo tanto, aunque la clave de R est firmada por N, PGP no considera legtima
la clave de R. Esta situacin tiene sentido. Si se desea enviar un mensaje privado
a un individuo, no es necesario confiar en l en ningn sentido. Slo es necesario
estar seguro de tener la clave pblica correcta para ese individuo.
2 Figura ofrecida al autor por Phil Zimmermann.
www.FreeLibros.org
148 Fundamentos de seguridad en redes. Aplicaciones y estndares
4 La Figura 5.7 tambin muestra un ejemplo de un nodo S separado hurfano,
con dos firmas desconocidas. Esta clave puede haber sido adquirida de un servi
dor de claves. PGP no puede asumir que esa clave es legtima simplemente por
que proviene de un servidor de confianza. El usuario debe declarar que la clave
es legtima firmndola o diciendo a PGP que est dispuesto a confiar por com
pleto en uno de los firmantes de la clave.
O = el dueo de la clave es parcialmente fiable para fir mar claves
( ) = la clave se considera legtima
Figura 5.7 E j e m p l o d e l m o d e l o d e c o n f i a n z a d e PGP
Por ltimo, recordemos que anteriormente se mencion que varios identificadores de
usuario podan asociarse con una nica clave pblica del fichero de claves pblicas. Esto
podra ser porque una persona ha cambiado los nombres o ha sido introducida median
te firma con mltiples nombres, indicando diferentes direcciones de correo electrnico
para la misma persona, por ejemplo. Por lo tanto podemos imaginar una clave pblica
como la raz de un rbol. Una clave pblica tiene asociada una serie de identificadores
de usuarios, con una serie de firmas para cada identificador de usuario. La vinculacin
de un identificador de usuario particular a una clave depende de las firmas asociadas con
l y esa clave, mientras que el nivel de confianza en esta clave (para firmar otras claves)
es una funcin de todas las firmas dependientes.
REVOCACIN DE CLAVES PBLICAS
Un usuario podra querer revocar su clave pblica actual porque sospecha que existe un
riesgo o simplemente para evitar el uso de la misma clave durante un perodo largo de
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 149
tiempo. Obsrvese que un compromiso requerira que un oponente, de alguna forma,
haya obtenido una copia de la clave privada de alguien sin cifrar o que el oponente haya
obtenido la clave privada de su fichero de claves privadas y su frase clave.
La convencin para revocar una clave pblica es que el propietario emita un certifica
do de revocacin de clave, firmado por l. Este certificado tiene la misma forma que
un certificado de firma normal pero incluye un indicador que seala que el propsito de
este certificado es el de revocar el uso de esta clave pblica Obsrvese que la clave priva
da correspondiente debe usarse para firmar un certificado que revoca una clave pblica. El
dueo debera intentar difundir este certificado lo ms amplia y rpidamente posible para
permitir que los interlocutores potenciales actualicen sus ficheros ae claves pblicas.
Hay que tener en cuenta que un oponente que ha comprometido la clave privada de
un propietario puede tambin emitir ese certificado. Sin embargo, esto denegara al opo
nente y al dueo legtimo el uso de la clave pblica, y por lo tanto parece una amenaza
menos probable que el uso fraudulento de una clave privada robada.
5 . 2 S/ MIME
S/MIME (Secure/Multipurpose Internet Mail Extensin) supone una mejora a la seguri
dad del formato estndar de correo electrnico de Internet de MIME, basado en tecno
loga de RSA Data Security. Aunque PGP y S/MIME son especificaciones de la IETF,
parece probable que S/MIME se convierta en el estndar industrial para uso comercial
y empresarial, mientras PGP se mantendr como una opcin para la seguridad personal
del correo electrnico para muchos usuarios. S/MIME se define en una serie de docu
mentos, especialmente en los RFC 2630, 2632 y 2633.
Para entender S/MIME, es necesario primero tener un conocimiento general de
MIME, que es el formato de correo electrnico subyacente que utiliza. Pero para com
prender la importancia de MIME, debemos retroceder al estndar tradicional del for
mato de correo electrnico, RFC 822, que an es de uso comn. Por ello, esta seccin
ofrece una introduccin a estos estndares iniciales y analiza el S/MIME.
RFC 822
El RFC 822 define un formato para los mensajes de texto que se envan por medio de
correo electrnico. Ha sido el estndar para los mensajes de texto de correo electrnico
basado en Internet y sigue siendo de uso comn. En el contexto del RFC 822, se consi
dera que los mensajes se componen de un sobre (envelope) y unos contenidos (conten).
El sobre contiene la informacin necesaria para llevar a cabo la transmisin y la distri
bucin. Los contenidos constituyen el objeto que se va a enviar al receptor. El estndar
RFC 822 se aplica nicamente a los contenidos. Sin embargo, el contenido estndar
incluye un conjunto de campos de cabecera que el sistema de correo electrnico puede
usar para crear el sobre, y el estndar est diseado para facilitar la adquisicin de dicha
informacin por parte de los programas.
La estructura general de un mensaje que se ajuste al RFC 822 es muy sencilla. Un
mensaje est formado por un nmero determinado de lneas de cabecera (the header)
www.FreeLibros.org
150 Fundamentos de seguridad en redes. Aplicaciones y estndares
seguido de un texto arbitrario (the body). La cabecera se separa del cuerpo del texto
mediante una lnea en blanco. Es decir, un mensaje es texto ASCII, y todas las lneas
hasta llegar a la primera lnea en blanco forman la cabecera que usa el agente de usua
rio del sistema de correo electrnico.
Una lnea de cabecera consta normalmente de una palabra clave, seguida de dos
puntos, seguidos, a su vez, del argumento de la palabra clave; el formato permite divi
dir una lnea muy larga en varias lneas. Las palabras clave ms empleadas son De
(From), A (To), Asunto (Subjecf) y Fecha (Dat). A continuacin se presenta un ejem
plo de mensaje;
D a t e : Tu e , 1 6 J a n 1 9 9 8 1 0 : 3 7 : 1 7 (EST)
From: W i l l i a m s t a l l i n g s <w s @ s h o r e . n e t >
S u b j e c t : La s i n t a x i s d e l RFC 8 2 2
To: S m i t h @ O t h e r - h o s t . c o m
C e : J o n e s @ Y e t - A n o t h e r - H o s t . com
H o l a . E s t a s e c c i n e s e l c o m i e n z o d e l c u e r p o d e t e x t o , q u e e s t
s e p a r a d o d e l a c a b e c e r a d e l m e n s a j e p o r u n a l n e a e n b l a n c o .
Otro campo que se encuentra habitualmente en las cabeceras RFC 822 es el Identif-
cador de mensaje (Message-ID). Este campo contiene un identificador nico asociado
con este mensaje.
MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS)
MIME es una extensin del marco de trabajo del RFC 822 diseado para afrontar algu
nos de los problemas y limitaciones del uso del SMTP (Simple Mail Transfer Protocol)
u otros protocolos de transferencia de correo y RFC 822 para correo electrnico.
[MURH98] presenta las siguientes limitaciones del esquema del SMTP/822:
L El SMTP no puede transmitir ficheros ejecutables ni otros objetos binarios. Se
utilizan una serie de esquemas para convertir ficheros binarios a formato texto
que puedan usar los sistemas de correo de SMTP, incluido el conocido esquema
de UNIX UUencode/UUdecode. Sin embargo, ninguno de ellos es un estndar.
Z El SMTP no puede transmitir datos de texto que incluyan caracteres de un idio
ma nacional porque stos se representan por cdigos de ocho bits con valores de
128 decimal o superiores, y SMTP se limita a caracteres ASCII de siete bits.
3L Los servidores SMTP pueden rechazar mensajes que superen una determinada
extensia
4 Las pasarelas SMTP que traducen de ASCII a cdigo EBCDIC no usan corres
pondencias consistentes, lo que da lugar a problemas de traduccin.
& Las pasarelas SMTP a redes de correo electrnico X.400 no pueden manejar
datos que no sean de texto incluidos en mensajes X.400.
& Algunas implementaciones SMTP no se adhieren por completo a los estndares
SMTP definidos en el RFC 821. Los problemas habituales incluyen:
Eliminacin, incorporacin o reordenamiento de caracteres de retomo de
carro y de salto de lnea.
www.FreeLibros.org
Captulo 5 /S e g ur i da d en el correo electrnico 151
Truncamiento o divisin de lneas de ms de 76 caracteres.
Eliminacin de espacios finales en blanco (caracteres fabuladores y de espacio).
Relleno de lneas de un mensaje para que tengan la misma longitud.
Conversin de caracteres fabuladores a mltiples caracteres de espacio.
MIME tiene la finalidad de resolver estos problemas de forma que resulte compatible
con las implementaciones existentes del RFC 822. La especificacin se encuentra en los
RFC 2045 al 2049.
DESCRIPCIN GENERAL
La especificacin MIME incluye los siguientes elementos:
1. Se definen cinco nuevos campos de cabecera del mensaje, que se pueden incluir
en una cabecera RFC 822. Estos campos aportan informacin sobre el cuerpo
del mensaje.
2. Se define una serie de formatos de contenido, estandarizando as las representa
ciones que dan soporte al correo electrnico multimedia.
3. Se definen esquemas de codificacin de transferencia que permiten la conver
sin de cualquier formato de contenido a una forma protegida contra alteracio
nes por el sistema de correo.
En este subapartado se introducen cinco campos de cabecera de mensaje. En los siguien
tes dos subapartados se analizan los formatos de contenido y los esquemas de codifica
cin de transferencia.
Los cinco campos de cabecera definidos en MIME son los siguientes:
Versin MIME: debe tener el valor de parmetro 1.0. Este campo indica que el
mensaje se ajusta a los RFC 2045 y 2046.
Tipo de contenido: describe los datos que contiene el cuerpo con suficiente
detalle para que el usuario receptor pueda elegir un agente o mecanismo apro
piado para representar los datos al usuario o, si no, manejar los datos de forma
apropiada.
Codificacin d e transferencia de contenido: indica el tipo de transformacin que
se ha utilizado para representar el cuerpo del mensaje de forma aceptable para el
transporte de correo.
Identificacin d e contenido: utilizada para identificar entidades MIME de forma
nica, en contextos mltiples.
Descripcin del contando: una descripcin en texto del objeto del cuerpo; es til
cuando el objeto no es legible (por ejemplo, datos de audio).
Cualquiera de estos campos puede aparecer en una cabecera normal de RFC 822. Una
correcta implementacin debe permitir los campos versin MIME, Tipo de contenido y
Codificacin de transferencia de contenido; los campos Identificacin de contenido y
Descripcin de contenido son opcionales y pueden ser ignorados por la implementacin
receptora.
www.FreeLibros.org
152 Fundamentos de seguridad en redes. Aplicaciones y estndares
TIPOS DE CONTENIDO MIME
El grueso de la especificacin MIME trata de la definicin de una serie de tipos de con
tenido. Esto refleja la necesidad de proporcionar formas estandarizadas de tratar una
gran variedad de representaciones de la informacin en un entorno multimedia.
La Tabla 5.3 presenta un listado de los tipos de contenido especificados en el RFC
2046. Hay siete tipos principales y un total ae 15 subtipos. En general, un tipo de con
tenido declara el tipo general de datos, y el subtipo especifica un formato particular para
ese tipo de datos.
T a b l a 5 . 3 T i p o s d e c o n t e n i d o d e M I M E
T i p o S u b t i p o Desc rip ci n
T e x to C la r o T e x to s i n f o r m a t e a r ; p u e d e s e r A S C I I o I S O
8 8 5 9 .
E n r i q u e c i d o P r o p o r c i o n a u n a m a y o r f l e x i b i l i d a d d e f o r m a t o .
M u l t i p a r t e
( m u l t i p a r t )
M e z c l a d o
( m i x e d )
Las d i f e r e n t e s p a rt e s so n i n d e p e n d i e n t e s p e r o se
v a n a t r a n s m i t i r j u n t a s . D e b e r a n p r e s e n t a r s e
al r e c e p t o r e n el o r d e n e n q u e a p a r e c e n e n el
m e n s a j e d e c o rr e o .
P a r a le lo
( p a r a l l e l )
S e d i f e r e n c i a d e l M e z c l a d o n i c a m e n t e e n q u e
no s e d e f i n e n i n g n o r d e n p a r a el e n v o de
l as p a rt e s al recep to r.
A l t e r n a t i v o
( a l t e r n a t i v a )
Las d i s t i n t a s p a r t e s so n v e r s i o n e s a l t e r n a t i v a s d e
l a m i s m a i n f o r m a c i n . Est n o r d e n a d a s en
e x a c t i t u d c r e c i e n t e al o r i g i n a l , y el s i s t e m a d e
c o r r e o r e c e p t o r d e b e r a m o s t r a r l a m e j o r
v e r s i n al u s u a r io .
R e s u m e n
( d i g e s t )
S i m i l a r a M e z c l a d o , p e r o el t i p o / s u b t i p o d e cada
p a r t e p o r d e f e c t o es m e n s a j e / r f c 8 2 2 .
M e n s a j e rfc 8 2 2
Parcial
C u e r p o e x t e r n o
El c u e r p o es p o r s m i s m o u n m e n s a j e e n c a p s u -
l a d o q u e s e a j u s t a al RFC 8 2 2 .
S e us a p a r a p e r m i t i r l a f r a g m e n t a c i n d e e l e
m e n t o s d e c o r r e o m u y l a r g o s , d e f o r m a q u e
sea t r a n s p a r e n t e al r e c e p t o r .
C o n t i e n e u n e n l a c e a u n o b j e t o q u e e x i s t e en
a l g u n a o t r a pa rte.
I m a g e n
jpeg
g f
La i m a g e n e s t e n f o r m a t o J P E G , c o d i f i c a c i n
JFIF.
La i m a g e n e s t e n f o r m a t o GIF.
V d e o m p e g F o r m a t o MP E G.
A u d i o Bsico C o d i f i c a c i n e n l e y m u d e u n ca na l n i c o I S D N
de 8 b i t s a 8 kHz.
A p l i c a c i n Post Sc rip t
R u j o d e oc tet os
A d o b e PostScript.
D a t o s b i n a r i o s g e n e r a l e s f o r m a d o s p o r b y t e s de
8 b i t s .
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 153
Para el tipo terto del cuerpo, no se requiere software especial para lograr el signifi
cado completo del texto, aparte de permitir el grupo de caracteres indicado. El subtipo
fundamental es texto claro, que consiste simplemente en una ristra de caracteres ASCII
o ISO 8859. El subtipo enriquecido permite una mayor flexibilidad en el formato.
El tipo multiparte indica que el cuerpo contiene varias partes independientes. El
campo de cabecera Tipo de Contenido incluye un parmetro, llamado lmite (boundary),
que define el delimitador entre las partes del cuerpo. Este lmite no debera aparecer en
ninguna de las partes del mensaje. Cada lmite empieza en una nueva lnea y est for
mado por dos guiones seguidos del valor del lmite. El lmite final, que indica el final de
la ltima parte, tambin tiene un sufijo de dos guiones. En cada parte puede haber una
cabecera comn MIME opcional.
A continuacin se muestra un ejemplo sencillo de un mensaje multiparte, que con
tiene dos partes compuestas por texto simple (extrado de RFC 2046):
F r a n : N a t h a n i e l B o r e n s t e i n <n s b @ b e l l c o r e . c o m >
I b : Ned F r e e d <n e d @ i n n o s o f t . com>
S u b j e c t : m e n s a j e d e m u e s t r a
MIME V e r s i o n : 1 . 0
C b n t e n t - t y p e : m u l t i p a r t / m i x e d ; b o u n d a r y = s i m p l e b o u n d a r y
E s t o e s e l p r e m b u l o . Ha d e s e r i g n o r a d o , a u n q u e e s u n l u g a r t i l
p a r a q u e l o s q u e e s c r i b e n c o r r e o i n c l u y a n u n a n o t a e x p l i c a t i v a p a r a
l o s l e c t o r e s q u e n o s i g u e n MIME, - - s i r r p l e b o u n d a r y
E s t o e s i m p l c i t m e n t e u n t e x t o e s c r i t o A S C I I . No a c a b a c o n u n a
r u p t u r a d e l n e a . - - s i m p l e b o u n d a r y
C b n t e n t - t y p e : t e x t / p l a i n ; c h a r s e t = u s - a s c i i
E s t o e s e x p l c i t a m e n t e u n t e x t o e s c r i t o A S C I I . A c a b a c o n u n a r u p t u r a
d e l n e a .
- - s i r r p l e b o u n d a r y - -
E s t e e s e l e p l o g o . Tambin h a d e s e r i g n o r a d o .
Hay cuatro subtipos del tipo multiparte, todos con la misma sintaxis general. El sr iti-
po nMdtipartefaftezdado se usa cuando hay varias partes del cuerpo independientes que
necesitan disponerse en un orden particular. Para el subtipo multiparte/paralelo, el orden
de las partes no es significativo. Si el sistema receptor es adecuado, las distintas partes pue
den presentarse en paralelo. Por ejemplo, una parte de imagen o de texto podra ir acom
paada de un comentario verbal que sonara cuando se mostraran el texto o la imagen.
Para el subtipo multiparte^alternativo las distintas partes son diferentes represen
taciones de la misma informacin. A continuacin se ofrece un ejemplo:
From: N a t h a n i e l B o r e n s t e i n <n s b @ b e l l c o r e . c o m >
I b : Ned F r e e d <n e d @ i n n o s o f t . com>
S u b j e c t : c o r r e o d e t e x t o f o r m a t e a d o
MIME-Vers i o n : 1 . 0
C b n t e n t - T y p e : mu 11 i p a r t / a l t e m a t i v e ; b o u n d a r y = b o u n d a r y 4 2
- - b o u n d a r y 4 2
C b n t e n t - T y p e : t e x t / p l a i n ; c h a r s e t = u s - a s c i i
www.FreeLibros.org
154 Fundamentos de seguridad en redes. Aplicaciones y estndares
. . . a q u v a l a v e r s i n d e t e x t o d e l m e n s a j e . . .
- - b o u n d a r y 4 2
C o n t e n t - T y p e : t e x t / e n r i c h e d
. . . a q u v a l a v e r s i n d e t e x t o e n r i q u e c i d o RFC 1 8 9 6 d e l mismo
m e n s a j e . . .
- - b o u n d a r y 4 2 - -
En este subtipo, las partes del cuerpo se ordenan en trminos de preferencia crecien
te. Para este ejemplo, si el sistema receptor es capaz de mostrar el mensaje en el forma
to texto enriquecido, lo hace; si no, se usa el formato de texto.
El subtipo multparte/resumai se usa cuando cada una de las partes del cuerpo se
interpreta como un mensaje RFC 822 con cabeceras. Este subtipo permite la construc
cin de un mensaje cuyas partes son mensajes individuales. Por ejemplo, el moderador
de un grupo podra recoger mensajes de correo electrnico de los participantes, agru
parlos y enviarlos en un mensaje MIME encapsulado.
El tipo mensaje proporciona una serie de capacidades importantes en MIME. El
subtipo mensaje'rfc822 indica que el cuerpo es un mensaje completo, que incluye
cabecera y cuerpo. A pesar del nombre de este subtipo, el mensaje encapsulado puede
ser cualquier mensaje MIME, y no slo un mensaje RFC 822.
El subtipo mcnsaje^pardal permite la fragmentacin de un mensaje largo en una
serie de partes, que deben volver a ensamblarse en el destino. Para este subtipo se espe
cifican tres parmetros en el campo Tipo de Contenido: mensaje/parcial: un identifica
dor comn a todos los fragmentos del mismo mensaje, un nmero de secuencia nico
para cada fragmento y el nmero total de fragmentos.
El subtipo maKaje'cuapo externo indica que los datos reales que se van a trans
portar en este mensaje no estn contenidos en el cuerpo. En vez de ello, el cuerpo con
tiene la informacin necesaria para acceder a los datos. Como con otros tipos de men
saje, el subtipo mensaje/cuerpo externo tiene una cabecera externa y un mensaje
encapsulado con su propia cabecera. El nico campo necesario en la cabecera externa es
el de Tipo de Contenido, que lo identifica como un subtipo mensaje/cuerpo externo. La
cabecera interna es la cabecera del mensaje para el mensaje encapsulado. El campo Tipo
de Contenido de la cabecera externa debe incluir un parmetro de tipo de acceso, que
indica el mtodo de acceso, como por ejemplo FTP (File TransferProtocol).
El tipo d e aplicacin se refiere a otros tipos de datos, generalmente datos binarios
sin interpretacin, o informacin que va a procesarse mediante una aplicacin basada en
correo.
CODIFICACIN DE TRANSFERENCIA DE MIME
El otro componente principal de la especificacin MIME, adems de la especificacin
del tipo de contenido, es una definicin de la codificacin de transferencia para cuerpos
de mensaje. El objetivo es proporcionar un envo seguro a travs de la gama ms amplia
de entornos.
El estndar MIME define dos mtodos de codificacin de datos. El campo Codifica
cin de Transferencia de Contenido en realidad puede tomar seis valores, como se mues
tra en la Tabla 5.4. Sin embargo, tres de estos valores (siete bits, ocho bits y binario)
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 155
indican que no se ha realizado la codificacin pero proporcionan informacin sobre la
naturaleza de los datos. Para la transferencia SMTP, es seguro usar la forma de siete bits.
Las formas de ocho bits y binarias se pueden utilizar en otros contextos de transporte de
correo. Otro valor de Codificacin de Transferencia de Contenido es x-token, que indi
ca que se usa algn otro esquema de codificacin, para el cual se proporciona un nom
bre. ste podra ser un esquema especfico del vendedor o de la aplicacin. Los dos
esquemas de codificacin reales definidos son imprimible textualmente (quoted-printa-
ble) y base64. Se definen dos esquemas para proporcionar una eleccin entre una tcni
ca de transferencia esencialmente legible para las personas y otra que es segura para
todos los tipos de datos en una forma razonablemente compacta.
T a b l a 5 . 4 C o d i f i c a c i n d e t r a n s f e r e n c i a d e M I M E
7 bit Todos lo s datos s e representan mediante lneas cortas de caracteres
ASCII.
8 bit Las l neas son cortas, pero podra haber caracteres que no fueran ASCII
(octetos con el bit de orden ms alto).
binario Adems de que pueden estar presentes caracteres que no sean ASCII,
las lneas no son suficientemente cortas para e l transporte SMTP.
Imprimible textualmente Codifica lo s datos de forma que s i los datos que s e estn codificando
s o n en su mayora texto ASCII, la forma codificada de los datos e s
fcilmente reconocible por l o s usuarios humanos.
base64 Codifica lo s datos convirtiendo los bloques de entrada de 6 bits en blo
ques de salida de 8 bits, todos el l o s caracteres ASCII imprimibles.
x-token Una codificacin no estndar.
La codificacin de transferencia imprimible textualmente es til cuando los datos
son en su mayora octetos que corresponden a caracteres ASCII imprimibles. Bsica
mente, representa caracteres inseguros por medio de la representacin hexadecimal de
su cdigo e introduce rupturas de lneas reversibles (suaves) para limitar las lneas del
mensaje a 76 caracteres.
La codificacin de transferencia base64 tambin conocida como codificacin radix
64, es comn para codificar datos binarios arbitrarios para que sean invulnerables al pro
cesamiento que llevan a cabo programas de transporte de correo. Tambin se usa en PGP
y se describe en el Apndice 5B.
UN EJEMPLO MULTIPARTE
La Figura 5.8, extrada del RFC 2045, es el esquema de un mensaje multiparte com
plejo. El mensaje tiene cinco partes que se muestran en serie: dos partes introducto
rias de texto claro, un mensaje multiparte insertado, una parte de texto enriquecido y
un mensaje de cierre de texto encapsulado en caracteres no ASCII. El mensaje multi
parte insertado tiene dos partes que se muestran en paralelo, una imagen y un frag
mento de audio.
www.FreeLibros.org
156 Fundamentos de seguridad en redes. Aplicaciones y estndares
FORMA CANNICA
Un concepto importante en MIME y S/MIME es el de forma cannica. Se trata de un
formato, apropiado al tipo de contenido, que est normalizado para usarse entre distin
tos sistemas. Es la opuesta a la forma nativa, que es un formato concreto para un siste
ma particular. La Tabla 5.5, del RFC 2049, ayuda a clarificar esta cuestin.
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com>
Ib: Ned Freed <ned@innosoft.com>
Subject: un ejemplo multiparte
Cbntent-iype: multpart/mixed;
boundary = unlque-boundary-1
Esto e s e l prembulo de un mensaje multiparte. Los lectores de correo que entienden e l formato multiparte
deberan ignorar este prembulo. S i est leyendo este texto, podra querer cambiar a un lector de correo
qje entienda cmo mostrar adecuadamente mensajes multiparte.
-unique boundary-1
..aqu aparece texto...
[Obsrvese que la lnea en blanco anterior significa que no se dieron campos de cabecera y que esto e s tex
to, con caracteres ASCII. Podra haberse necho escribiendo explcitamente, como en la siguiente parte.]
-unique boundary-1
Content-type: text/plain; charset= US-ASCII
Esto podra haber sido parte de la parte anterior, pero muestra la escritura explcita de las partes del cuerpo
(en contraposicin a la implcita).
-unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
-unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding:base64
...aqu van los datos de audio en ley mu de un canal nico codificado en base64 a 8000 Hz
-unique-boundary-2
Content-Type: image/jpeg
Content-TYansfer-Encoding:base64
... aqu van los datos de imagen codificados en base64
-unique-boundary-2
-unique-boundary-1
Content-type: text/enriched
Esto e s <bold><italic>texto enriquecido. </ita l i c x / bo l dxsm a l l e r > definido en RFC 1896 </smaller>
No e s <biggerxbigger>fantstico? </biggerx/bigger>
-unique-boundary-1
Content-iype: message/rfc822
From: (buzn en US-ASCII)
Tb: (direccin en US-ASCII)
Subject: (asunto en US-ASCII)
Content-iype: Text/plain; charset=ISO-8859-l
Content-TYansfer-Encoding: imprimible textualmente
...aqu va e l texto adicional en ISO-8859-1...
-unique-boundary-1 -
Figura 5.8 E j e m p l o d e e s t r u c t u r a d e m e n s a j e M I M E
www.FreeLibros.org
Captulo 5 /S e g ur i da d en el correo electrnico 1 5 7
Tabla 5 . 5 F o r m a n a t i v a y f o r m a c a n n i c a
F o r m a n a t i v a El c u e r p o q u e s e v a a t r a n s m i t i r s e cr ea e n e l f o r m a t o n a t i v o de l si s
t e m a . S e us a el c o n j u n t o d e c a r a c t e r e s n a t i v o s y , d o n d e sea a d e
c u a d o , s e us a n t a m b i n c o n v e n c i o n e s l o c a l e s d e f i n a l d e l n e a . El
c u e r p o p u e d e s e r u n a r c h i v o d e t e x t o de l e s ti lo d e U N I X , o u n a i m a
g e n e n S u n r s te r , o u n a r c h i v o i n d e x a d o V M S , o da t o s d e a u d i o en
u n f o r m a t o d e p e n d i e n t e de l s i s t e m a a l m a c e n a d o s s l o e n m e m o
r i a , o c u a l q u i e r ot r a cosa q u e c o r r e s p o n d a a l m o d e l o l o c a l p a r a la
r e p r e s e n t a c i n d e a l g u n a f o r m a d e i n f o r m a c i n . B s i c a m e n t e , l o s
d a to s s e c r e a n e n l a f o r m a n a t i v a q u e c o r r e s p o n d e a l t i p o e s p e
c if i c a d o p o r el t i p o d e m e d i o .
F o r m a c a n n i c a El c u e r p o e n t e r o , i n c l u i d a l a i n f o r m a c i n f u e r a d e b a n d a , c o m o
p o r e j e m p l o l a l o n g i t u d d e l o s r e g is t r o s y l a p o s i b l e i n f o r m a c i n
s o b r e a t r i b u t o s d e fi c h e r o s , se c o n v i e r t e a f o r m a c a n n i c a u n i v e r
sal. El t i p o d e m e d i o e s p e c f i c o de l c u e r p o y sus a t r i b u t o s a s o c i a
do s d i c t a n l a n a t u r a l e z a d e l a f o r m a c a n n i c a q u e s e usa. La c o n
v e r s i n a l a f o r m a c a n n i c a a d e c u a d a p u e d e i m p l i c a r c o n v e r s i n
de l c o n j u n t o d e c a r a c t e r e s , t r a n s f o r m a c i n d e d a t o s d e a u d i o ,
c o m p r e s i n u o t r a s o p e r a c i o n e s e s p e c fi c a s a l os d i s t i n t o s t i p o s d e
m e d i o s . S i t i e n e l u g a r l a c o n v e r s i n de l g r u p o d e c a r a c t e r e s , sin
e m b a r g o , se d e b e t e n e r c u i d a d o p a r a e n t e n d e r l a s e m n t i c a del
t i p o d e m e d i o , q u e p u e d e t e n e r se ri a s i m p l i c a c i o n e s p a r a l a c o n
v e r s i n d e c u a l q u i e r g r u p o d e c a r a c t e r e s ( p o r e j e m p l o , co n r e s
p e c t o a l o s c a r a c t e r e s s i n t c t i c a m e n t e s i g n i f i c a t i v o s e n u n s u b t i p o
d e t e x t o q u e n o sea s l o t e x t o ) .
FUNCIONALIDAD S/MIME
En trminos de funcionalidad general, S/MIME es muy similar a PGP. Los dos ofrecen
la posibilidad de firmar y/o cifrar mensajes. En este subapartado, se resume brevemen
te la capacidad de S/MIME. Luego se analizar ms detalladamente esta capacidad exa
minando los formatos de mensaje y la preparacin de mensajes.
FUNCIONES
S/MIME proporciona las siguientes funciones:
* Datos empaquetados (a nekp ed data}: consiste en contenido cifrado de cual
quier tipo y claves de cifrado de contenido cifrado para uno o ms receptores.
* Datos firmados (s & te d data}: una firma digital se forma tomando el resumen de
mensaje del contenido que se va a firmar y cifrndolo con la clave privada del fir
mante. El contenido ms la firma se codifican luego usando codificacin base64.
Un mensaje de datos firmado slo puede verlo un receptor con capacidad S/MIME.
* Datos firmados en d a r o (destr\i<?n\/data}: al igual que con los datos firmados,
se crea una firma digital del contenido. Sin embargo, en este caso, slo se codifica
la firma digital usando base64. Como resultado, los receptores sin capacidad
S/MIME pueden ver el contenido del mensaje, aunque no pueden verificar la firma.
www.FreeLibros.org
1 5 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
Datos fnnadosy anpaquetadas (si&iedandotvdopeddata): se pueden anidar
entidades slo firmadas y slo cifradas, para que los datos cifrados puedan ser fir
mados y que los datos firmados o en formato clear-signed puedan ser cifrados.
ALGORITMOS CRIPTOGRFICOS
La Tabla 5.6 resume los algoritmos criptogrficos que se usan en S/MIME S/MIME usa
la siguiente terminologa, extrada de RFC 2119 para especificar el nivel de requisitos:
Tabla 5 . 6 A l g o r i t m o s c r i p t o g r f i c o s u s a d o s e n S / M I M E
Funcin Requisito
Crea u n r e s u m e n d e m e n s a j e p a r a c r e a r
un a f i r m a d i g i t a l .
DEBE p e r m i t i r S HA- 1 .
El r e c e p t o r DEBERA s o p o r t a r M D 5 pa ra
t e n e r c o m p a t i b i l i d a d co n v e r s i o n e s
a n t e r i o r e s .
C i fr a u n r e s u m e n d e m e n s a j e p a r a c r e a r
un a f i r m a d i g i t a l .
E n v i a r y r e c i b i r a g e n t e s DEBE p e r m i t i r
DDS.
E n v i a r a g e n t e s D E B E R A p e r m i t i r c i f r a d o
RSA.
R e c i b i r a g e n t e s D E B E R A p e r m i t i r v e r i f i
c a cin d e f i r m a s R S A co n c l a v e s de
512 b i t s a 1 0 2 4 b i t s .
Cifra la c l a v e d e s e s i n p a r a su t r a n s m i
sin co n el m e n s a j e .
E n v i a r y r e c i b i r a g e n t e s DEBE s o p o r t a r
D i f f i e - H e l l m a n .
E n v i a r a g e n t e D E B E R A p e r m i t i r c i f r a d o
RSA co n c l a v e s d e 5 1 2 b i t s a 1 0 2 4 bi ts.
R e c i bir a g e n t e D E B E R A p e r m i t i r c i f ra do
RSA.
Cifra el m e n s a j e p a r a su t r a n s m i s i n
con l a cla ve d e s e sin d e u n solo
us o.
E n v i a r a g e n t e s D E B E R A p e r m i t i r c i f r a d o
co n t r i p l e DES y RC 2 / 4 0 .
R e c i bir a g e n t e s DEBE p e r m i t i r de s c i f r a d o
u s a n d o t r i p l e D E S y D E B E R A p e r m i t i r
de s c i f r a d o co n RC2 /4 0 .
DEBE: la definicin es un requisito absoluto de la especificacin. Una implemen-
tacin debe incluir esta caracterstica o funcin para ajustarse a la especificacin.
DEBERA: pueden existir razones vlidas en circunstancias particulares para
ignorar esta caracterstica o funcin, pero se recomienda que una implementacin
incluya la caracterstica o funcin.
S/MIME incorpora tres algoritmos de clave pblica. El DSS (Digital Signature Stan
dard), mencionado en el Captulo 3, es el algoritmo preferido para firmas digitales.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 159
S/MIME propone Diffie-Hellman como el algoritmo preferido para cifrar claves de
sesin; de hecho, S/MIME usa una variante de Diffie-Hellman que proporciona ci
frado/descifrado, conocida como ElGamal. Como alternativa, RSA, descrito en el Cap
tulo 3, se puede usar tanto para cifrar firmas como claves de sesin. Son los mismos
algoritmos que se usan en PGP y aportan una mayor seguridad. Para la funcin hash uti
lizada para crear la firma digital, la especificacin requiere SHA-1 de 160 bits, pero
recomienda que el receptor admita MD5 de 128 bits para lograr compatibilidad con ver
siones anteriores de S/MIME. Como se expona en el Captulo 3, hay una preocupacin
justificada por la seguridad de MD5, por lo que SHA-1 es la alternativa preferida.
Para el cifrado de mensajes, se recomienda el tripleDES de tres claves (tripleDES),
pero las implementaciones adecuadas deben dar soporte a RC2 de 40 bits. El ltimo es un
algoritmo dbil de cifrado pero se ajusta a los controles de exportacin en Estados Unidos.
La especificacin S/MIME incluye una discusin del procedimiento para decidir qu
algoritmo de cifrado de contenido usar. Bsicamente, un agente emisor puede tomar dos
decisiones. En primer lugar, el emisor debe determinar si el receptor es capaz de desci
frar usando un algoritmo de cifrado determinado. Segundo, si el receptor slo es capaz
de aceptar contenido que se ha cifrado mediante un algoritmo dbil, el emisor debe deci
dir si es aceptable enviar usando un cifrado dbil. Para apoyar este proceso de decisin,
un emisor puede anunciar sus capacidades de descifrado en orden de preferencia para
cualquier mensaje que enve. Un receptor puede almacenar esa informacin para usarla
en el futuro.
El agente emisor debera seguir las siguientes reglas, en el siguiente orden:
1. Si el emisor tiene una lista de capacidades de descifrado preferentes de un recep
tor determinado, DEBERA elegir la primera capacidad (ms alto grado de pre
ferencia) de la lista que pueda utilizar.
2. Si el emisor no dispone de dicha lista pero ha recibido uno o ms mensajes del
receptor, entonces el mensaje saliente DEBERA usar el mismo algoritmo de
cifrado que se us en el ltimo mensaje cifrado y firmado que recibi de dicho
receptor.
3. Si el emisor no tiene conocimiento de las capacidades de descifrado del recep
tor y est dispuesto a arriesgarse a que ste no pueda descifrar el mensaje, enton
ces el emisor DEBERA usar tripleDES.
4 Si el emisor no tiene conocimiento de las capacidades de descifrado del recep
tor y no est dispuesto a arriesgarse a que t e no pueda descifrar el mensaje,
entonces el agente emisor DEBE usar RC2/40.
Si un mensaje debe enviarse a mltiples receptores y no se puede seleccionar un algo
ritmo de cifrado comn para todos, entonces el emisor necesitar enviar dos mensajes.
Sin embargo, en ese caso, es importante observar que la seguridad del mensaje se hace
vulnerable por la transmisin de una copia con menor seguridad.
MENSAJES S/ MIME
S/MIME usa una serie de nuevos tipos de contenido MIME, que se muestran en la
Tabla 5.7. Todos los nuevos tipos de aplicaciones usan la designacin PKCS, que hace
www.FreeLibros.org
160 Fundamentos de seguridad en redes. Aplicaciones y estndares
referencia a un grupo de especificaciones criptogrficas de clave pblica emitidas por
RSA Laboratories y que estn disponibles para la mejora de S/MIME.
Tabla 5.7 Tipos de contenido S/MIME
Tipo Subtipo Parmetro smime Descripcin
M u l t i p a r t e F i r m a d o U n m e n s a j e f i r m a d o e n c l a r o
e n do s partes: u n a es el m e n
s a je y l a ot r a l a f i r m a .
A p l i c a c i n P kc s 7 -m ime S i g n e d D a t a
U n a e n t i d a d S / M I M E f i r m a d a .
P kc s 7 -m ime E n v e l o p e d D a t a
U n a e n t i d a d S / M I M E c i f r a d a .
P k c s 7 - m i m e d e g e n e r a t e s i g n e d
Da ta
U n a e n t i d a d q u e c o n t i e n e slo
c e r t i f i c a d o s d e c l a v e p b l i c a .
Pkcs 7-fi rma El t i p o d e c o n t e n i d o d e l a sub-
p a r t e d e f i r m a d e u n m e n s a j e
m u l t i p a r t e f i r m a d o .
P k c s 1 0 - m im e
U n m e n s a j e d e s o l i c i t u d d e
r e g i s t r o d e c e r ti fi c a d o .
Despus de examinar los procedimientos generales para la preparacin de mensajes
S/MIME, se analizar cada uno de ellos.
Asegurar una entidad MIME
S/MIME asegura una entidad MIME con una firma, con cifrado o con ambos. Una enti
dad MIME puede ser un mensaje completo (excepto las cabeceras RFC 822), o si el tipo
de contenido MIME es multiparte, entonces una entidad MIME es una o ms supartes
del mensaje. La entidad MIME se prepara de acuerdo con las reglas normales para la
preparacin de mensajes MIME. Entonces la entidad MIME ms gunos datos relacio
nados con la seguridad, como identificadores de algoritmos y certificados, son procesa
dos por MIME para producir lo que se conoce como objeto PKCS. Luego, un objeto
PKCS se trata como contenido de mensaje y se incluye en MIME (est provisto de las
cabeceras MIME apropiadas). Este proceso debera aclararse a medida que observemos
objetos especficos y algunos ejemplos.
En todos los casos, el mensaje que se va a enviar se convierte a forma cannica. En
particular, para un tipo y un subtipo dados, se usa la forma cannica adecuada para el
contenido del mensaje. En un mensaje multiparte, para cada subparte se usa la forma
cannica adecuada.
El uso de codificacin de transferencia requiere especial atencin. Para la mayora
de los casos, el resultado de aplicar el algoritmo de seguridad ser producir un objeto
representado parcial o totalmente en datos binarios arbitrarios. ste luego se agrupar en
un mensaje MIME externo y en ese punto se puede aplicar la codificacin de transfe
rencia, normalmente base64. Sin embargo, en el caso de un mensaje firmado multipar
te, que se describir ms detalladamente luego, el contenido de mensaje en una de las
subpartes no es modificado por el proceso de seguridad. A menos que el contenido sea
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 161
de siete bits, la transferencia debera codificarse usando base64 o imprimible textual
mente, para que no haya peligro de alteracin del contenido al que se aplic la firma.
A continuacin observemos cada uno de los tipos de contenido S/MIME.
Datos empaquetados ( EnvelopedData)
Un subtipo application/pkcs7-mime se usa para una de las cuatro categoras del proce
samiento S/MIME, cada una con un parmetro nico de tipo smme. En todos los casos,
la entidad resultante, a la que se conoce como objeto, se representa en una forma cono
cida como BER (Basic Encoding Rule$, que se define en la Recomendacin X.209 de
la ITU-T. El formato BER est formado por ristras de octetos arbitrarios y consiste, por
lo tanto, en datos binarios. La transferencia de dicho objeto debera ser codificada con
base64 en el mensaje MIME externo. Empecemos con envelopedData.
Los pasos para la preparacin de una entidad MIME envelopedData son los siguientes:
1. Generar una clave de sesin pseudoaleatoria para un algoritmo de cifrado sim
trico particular (RC2/40 o triple DES).
2. Para cada receptor, cifrar la clave de sesin con la clave pblica RSA del receptor.
3. Para cada receptor, preparar un bloque conocido como Recipentlnfo (informa
cin sobre el receptor) que contiene un identificador del certificado de clave
pblica del receptor3, un identificador del algoritmo utilizado para cifrar la cla
ve de sesin y la clave de sesin cifrada.
4 Cifrar el contenido de mensaje con la clave de sesin.
Los bloques Recipientlnfo seguidos del contenido cifrado constituyen los envelopedDa
ta. Esta informacin luego se codifica en base64. El siguiente es un ejemplo de mensa
je (excluyendo las cabeceras RFC 822):
C o n t e n t - T y p e : a p p l i c a t i o n / p k c s 7 - m i m e ; s m i m e - t y p e = e n v e l c p e d - d a t a ;
name=smime. p7m
G o n t e n t - T r a n s f e r - E n c o d i n g : b a s e 6 4
C b n t e n t - D i s p o s i t i o n : a t t a c h m e n t ; f i l e a m e = s m i m e .p7m
r f v b n j 756tbBghyHhHUuj hJhjH77n8HHGT9HG4VQpfyF4 67GhIGf Hf YT6
7n8HHGghyHhHu jhJh4VQpf yF467GhIGf Hf YGTr f v b n j T 6 j H7756 tbB9H
f 8HHGTrf v h J h jH776tbB9HG4VQbn j 7 5 67GhIGfHfYT6ghyHhHUu j p f y F 4
OGhIGgHfQbnj 7 5 6 YT64V
Para recuperar el mensaje cifrado, el receptor, en primer lugar, elimina la codifica
cin base64. Luego, se usa la clave privada del receptor para recuperar la clave de
sesin. Por ltimo, el contenido de mensaje se cifra con la clave de sesin.
Datos firmados ( SignedData)
El tipo smime SignedData puede usarse con uno o ms firmantes. Para aportar mayor
claridad, aplicamos nuestra descripcin al caso de una nica firma digital. Los pasos
para preparar una entidad MIME SignedData son los siguientes:
3 Este e s un certificado X.509, que se tratar ms adelante en esta seccin.
www.FreeLibros.org
162 Fundamentos de seguridad en redes. Aplicaciones y estndares
L Seleccionar un algoritmo de resumen de mensaje (SHA o MD5).
Z Calcular el resumen del mensaje, o funcin hash, del contenido que se va a firmar.
3L Cifrar el resumen de mensaje con la clave privada del firmante.
4 Preparar un bloque conocido como Signerlnfo (informacin sobre el firmante)
que contenga el certificado de clave pblica del firmante, un identificador del
algoritmo de resumen del mensaje, un identificador del algoritmo usado para
cifrar el resumen el mensaje y el resumen de mensaje cifrado.
La entidad signedData se compone de una serie de bloques, incluyendo un identifica
dor del algoritmo de resumen de mensaje, el mensaje que se est firmando y Signe
rlnfo. La entidad signedData tambin puede incluir un conjunto de certificados de cla
ve pblica suficiente para constituir una cadena que va desde una autoridad de
certificacin raz o de alto nivel, reconocida, hasta el firmante. Esta informacin lue
go se codifica en base64. El siguiente es un ejemplo de mensaje (excluyendo las cabe
ceras RFC 822):
C b n t e n t - T y p e : a p p l i c a t i o n / p k c s 7 - m i m e ; s m i m e - t y p e = s i g n e d - d a t a ;
name=smime. p7m
C b n t e n t - T r a n s f e r - E n c o d i n g : b a s e 6 4
Ctont e n t - D i s p o s i t i o n : a t t a c h m e n t ; f i l eame=smime .p7m
56 7GhIGfHdYT6ghyHhHCJuj pfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj 7
77n8HHGT9HG4 VQpf y F 4 6 7GhIGfHfYT6 r f v b n j 7 5 6tbBfhyHhHUu j h J h j H
HJu j hJh4 VQpf y F 4 6 7GhIGf HfYGTrf v b n j T6 j H 7 7 5 6 tbB9H7n8HHGghyHh
6YT6 4V0GhIGfHf Qbn j 7 5
Para recuperar el mensaje firmado y verificar la firma, el receptor elimina la codifi
cacin base64. Luego, la clave pblica del firmante se usa para descifrar el resumen del
mensaje. El receptor computa independientemente el resumen de mensaje y lo compara
con el resumen del mensaje descifrado para verificar la firma.
Firma en claro ( dear signing)
La firma en claro (clear signing) se consigue usando el tipo de contenido multiparte
con un subtipo firmado. Como ya se ha mencionado, este proceso de firma no impli
ca transformar el mensaje que se va a firmar, para que el mensaje se enve en claro.
As, los receptores con capacidad MIME pero sin S/MIME pueden leer el mensaje
entrante.
Un mensaje multiparte/firmado tiene dos partes. La primera parte puede ser cualquier
tipo MIME pero debe prepararse para que no sea modificado durante la transferencia des
de la fuente al destino. Esto significa que si la primera parte no es de siete bits, entonces
necesita ser codificada usando base64 o imprimible textualmente. Luego, esta parte se
procesa de la misma forma que signedData, pero en este caso se crea un objeto con sig
nedData que tenga un campo de contenido de mensaje vaco. Este objeto es una firma
separada. Luego la transferencia se codifica usando base64 para convertirse en la segun
da parte del mensaje multiparte firmado. Esta segunda parte tiene un tipo de contenido
MIME de aplicacin y un subtipo de firma pkcs7. Este es un ejemplo de mensaje:
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 163
C o n t e n t - T y p e : m u l t i p a r t / s i g n e d ;
p r o t o c o l = "a p p l i c a t i o n / p k c s 7 - s i g n a t u r e " ;
m i c a l g = s h a l ; b o u n d a r y = b o u n d a r y 4 2
- - b o u n d a r y 4 2
C o n t e n t - T y p e : t e x t / p l a i n
E s t e e s u n m e n s a j e f i r m a d o e n c l a r o .
- - b o u n d a r y 4 2
C o n t e n t - T y p e : a p p l i c a t i o n / p k c s 7 - s i g n a t u r e ; name=smime . p 7 s
C o n t e n t - T r a n s f e r - E n c o d i n g : b a s e 6 4
C o n t e n t - D i s p o s i t i o n : a t t a c h m e n t ; f i l e n a m e = s m i m e . p 7 s
ghyHhHUu j h J h j H7 7n8HH(?Trf v b n j 7 5 6tbB9HG4 VQpf y F467GhIGfHfHfYT6
4VQpfyF46 7GhIGf Hf YT6 jH77n8HHGghyHhHUu j hJh7 5 6tbB9HGTrf v b n j
n8HHGTr f v h j h j H77 6 tbB9HG4 VQbn j 7 5 6 7GhIGf Hf YT6ghyHbHUu j p f y F4
7GhIGfHfYT64VQbnj7 56
- - b o u n d a r y 4 2 - -
El parmetro de protocolo indica que se trata de una entidad de dos partes clear-sg-
ned. El parmetro micalg indica el tipo de resumen de mensaje usado. El receptor
puede verificar la firma tomando el resumen de mensaje de la primera parte y compa
rndolo con el resumen de mensaje recuperado de la firma en la segunda parte.
Solicitud de registro
Normalmente, una aplicacin o usuario solicitar un certificado de clave pblica a una
autoridad de certificacin. La entidad S/MIME aplicacin/pkcslO se usa para transferir
una solicitud de certificacin. Dicha solicitud incluye un bloque de informacin de so
licitud de certificacin (certifcationRequestlnfo), seguido de un identificador del al
goritmo de cifrado de clave pblica, seguido de la firma del bloque de informacin de
solicitud de certificacin, que se hace usando la calve privada del emisor. Dicho bloque
incluye un nombre del sujeto del certificado (la entidad cuya clave pblica se va a cer
tificar) y una representacin de ristra de bits de la clave pblica del usuario.
Mensaje que contiene slo certificados
Un mensaje que contenga slo certificados o una lista de revocacin de certificados
(CRL: CertifcateRevocation List) se puede enviar en respuesta a una solicitud de regis
tro. El mensaje es un tipo/subtipo aplicacin/pkcs7-mme con un parmetro del tipo smi-
me de degenerate. Los pasos necesarios son los mismos que los que se usan para crear
un mensaje signedData, a excepcin de que no hay contenido de mensaje y que el cam
po signerlnfo est vaco.
PROCESAMIENTO DE CERTIFICADOS S/MIME
S/MIME usa certificados de clave pblica que se ajustan a la versin 3 de X.509 (ver
Captulo 4). El esquema de gestin de claves utilizado por S/MIME es un hbrido entre
www.FreeLibros.org
164 Fundamentos de seguridad en redes. Aplicaciones y estndares
una jerarqua estricta de certificacin X.509 y la red de confianza de PGP. Como con el
modelo PGP, los administradores y/o usuarios de S/MIME deben configurar cada clien
te con una lista de claves fiables y con listas de revocacin de certificados. Es decir, la
responsabilidad es local para mantener los certificados necesarios para la verificacin de
las firmas entrantes y para cifrar los mensajes salientes. Por otra parte, los certificados
los firman las autoridades de certificacin.
El papel del agente usuario
Un usuario S/MIME tiene varias funciones de gestin de claves que realizar:
Generacin de claves el usuario de alguna herramienta administrativa relaciona
da (por ejemplo, una asociada con la gestin de LAN) DEBE poder generar pare
jas separadas de claves Diffie-Hellman y DSS y DEBERIA poder generar parejas
de claves RSA. Cada pareja de claves DEBE ser generada a partir de una buena
fuente de entrada aleatoria no determinstica y ser protegida de forma segura. Un
agente usuario DEBERA generar parejas de clave RSA con una longitud de entre
768 y 1024 bits y NO DEBE generar una longitud inferior a 512 bits.
Re^stro: una clave pblica de usuario debe registrarse con una autoridad de cer
tificacin para recibir un certificado de clave pblica X.509.
Almacenamiento y recuperacin de c ali ficada un usuario requiere acceso a
una lista local de certificados para verificar las firmas entrantes y para cifrar los
mensajes salientes. Esta lista podra ser mantenida por el usuario o por alguna enti
dad administrativa local en nombre de una serie de usuarios.
Certificados VeriSign
Existen varias compaas que proporcionan servicios de autoridad de certificacin (CA).
Por ejemplo, Nortel ha diseado una solucin de empresa CA y puede proporcionar
soporte S/MIME en una organizacin. Hay una serie de CA basadas en Internet, entre
las que se incluyen VeriSign, GTE y el servicio postal de Estados Unidos. De estos, el
ms usado es el servicio CA de VeriSign, del que se har una breve descripcin.
VeriSign ofrece un servicio de CA diseado para ser compatible con S/MIME y otras
aplicaciones. Emite certificados X.509 con el nombre VeriSign Digital ID. A principios
de 1998, ms de 35.000 sitios web comerciales usaban los identificadores digitales del
servidor VeriSign, y ms de un milln de identificadores digitales haban sido emitidos
a usuarios de Netscape y navegadores de Microsoft.
La informacin que contiene un identificador digital depende del tipo de identifica
dor digital y su uso. Como mnimo, cada identificador contiene:
Clave pblica del dueo.
Nombre o alias del dueo.
Fecha de caducidad del identificador digital.
Nmero de serie del identificador digital.
Nombre de la autoridad de certificacin que emiti el identificador digital.
Firma digital de la autoridad de certificacin que emiti el identificador digital.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 165
Los identificadores digitales pueden contener tambin otra informacin suministrada
por el usuario, como
Direccin.
Direccin de correo electrnico.
Informacin bsica de registro (pas, cdigo postal, edad y gnero).
Tabla 5.8 Clases de certificados de clave pblica VeriSign
Resumen de
confirmacin de
identidad
Proteccin de
dave privada de
la autoridad
emisora
Solicitante
de certificado
y proteccin
de clave privada
del suscriptor
Aplicaciones
implementadas
o contempladas
por usuarios
Clase 1 Nombr e
automatizado sin
ambigedad y
bsqueda de
direccin de correo
electrnico.
PCA: h a r d w a r e
fiable;
CA: s o w a re
f i a bl e o ha rd w a r e
fiable.
Soft war e de cifrado
(protegido con PIN)
recomendado pero
no necesario.
N a v e g a d o r y
cierto uso de
correo electrnico.
Clase 2 Igual que la clase
1, ms
comprobacin
automatizada de la
informacin de
registro ms
comprobacin
automatizada de
direccin.
PCA y CA:
h a r d w a r e fiable.
S o ft w a r e de
c ifrado (pro teg ido
con PIN) necesario.
Correo electrnico
individual y entre
empresas,
suscripciones en
lnea, sustitucin
de contraseas y
validacin de
software.
Clase 3 Igual que la clase
1, ms presencia
personal y
documentos de ID
ms la
comprobacin
au tomat i zada de
ID pa ra individuos
de la clase 2;
registros de
empresas (o
archivos) para
organizaciones.
PCA y CA:
h a r d w a r e fiable.
Soft war e de
cifrado (pro teg i do
con PIN)
necesario;
dispositivo
h a r d w a r e de
identificacin
rec o me n da do pero
no necesario.
Banca electrnica,
acceso a bases de
datos, banca
personal, servicios
en lnea basados
en miembros,
servicios de
integridad de
contenidos,
servidor de
comercio
electrnico,
validacin de
software;
autentificacin de
las LRAA; y cifrado
robusto para
ciertos servidores.
PCA: Aut or i da d de certificacin pblica pr i mar ia de VeriSi gn.
PIN: n m e r o de identificacin personal.
LRAA: a d mi n is t ra d or local de a utor idad de registro.
www.FreeLibros.org
166 Fundamentos de seguridad en redes. Aplicaciones y estndares
VeriSgn proporciona tres niveles, o clases, de seguridad para certificados de clave
pblica, como se resume en la Tabla 5.8. Un usuario solicita un certificado en lnea en
el sitio web de VeriSign u otros sitios web participantes. Las solicitudes de clase 1 y cla
se 2 se procesan en lnea, y en la mayora de los casos tardan slo unos segundos en
aprobarse. Se usan los siguientes procedimientos:
Para los identificadores digitales de la clase 1, VeriSign confirma la direccin de
correo electrnico del usuario enviando un PIN e informacin del identificador
digital a la direccin de correo electrnico suministrada en la aplicacin.
Para los identificadores digitales de la clase 2, VeriSign verifica la informacin en
la aplicacin mediante una comparacin automtica con una base de datos de con
sumidores, adems de realizar toda la comprobacin asociada a un identificador
digital de clase 1. Por ltimo, se enva la confirmacin a la direccin postal espe
cificada avisando al usuario de que se ha emitido un identificador digital en su
nombre.
Para los identificadores digitales de la clase 3, VeriSign requiere un nivel ms alto
de seguridad de la entidad. Un individuo puede probar su identidad proporcionan
do credenciales notarizadas o solicitndolo en persona.
SERVICIOS DE SEGURIDAD AVANZADA
Se han propuesto tres servicios de seguridad como borrador de Internet. Pueden cambiar
sus caractersticas y aadirse servicios adicionales. Los servicios son los siguientes:
Recibos firmados: se puede solicitar un recibo firmado en un objeto SignedDa-
ta. Devolver un recibo firmado proporciona una prueba de la entrega al creador
de un mensaje y le permite demostrar a una tercera parte que el receptor recibi
el mensaje. Bsicamente, el receptor firma el mensaje original completo ms la
firma original (del emisor) y aade la nueva firma para formar un nuevo mensa
je S/MIME.
Etiquetas de seguridad: una etiqueta de seguridad se puede incluir en los atribu
tos autentificados de un objeto SignedData. Una etiqueta de seguridad es informa
cin sobre seguridad con respecto a la confidencialidad del contenido protegido
por el encapsulado de S/MIME. Las etiquetas pueden usarse para el control del
acceso, indicando qu usuarios tienen permiso para acceder a un objeto. Tambin
se utilizan para indicar prioridad (secreta, confidencial, restringida, etc.) o para
describir qu tipo de personas pueden ver la informacin (por ejemplo, equipo
mdico de un paciente, etc.).
listas de correo segpras: cuando un usuario enva un mensaje a varios recep
tores, es necesaria una cierta cantidad de procesamiento por cada receptor, inclu
yendo el uso de la clave pblica de cada uno de ellos. El usuario puede liberar
se de este trabajo empleando los servicios de un MLA (Mail List Agent) de
S/MIME. Un MLA puede tomar un solo mensaje entrante, realizar el cifrado
especfico para cada receptor y reenviar el mensaje. El creador de un mensaje
slo necesita enviar el mensaje a la MLA, habiendo realizado el cifrado con la
clave pblica de la MLA.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 167
5 . 3 SITIOS WEB RECOMENDADOS
Sitios web recomendados:
PGP Heme PagK sitio web PGP de Network Associates, el vendedor lder de PGP
MTT Disributicn S k e f c r PGP: distribuidor lder de PGP libre. Contiene FAQ,
otra informacin y enlaces a otros sitios PGP.
S/MIME Charter: los ltimos borradores de RFC e Internet para S/MIME.
S/MIME Central: el sitio web de RSA Inc. para S/MIME. Incluye FAQ y otra
informacin til.
5 . 4 TRMINOS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
TRMINOS CLAVE
Clave de sesin
Confianza
Correo electrnico
Firma separada
PREGUNTAS DE REPASO
& L Cules son los cinco servicios principales que ofrece PGP?
5l2. Cul es la utilidad de una firma separada?
Por qu PGP genera una firma antes de aplicar la compresin?
S 4 Qu es la conversin R64?
5lS Por qu es la conversin R64 til para una aplicacin de correo electrnico?
5l& Por qu es necesaria la funcin de segmentacin y reensamblado en PGP?
&7. Cmo usa PGP el concepto de confianza?
Qu es RFC 822?
a a Qu es MIME?
a i f t Qu es S/MIME?
PROBLEMAS
5l1. PGP usa el modo CFB (Cpher FeedBacfy de CAST-128, mientras que la
mayora de las aplicaciones de cifrado (diferentes del cifrado de claves) usan
el modo CBC (cpher block chaning). Tenemos
CBC: C= EfQ_i P; P = C_\ 0 DC]
CFB: C= Py FjdCj-iY, P/ = C EK[C.{\
MIME (Multipurpose In- S/MIME
temet Mail Extensons) ziP
PGP (Pretty Good Privacfi
Radix 64
www.FreeLibros.org
168 Fundamentos de seguridad en redes. Aplicaciones y estndares
Los dos parecen proporcionar la misma seguridad. Razona por qu PGP utili
za el modo CFB.
5l& Los primeros 16 bits del resumen del mensaje en una firma PGP se traducen
en claro.
} Hasta qu punto compromete este hecho la seguridad del algoritmo hash?
b) Hasta qu punto realiza realmente la funcin de ayudar a determinar si se
us la clave RSA correcta para descifrar el resumen?
5l3L En la Figura 5.4, cada entrada en el fichero de claves pblicas contiene un
campo de confianza en el propietario que indica el grado de confianza asocia
da a ese dueo de clave pblica. Por qu no es suficiente con eso? Es decir,
si este propietario es fiable y se supone que esa es la clave pblica del dueo,
por qu no es eso suficiente para permitir que PGP use esta clave pblica?
5l4 Consideremos la conversin radix 64 como una forma de cifrado. En este caso
no hay clave. Pero supongamos que un oponente supiera slo que se estaba
usando algn algoritmo de sustitucin para cifrar el texto en ingls. En qu
grado sera efectivo este algoritmo contra el criptoanlisis?
5.5. Phil Zimmermann eligi los algoritmos de cifrado simtrico IDEA, triple DES
de tres claves y CAST-128 para PGP. Razona por qu cada uno de los siguien
tes algoritmos de cifrado simtrico descritos en este libro es adecuado o no
para PGP: DES, triple DES de dos claves, Blowfish y RC5.
APNDICE 5 A COMPRESIN DE DATOS U SANDO Z IP
PGP hace uso de un paquete de compresin llamado ZIP, escrito por Jean-lup Gailly,
Mark Adler y Richard Wales. ZIP es un paquete freeware escrito en C que se ejecuta
como una utilidad en UNIX y otros sistemas. Funcionalmente es equivalente a PKZIP, un
paquete Shareware muy utilizado para sistemas Windows desarrollados por PKWARE,
Inc. El algoritmo Zip es quizs la tcnica de compresin ms usada por distintas plata
formas; las versiones freeware y Shareware estn disponibles para Macintosh y otros sis
temas, as como para Windows y UNIX.
Zip y algoritmos similares son el producto de la investigacin de Jacob Ziv y Abra-
ham Lempel. En 1977, describieron un tcnica basada en un buffer de ventana con
desplazamiento que contiene los textos procesados ms recientemente [ZIV77]. Este
algoritmo se conoce generalmente como LZ77. Se usa una versin de este algoritmo en
el esquema de compresin zip (PKZIP, gzip, zipit, etc.).
LZ77 y sus variantes explotan el hecho de que las palabras y las frases de un flujo de
texto (patrones de imagen en el caso de GIF) podran repetirse. Cuando se produce una
repeticin, la secuencia repetida puede reemplazarse por un cdigo corto. El programa de
compresin busca las repeticiones y desarrolla cdigos sobre la marcha para reemplazar
la secuencia repetida. De vez en cuando, los cdigos se reutilizan para capturar nuevas
secuencias. El algoritmo debe definirse de forma que el programa de descompresin pue
da deducir la correspondencia real entre cdigos y secuencias de datos fuente.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 1 6 9
t h e brown f ox jumped o v e r t h e brown foxy jumping f r o g
t-26 t ____________
L27--------------
t h e brown f o x jurrped o v e r 0/,2613 y i n g f r o g
13
Figura 5.9 Ejemplo de esquema LZ77
Antes de fijamos en los detalles de LZ77, observemos un ejemplo sencillo4. Consi
deremos la frase sin sentido
The brown f ox jumped o v e r t h e brown foxy jurrping f r o g
con una extensin de 53 octetos = 424 bits. El algoritmo procesa este texto de izquierda
a derecha. Inicialmente, cada carcter se corresponde con un patrn de nueve bits que
consiste en un 1 binario seguido de la representacin ASCII de ocho bits del carcter. A
medida que avanza el procesamiento, el algoritmo busca secuencias repetidas. Cuando
se encuentra una repeticin, el algoritmo contina buscando hasta que la repeticin ter
mina. En otras palabras, cada vez que se produce una repeticin, el algoritmo incluye
todos los caracteres posibles. La primera secuencia encontrada es tibe brown fax Esta
secuencia se sustituye por un puntero a la secuencia anterior y la longitud de la secuen
cia. En este caso la secuencia anterior a te tmvwn fo x ocurre 26 posiciones de caracte
res antes y la longitud de la secuencia es de 13 caracteres. Para este ejemplo, asumimos
dos opciones para la codificacin; un puntero de ocho bits y una longitud de cuatro bits,
o un puntero de doce bits y una longitud de seis bits; una cabecera de dos bits indica qu
opcin se elige, con 00 indicando la primera opcin y 01 la segunda. As, la segunda
aparicin de te bntw n fa x se codifica como <00/^x260x1300 o 00 00011010 1101.
Las partes que quedan del mensaje comprimido son la letra y; la secuencia
<00/px27><5oO, que sustituye la secuencia formada por el carcter de espacio segui
do d e / i n j p y la secuencia de caracteres h tg fm g
La Figura 5.9 ilustra las correspondencias de compresin. El mensaje comprimido se
compone de 35 caracteres de nueve bits y dos cdigos, para un total d e 3 5 x 9 + 2 x 14
= 343 bits. Esto se compara con los 424 bits del mensaje descomprimido para un ratio
de compresin de 1.24.
ALGORITMO DE COMPRESIN
El algoritmo de compresin para LZ77 y sus variantes hacen uso de dos buffers. Un buf-
ifrhfeMrko deslizante contiene los ltimos ^caracteres de los datos de entrada que se
han procesado, y un b u ffird e entrada contiene los siguientes L caracteres que se van a
procesar (Figura 5.10a). El algoritmo intenta hacer coincidir dos o ms caracteres del
principio del buffer de entrada con una ristra del buffer histrico de desplazamiento. Si
no se encuentran coincidencias, el primer carcter del buffer de entrada se devuelve
como un carcter de nueve bits y tambin se desplaza en la ventana deslizante, con lo
cual se elimina el carcter ms antiguo de la misma. Si se encuentra una coincidencia,
el algoritmo contina buscando la coincidencia ms larga. Entonces la ristra coinciden
4 Basado en un ejemplo de [WEIS93).
www.FreeLibros.org
170 Fundamentos de seguridad en redes. Aplicaciones y estndares
te se devuelve en forma de terceto (indicador, puntero, longitud). Para una ristra de K
caracteres, los K caracteres ms antiguos en la ventana deslizante se retiran, y los A
caracteres de la ristra codificada se introducen en la ventana
La Figura 5.10b muestra la operacin de este esquema en nuestra secuencia de ejem
plo. La ilustracin asume una ventana deslizante de 39 caracteres y un buffer de entra
da de 13 caracteres. En la parte superior del ejemplo, los primeros 40 caracteres se han
procesado y la versin descomprimida de los 39 caracteres ms recientes est en la ven
tana deslizante. Lo que queda se encuentra en la ventana de entrada. El algoritmo de
compresin determina la siguiente coincidencia, traspasa 5 caracteres del buffer de
entrada a la ventana con desplazamiento, y extrae el cdigo para esta ristra. El estado del
buffer despus de estas operaciones se muestra en la parte inferior del ejemplo.
Mientras LZ77 es efectivo y se adapta a la naturaleza de la entrada actual, tiene algu
nas desventajas. El algoritmo usa una ventana finita para buscar coincidencias en el tex
to anterior. Para un bloque muy largo de texto, comparado con el tamao de la ventana,
se eliminan muchas posibles coincidencias. El tamao de la ventana se puede aumentar,
pero esto trae consigo dos consecuencias negativas: (1) el tiempo de procesamiento del
algoritmo aumenta porque debe realizar una comparacin de ristras con el buffer de
entrada para cada posicin de la ventana deslizante, y (2) el campo <puntero> debe ser
ms largo para ajustarse a los saltos ms largos.
desplazamiento
texto fuente
-Fuente
Texto de salida
comprimido
(a) Estructura general
he brown fox jumped over the brown foxy jumping frog
cwn fox junped over the brown foxy jump ing frog
(b) Ejemplo
Figura 5.10 Esquema LZ77
ALGORITMO DE DESCOMPRESIN
La descompresin de texto comprimido LZ77 es sencilla. El algoritmo de descompre
sin debe guardar los ltimos N caracteres de la salida descomprimida. Cuando se
encuentra una ristra codificada, el algoritmo de descompresin usa los campos <punte
r o y <longitud> para reemplazar el cdigo con la ristra real de texto.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 171
APNDICE 5B CONVERSIN R A D I X 6 4
Tanto PGP como S/MIME hacen uso de una tcnica de codificacin conocida como
conversin radix 64. Esta tcnica convierte entradas binarias arbitrarias en salidas de
caracteres imprimibles. Su forma de codificacin tiene las siguientes caractersticas:
1. El rango de la funcin es un grupo de caracteres representable universalmente
en todos los sitios, no una codificacin binaria especfica de ese grupo de carac
teres. As, los propios caracteres se pueden codificar en cualquier forma que sea
necesaria para un sistema especfico. Por ejemplo, el carcter E se representa
en un sistema basado en ASCII como 45 hexadecimal y en un sistema basado en
EBCDIC como C5 hexadecimal.
2. El grupo de caracteres consiste en 65 caracteres imprimibles, uno de los cuales
se usa para relleno. Con 26 = 64 caracteres disponibles, cada carcter se puede
usar para representar seis bits de entrada.
& No se incluyen caracteres de control en el grupo. As, un mensaje codificado en
radix 64 puede atravesar sistemas de correo que comprueben el flujo de datos en
busca de caracteres de control.
4 No se usa el carcter guin (-). Debido a que este carcter es significativo en
el formato RFC 822 debera evitarse aqu.
La Tabla 5.9 muestra las correspondencias de los valores de entrada de seis bits con los
caracteres. El grupo de caracteres consiste en los caracteres alfanumricos ms + y
/. El carcter = se usa como carcter de relleno.
T a b l a 5 . 9 Codificacin radix 6 4
Valor de Codificacin Valor Codificacin Valor Codificacin Valor Codificacin
6 bits del carcter de 6 bits del carcter de 6 bits del carcter de 6 bits del carcter
0 A 16 Q
32
9
4 8 w
1 B 17 R 3 3 h 4 9 X
2 C 18 S 3 4 i 5 0
y
3 D 19 T 3 5
i
51 z
4 E 20 U 3 6 k 52 0
5 F 21 V 37 I 5 3 1
6 G 22 w 3 8 m 5 4 2
7 H 2 3 X 3 9 n 5 5 3
8 I 24 Y 40 o 56 4
9 J 25 z 41
P
57 5
10 K 26 a 42
q
58 6
11 L 27 b 43 r 59 7
12 M 28 c 4 4 s 6 0 8
13 N 29 d 45 t 61 9
14 0 30 e 4 6 u 62 +
15 P 31 f 47 V 63
R e l l e
no
/
www.FreeLibros.org
172 Fundamentos de seguridad en redes. Aplicaciones y estndares
24 bi ts------------------------------------------
< ----------------------------------------------4 caracteres = 32 bits
Figura 5.11 Codificacin imprimible de datos binarios en formato radix 64
La Figura 5.11 ilustra el esquema simple de correspondencias. La entrada binaria se
procesa en bloques de tres octetos, o 24 bits. Cada grupo de seis bits en el bloque de 24
bits se convierte en un carcter. En la figura, los caracteres se muestran codificados
como cantidades de ocho bits. En este caso tpico, cada entrada de 24 bits se expande a
una salida de 32 bits.
Por ejemplo, consideremos la secuencia de texto de 24 bits 00100011 01011100
10010001, 235C91 en hexadecimal. S se organiza esta entrada en bloques de seis bits,
se obtiene:
001000 110101 110010 010001
Los valores decimales de seis bits extrados son 8, 53, 50, 17. Buscarlos en la Tabla
5.9 da como resultado los siguientes caracteres con codificacin radix 64: IlyR. S estos
caracteres se almacenan en formato ASCII de ocho bits con el bit de paridad fijado a
cero, tenemos
01001001 00110001 01111001 01010010
En hexadecimal corresponde a 49317952. Para resumir,
Dates d e entrada
Representacin binaria 00100011 01011100 10010001
Representacin hexadecimal 235C91
Codificacin radix 64 d e datos de nitrada
Representacin de caracteres I lyR
Cdigo ASCII (8 bits, paridad cero) 01001001 00110001 01111001 01010010
Representacin hexadecimal 49317952
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 173
APNDICE 5 C GENERACIN DE NMEROS ALEATORIOS DE PGP
PGP usa un esquema complejo y potente para generar nmeros aleatorios y nmeros
pseudoaleatorios para una gran variedad de propsitos. PGP genera nmeros aleatorios
del contenido y el tiempo de las pulsaciones de tecla del usuario, y nmeros pseudoale
atorios usando un algoritmo basado en el de ANSI X9.17. PGP usa estos nmeros con
la siguiente finalidad:
Nmeros aleatorios:
usados para generar parejas de claves RSA
proporcionan la semilla inicial para el generador de nmeros pseudoaleatorios
proporcionan entrada adicional durante la generacin de nmeros pseudoaleatorios
* Nmeros pseudoaleatorios:
usados para generar claves de sesin
usados para generar vectores de inicializacin para ser usados con la clave de
sesin en el cifrado en modo CFB
NMEROS ALEATORIOS
PGP tiene un buffer de 256 bytes de bits aleatorios. Cada vez que PGP espera una pul
sacin en el teclado, graba la hora, en formato de 32 bits, a la que empieza a esperar.
Cuando recibe la pulsacin, registra la hora a la que se puls la tecla y el valor de ocho
bits de la pulsacin. La informacin de tiempo y la pulsacin se usan para generar una
clave que, a su vez, se usa para cifrar el valor actual del buffer de bits aleatorios.
NMEROS PSEUDOALEATORIOS
La generacin de nmeros pseudoaleatorios hace uso de una semilla de 24 octetos y pro
duce una clave de sesin de 16 octetos, un vector de inicializacin de ocho octetos y una
nueva semilla para la generacin de los prximos nmeros pseudoaleatorios. El algorit
mo usa las siguientes estructuras de datos:
1. Entrada
randseed.bin (24 octetos): si el fichero est vaco, se llena con 24 octetos alea
torios.
mensaje: la clave de sesin y el vector de inicializacin que se van a usar para
cifrar un mensaje son por s mismos una funcin de ese mensaje. Esto contri
buye a la aleatoriedad de la clave y el vector de inicializacin, y si un oponente
ya conoce el contenido en texto claro del mensaje, no hay necesidad aparente
de capturar la clave de sesin de un solo uso.
2. Salida
K (24 octetos): los primeros 16 octetos, K[0.. 15], contienen una clave de sesin,
y los ltimos ocho octetos, K[16..23], contienen un vector de inicializacin.
randseed.bin (24 octetos): se coloca una nueva semilla en este fichero.
www.FreeLibros.org
174 Fundamentos de seguridad en redes. Aplicaciones y estndares
K [ 1 6 . . 2 3 ] K [ 8 . . 15] K[0 . . 7 ]
Figura 5.12 Generacin de clave de sesin y vector de inicializacin PGP
(pasos desde G2 hasta G8)
3L Estructuras internas de datos
dtbuf (ocho octetos): los primeros cuatro octetos, dtbuf[0..3], se inicializan
con el valor actual de fecha y hora. Este buffer equivale a la variable DT en el
algoritmo X I 2.17.
rkey (16 octetos): se usa la clave de cifrado CAST-128 en todas las fases del
algoritmo.
rseed (ocho octetos): equivalente a la variable X12.17 V/.
rbuf (ocho octetos): un nmero pseudoaleatorio generado por el algoritmo.
Este buffer equivale a la variable X12.17
K (24 octetos); buffer temporal para el nuevo valor de randseed.bin.
El algoritmo se compone de nueve pasos, desde G1 hasta G9. El primero y el ltimo
pasos son pasos de confusin, que tienen la finalidad de reducir el valor de un fichero
randseed.bin capturado a un oponente. Los pasos restantes equivalen bsicamente a tres
iteraciones del algoritmo X12.17 y se ilustran en la Figura 5.12. Para resumir,
G l. [Predmrinar (preuash) la semilla anterior]
a) Copiar randseed.bin en K[0..23].
b) Tomar el hash del mensaje (ste ya se ha generado si el mensaje se est fir
mando; si no, se usan los octetos de los primeros 4K del mensaje). Usar el
resultado como clave, usar un vector de inicializacin nulo y cifrar K en
modo CFB; almacenar el resultado en K.
G2. [Establera la samDa inicial)
a) Fijar dtbuf[0..3] a la hora local de 32 bits. Fijar dtbuf[4..7] todo a cero.
Copiar rkey <K[0.. 15]. Copiar rseed K[16..23].
b) Cifrar el dtbuf de 64 bits usando el rkey de 128 bits en modo ECB; almace
nar el resultado en dtbuf.
www.FreeLibros.org
Captulo 5 / Seguridad en el correo electrnico 175
G3L [Preparar para generar octetos aleatorios) Fijar rcount <- 0 y k <- 23. El
bucle de pasos G4-G7 se ejecutar 24 veces (k = 23...0), una vez por cada octe
to aleatorio generado y situado en K. La variable rcount es el nmero de octe
tos aleatorios no utilizados en rbuf. Contar hacia atrs de 8 a 0 tres veces para
generar los 24 octetos.
G 4 [Bytes disponibles?] Si rcount = 0 ir a G5, s no, ir a G7. Los pasos G5 y G6
realizan una instancia del algoritmo X I 2.17 para generar un nuevo batch de
ocho octetos aleatorios.
G5l [Generar nuevos octetos aleatorios]
a) rseed rseed dtbuf.
b) rbuf <A^frseed] en modo ECB.
G& [Generar b d g rim te sn n lia l
a) rseed <- rbuf dtbuf.
b) rseed ^^ r s e e d ] en modo ECB.
c) Fijar rcount <8.
G7. [Transferir un bit cada vez desde ib u f a K]
a) Fijar rcount <- rcount - 1.
b) Generar un byte aleatorio b, y fijar K[k] rbuf[rcount] b.
G& [Hedi?] S i k = O i r a G9 s i no fijar k - 1 e ir aG 4
G9L [Postdnmnar (postwash) la sandia y devolver resultado]
a) Generar 24 bytes ms con el mtodo de los pasos G4-G7, pero no aplicar el
XOR a un byte aleatorio en G7. Colocar el resultado en el buffer K.
b) Cifrar K con la clave Af[0..15] y el vector de inicializacin ATJ16..23] en
modo CFB; almacenar el resultado en randseed.bin.
c) Devolver A.
No debera ser posible determinar la clave de sesin a partir de los 24 nuevos octetos
generados en el paso G9.a. Sin embargo, para garantizar que el fichero randseed.bin
almacenado no proporciona informacin sobre la clave de sesin ms reciente, los 24
nuevos octetos se cifran y el resultado se almacena como la nueva semilla.
Este algoritmo elaborado debera proporcionar nmeros pseudoaleatorios criptogr
ficamente robustos.
www.FreeLibros.org
www.FreeLibros.org
C A P T U L O 6
Seguridad IP
6.1 Introduccin a la seguridad IP
A p l i c a c i o n e s d e I P S e c
B e n e f i c i o s d e I P S e c
A p l i c a c i o n e s d e e n r u t a m i e n t o
6.2 Arquitectura de seguridad IP
D o c u m e n t o s d e I P S e c
S e r v i c i o s I P S e c
A s o c i a c i o n e s d e s e g u r i d a d
M o d o t r a n s p o r t e y m o d o t n e l
6.3 Cabecera de autentificacin
S e r v i c i o c o n t r a r e p e t i c i o n e s
V a l o r d e c o m p r o b a c i n d e i n t e g r i d a d
M o d o s t r a n s p o r t e y t n e l
6.4 Encapsulamiento de la carga til de seguridad
E l f o r m a t o E S P
A l g o r i t m o s d e c i f r a d o y a u t e n t i f i c a c i n
R e l l e n o
M o d o t r a n s p o r t e y m o d o t n e l
6.5 Combinacin de asociaciones de seguridad
A u t e n t i f i c a c i n m s c o n f i d e n c i a l i d a d
C o m b i n a c i o n e s b s i c a s d e a s o c i a c i o n e s d e s e g u r i d a d
6.6 Gestin de claves
P r o t o c o l o d e d e t e r m i n a c i n d e c l a v e s O a k l e y
I S A K M P
6.7 Bibliografa y sitios w e b recomendados
6.8 Trminos clave, preguntas de repaso y problemas
T r m i n o s c l a v e
P r e g u n t a s d e r e p a s o
P r o b l e m a s
Apndice 6A Comunicacin entre redes y protocolos de internet
E l p a p e l d e u n p r o t o c o l o d e I n t e r n e t
I P v 4
I P v 6
www.FreeLibros.org
1 7 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
S un espa divulga una noticia secreta antes de que sea e l momento oportuno, debe ser ejecu
tado, junto con e l hombre a quien revel e l secreto.
E l arte de la p o ra, Sun Tzu
L
a comunidad de Internet ha desarrollado mecanismos de seguridad para aplica
ciones especficas en una serie de reas como, por ejemplo, correo electrnico
(S/MIME, PGP), cliente/servidor (Kerberos), acceso a l a Web (SSL, Secure Soc-
kets Layer), entre otras. Sin embargo, los usuarios tienen preocupaciones relativas a la
seguridad que rebasan las capas de protocolos. Por ejemplo, una empresa puede hacer
que su red privada TCP/IP sea segura desautorizando conexiones a sitios no fiables,
cifrando paquetes que salen de sus instalaciones y autentificando los paquetes que se
reciben. Implementando la seguridad en el nivel de IP, una organizacin puede conse
guir una red segura no slo para las aplicaciones que poseen mecanismos de seguridad,
sino tambin para las aplicaciones que no los tienen.
La seguridad IP abarca tres reas funcionales: autentificacin, confidencialidad y
gestin de claves. El mecanismo de autentificacin garantiza que un paquete recibido,
de hecho, fue transmitido por la parte identificada como fuente u origen en la cabecera
del paquete. Adems, este mecanismo asegura que el paquete no ha sido alterado duran
te la transmisin. La herramienta de confidencialidad permite que los nodos que se
comunican cifren los mensajes para prevenir escuchas de terceras partes. La herramien
ta de gestin de claves se ocupa del intercambio seguro de claves.
Este Captulo comienza con una descripcin general de la seguridad IP (IPSec) y una
introduccin a la arquitectura de IPSec. Luego, se estudia en profundidad cada una de
las tres reas funcionales. A su vez, el apndice de este Captulo repasa los protocolos
de Internet.
6.1 INTRODUCCIN A LA SEGURIDAD IP
En 1994, el Comit de Arquitectura de Internet (IAB: Internet Architecture Board) publi
c un informe titulado Seguridad en la arquitectura de Internet (RFC 1636). El informe
manifestaba el consenso general sobre la necesidad de una mayor y mejor seguridad en
Internet, e identificaba las reas fundamentales para los mecanismos de seguridad. Entre
stas se encontraba la necesidad de proteger la infraestructura de la red de la observacin
y el control no autorizados del trfico de red, as como la necesidad de asegurar el trfi
co entre usuarios finales utilizando mecanismos de autentificacin y cifrado.
Estas preocupaciones estn del todo justificadas. Como prueba, el informe anual de
2001 del Equipo de Respuesta a Emergencias en Computadores o CERT (Computer
Emergency Response Team) informaba sobre ms de 52.000 incidentes de seguridad.
Los tipos de ataque ms graves incluan los falsos IP, en los que los intrusos crean paque
tes con direcciones IP falsas y explotan las aplicaciones que usan autentificacin basa
da en IP; y distintas formas de escucha y captura de paquetes, donde los atacantes leen
la informacin transmitida, incluida la de conexin al sistema y la de los contenidos de
bases de datos.
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 1 7 9
En respuesta a estas cuestiones, la IAB incluy la autentificacin y el cifrado como
caractersticas necesarias de seguridad en el IP de nueva generacin, que se conoce
como IPv6. Afortunadamente, estas capacidades de seguridad se disearon para que fue
ran empleadas con el actual IPv4 y el futuro IPv6. Esto significa que los fabricantes ya
pueden empezar a ofrecer estas caractersticas, y ya muchos de ellos han incorporado
algunas capacidades de IPSec a sus productos.
APLICACIONES DE IPSEC
IPSec proporciona la capacidad de asegurar las comunicaciones a travs de una LAN,
de una WAN privada y pblica y de Internet. Los siguientes son algunos ejemplos de
su uso:
Conexin segpra entre oficinas sucursales a travs de IatOMb una compaa
puede construir una red virtual privada y segura a travs de Internet o de una
WAN pblica Esto permite que una empresa se apoye fuertemente en Internet y
reduzca su necesidad de redes privadas, disminuyendo gastos y costes en la ges
tin de red.
Acceso ranoto seg^iro a travs d e Internet: un usuario final cuyo sistema est
dotado de protocolos de seguridad IP puede hacer una llamada local a su prove
edor de servicios de Internet (ISP, Internet Service Providei) y acceder de forma
segura a la red de una compaa. Esto reduce los gastos de los empleados que se
tienen que desplazar y de los empleados a distancia.
Establednraito d e conedn extrae* e Intranet con socios: IPSec se puede
usar para hacer que las comunicaciones con otras organizaciones sean seguras,
garantizando la autentificacin y la confidencialidad y proporcionando un meca
nismo de intercambio de claves.
Mejora de la seguridad en d comerdo electrnico: aunque algunas aplicacio
nes web y de comercio electrnico tienen incorporados protocolos de seguridad,
el uso de IPSec mejora la seguridad.
La caracterstica principal de IPSec que permite dar soporte a esta variedad de apli
caciones es que puede cifrar y/o autentificar todo el trfico en el nivel IP. Por lo tanto,
pueden asegurarse todas las aplicaciones distribuidas, incluyendo conexin remota,
cliente/servidor, correo electrnico, transferencia de ficheros, acceso a la web, etc.
La Figura 6.1 representa un ejemplo comn del uso de IPSec. Una organizacin tie
ne algunas LAN en lugares dispersos. En cada LAN hay trfico IP que no es seguro. Los
protocolos IPSec se utilizan para el trfico exterior, a travs de una WAN privada o
pblica. Estos protocolos operan en dispositivos de red, como por ejemplo un router o
un cortafuegos, que conecta cada LAN al mundo exterior. El dispositivo de red IPSec
cifrar y comprimir todo el trfico que entre en la WAN, y descifrar y descomprimir
todo el trfico que provenga de ella; estas operaciones son transparentes a las estaciones
de trabajo y a los servidores en la LAN. Tambin es posible la transmisin segura con
usuarios individuales que se conectan a la WAN. Dichas estaciones de trabajo de usua
rios deben implementar los protocolos IPSec para proporcionar seguridad.
www.FreeLibros.org
180 Fundamentos de seguridad en redes. Aplicaciones y estndares
Red p b l i c a (I n te rn e t)
o pr iv a d a
IPSec,
D i s p o s i t i v o d e red
con IPSec
C a b e c e r a C a r g a t i l
IP I P
Sistema del usuario,.
c o n I P S e c I C a b e c e r a C a b e c e r a
I P S e c
C a r g a t i l
I P s e g u r a
Figura 6.1 Entorno de seguridad IP
BENEFICIOS DE IPSEC
En [MARK97] se presentan los siguientes beneficios de IPSec:
Cuando IPSec se implementa en un cortafuegos o un router, proporciona una gran
seguridad que se puede aplicar a todo el trfico que lo cruza. El trfico en una
compaa o grupo de trabajo no provoca costes adicionales de procesamiento
relativo a la seguridad.
IPSec es seguro en un cortafuegos si se obliga a que todo el trfico que proviene
del exterior use IP, y el cortafuegos es el nico medio de entrada desde Internet a
la organizacin.
IPSec est por debajo de la capa de transporte (TCP, UDP) y, por ello, es trans
parente a las aplicaciones. No es necesario cambiar el software en el sistema de
un usuario o de un servidor cuando IPSec se implementa en el cortafuegos o el
router. Incluso si IPSec se implementa en sistemas finales, el soware de nivel
superior, incluyendo aplicaciones, no se ve afectado.
IPSec puede ser transparente a usuarios finales. No es necesario entrenar a los
usuarios para la utilizacin de mecanismos de seguridad, ni suministrar material
relativo al uso de claves por cada usuario, ni inhabilitar dicho material cuando los
usuarios abandonan la organizacin.
IPSec puede proporcionar seguridad a usuarios individuales s es necesario, lo
cual es til para trabajadores externos y para establecer una subred virtual segu
ra en una organizacin para las aplicaciones confidenciales.
www.FreeLibros.org
Captulo 6 / Seguridad IP 1 8 1
APLICACIONES DE ENRUTAMIENTO
Adems de dar soporte a usuarios finales y proteger los sistemas y las redes de las ins
talaciones de la organizacin, IPSec puede desempear un papel fundamental en la
arquitectura de enrutamiento necesaria para la comunicacin entre redes. [HUIT98]
ofrece una serie de ejemplos del uso de IPSec. IPSec puede garantizar que:
Un anuncio de router (un nuevo router anuncia su presencia) procede de un rou-
ter autorizado.
Un anuncio de un router vecino (un router intenta establecer o mantener una rela
cin con un router en otro dominio de enrutamiento) viene de un router autorizado.
Un mensaje redirigido proviene del router al que se envi el paquete inicial.
Una actualizacin de enrutamiento no se falsifica.
Sin estas medidas de seguridad, un oponente puede interrumpir las comunicaciones o
desviar el trfico. Los protocolos de enrutamiento como OSPF deberan ejecutarse por
encima de las asociaciones de seguridad entre routers que estn definidos por IPSec.
6 . 2 ARQUITECTURA DE SEGURIDAD IP
La especificacin IPSec se ha hecho muy compleja. Para entender la arquitectura gene
ral, en primer lugar, conviene observar los documentos que definen IPSec. Luego se tra
tan los servicios de IPSec y se introduce el concepto de asociacin de seguridad.
DOCUMENTOS DE IPSEC
La especificacin IPSec se compone de numerosos documentos. Los ms importantes
de ellos, publicados en noviembre de 1998, son los RFC 2401, 2402, 2406 y 2408:
RFC 2401: descripcin general de una arquitectura de seguridad
RFC 2402: descripcin de la extensin de autentificacin de un paquete a IPv4 e
IPv6
RFC 2406: descripcin de la extensin de cifrado de un paquete a IPv4 e IPv6
RFC 2408: especificacin de las capacidades de gestin de claves
Permitir estas caractersticas es obligatorio para IPv6 y opcional para IPv4. En ambos
casos, las caractersticas de seguridad se implementan como cabeceras de extensin que
siguen a la cabecera IP principal. La cabecera de extensin para la autentificacin se
conoce como cabecera de autenticacin (AH, Authenticaton Header)\ y para el cifra
do se conoce como cabecera de encapsulado de carga til de seguridad (ESP, Encap-
sulating Security Payload header) .
Adems de estos cuatro RFC, el grupo de trabajo (SecurityProtocol WorkingGroup),
creado por la IETF, ha publicado una serie de borradores adicionales. Los documentos
se dividen en siete grupos, como se muestra en la Figura 6.2 (RFC 2401):
Aquhectura: cubre los conceptos generales, los requisitos de seguridad, las defi
niciones y los mecanismos que definen la tecnologa IPSec.
www.FreeLibros.org
182 Fundamentos de seguridad en redes. Aplicaciones y estndares
Encapsulado d e carga tfl desegiridad (ESP): cubre el formato del paquete y
los aspectos generales relacionados con el uso de ESP para el cifrado de paque
tes y, de manera opcional, para la autentificacin.
Figura 6.2 E s q u e m a g e n e r a l d e d o c u m e n t o I P S e c
Cabecera d e autentificarin (AH): cubre el formato del paquete y los aspectos
generales relacionados con el uso de AH para la autentificacin de paquetes.
Algoritmo d e cifrados un conjunto de documentos que describen cmo se utili
zan distintos algoritmos de cifrado para ESP.
Algoritmo d e autentificacin: un conjunto de documentos que describen cmo
se utilizan distintos algoritmos de autentificacin para AH y para la opcin de
autentificacin de ESP.
Gestin de daves: documentos que describen los esquemas de gestin de claves.
Dominio d e interpretacin (DOI: Domain o fln ta p i &atian): contiene los valo
res necesarios para que los dems documentos se relacionen entre s. Estos inclu
yen identificadores para algoritmos aprobados de cifrado y de autentificacin, as
como parmetros operativos como el tiempo de vida de las claves.
SERVICIOS IPSEC
IPSec proporciona servicios de seguridad en la capa IP permitiendo que un sistema eli
j a los protocolos de seguridad necesarios, determine los algoritmos que va a usar para el
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 183
servicio o servicios y ubique las claves criptogrficas necesarias para proporcionar los
servicios solicitados. Se usan dos protocolos para proporcionar seguridad: un protocolo
de autentificacin designado por la cabecera del protocolo, AH, y un protocolo combi
nado de ciffado/autentificacin designado por el formato del paquete para ese protoco
lo, ESP. Los servicios son los siguientes:
Control de acceso.
Integridad sin conexin.
Autentificacin del origen de datos.
Rechazo de paquetes reenviados.
Confidencialidad (cifrado).
Confidencialidad limitada del flujo de trfico.
Tabla 6.1 S e r v i c i o s d e IP S e c
E S P (c i fr a do
AH E S P ( s l o c i f r a d o ) y a u t e n t i f l c a c i n )
C o n t r o l d e ac ceso / /
I n t e g r i d a d si n c o n e x i n / V
A u t e n t i f l c a c i n de l o r i g e n
d e d a to s / y
Rechazo d e p a q u e t e s r e e n v i a d o s / / y
C o n f i d e n c i a l i d a d / y
C o n f i d e n c i a l i d a d l i m i t a d a de l
f l u j o d e t r f i c o / y
La Tabla 6.1 muestra qu servicios proporcionan los protocolos AH y ESP. Para ESP,
existen dos casos: con y sin opcin de autentificacin. Tanto AH como ESP son vehcu
los para el control de acceso, basados en la distribucin de claves criptogrficas y la ges
tin de flujos de trfico referente a estos protocolos de seguridad.
ASOCIACIONES DE SEGURIDAD
Un concepto fundamental que aparece en los mecanismos de autentificacin y confiden
cialidad en IP es el de asociacin de seguridad (SA, Security Association). Una asociacin
es una relacin unidireccional entre un emisor y un receptor que ofrece servicios de segu
ridad al trfico que se transporta. Si se necesita una relacin que haga posible un inter
cambio bdireccional seguro, entonces se requieren dos asociaciones de seguridad. Los
servicios de seguridad se suministran a una SA para que use AH o ESP, pero no los dos.
Una asociacin de seguridad se identifica unvocamente por tres parmetros:
www.FreeLibros.org
184 Fundamentos de seguridad en redes. Aplicaciones y estndares
ndice d e parmetros d e s a n id a d (SPI, SecurtyParanteersInde*): una ris
tra de bits asignada a esta SA y que tiene slo significado local. El SPI se trans
porta en cabeceras AH y ESP para permitir que el sistema receptor elija la S A con
la cual se procesar un paquete recibido.
Direccin IP d e destino: actualmente slo se permiten direcciones de un nico
destino (uncast)\ sta es la direccin del destino final de la SA, que puede ser un
sistema de un usuario final o un sistema de red, como por ejemplo un cortafue
gos o un router.
Identificador d d protocolo de seglaridad: indica si la asociacin es una asocia
cin de seguridad AH o ESP
Por consiguiente, en cualquier paquete IP 1, la asociacin de seguridad se identifica un
vocamente por la direccin de destino en la cabecera IPv4 o IPv6 y el SPI en la cabece
ra de extensin adjunta (AH o ESP).
Parmetros de SA
En cada implementacin de IPSec hay una base de datos nominal2de asociaciones de
seguridad que define los parmetros asociados con cada SA. Una asociacin de seguri
dad se define, normalmente, por los siguientes parmetros:
Contador d e nmero d e secuencia: un valor de 32 bits que se utiliza para gene
rar el campo nmero de secuencia en las cabeceras AH o ESP, que se describen
en el apartado 6.3 (se requiere para todas las implementaciones).
Desbordamiento d d contador de secuencia: un indicador que seala si el des
bordamiento del contador de nmeros de secuencia debera generar una accin de
auditora y evitar la transmisin de ms paquetes en esta SA (se requiere para
todas las implementaciones).
Ventana contra repeticiones: se usa para determinar si un paquete AH o ESP
que llega es una repeticin, como se describe en el apartado 6.3 (se requiere para
todas las implementaciones).
Informacin AH: algoritmo de autentifcacin, claves, tiempos de vida de las
claves y parmetros relacionados que se usan con AH (se requiere para las
implementaciones AH).
Informacin ESP: algoritmo de cifrado y autentifcacin, claves, valores de ini
cializacin, tiempos de vida de las claves y parmetros relacionados que se usan
con ESP (se requiere para las implementaciones ESP).
Tiempo de vida de la asociacin de s a n id a d : un intervalo de tiempo o conta
dor de bytes despus del cual una S A se debe reemplazar con una nueva S A (y un
nuevo SPI) o se debe finalizar, junto con una indicacin de cules de estas accio
nes deberan ocurrir (se requiere para todas las implementaciones).
Modo de protocolo IPSec: tnel, transporte o modo comodn (se requiere para
todas las implementaciones). Estos modos se tratarn en esta seccin.
1 En este Captulo, e l trmino paquete IP se refiere tanto a un datagrama IPv4 como a un paquete IPv6,
2 Nominal en e l sentido de que la funcionalidad que proporciona una base de datos de asociaciones de
seguridad debe estar presente en cada implementacin de IPSec, pero la forma en que se proporciona dicha
funcionalidad e s decisin del implementador.
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 185
M T U (maxnamn transnmssoa unk) dd camma cualquier unidad de transfe
rencia mxima que se observe en el camino (tamao mximo de un paquete que
se puede transmitir sin fragmentacin) y variables de caducidad (se requiere en
todas las implementaciones).
El mecanismo de gestin de claves que se emplea para que stas se distribuyan est liga
do a los mecanismos de autentificacin y privacidad slo mediante el ndice de parme
tros de seguridad. Por ello, la autentificacin y la privacidad se han especificado inde
pendientemente de cualquier mecanismo especfico de gestin de claves.
Selectores de SA
PSec proporciona al usuario una gran flexibilidad en la forma en que los servicios de
PSec se aplican al trfico P. Como se ver ms adelante, las SA se pueden combinar
de distintas maneras para producir la configuracin de usuario deseada. Adems, PSec
proporciona un alto grado de segmentacin al discriminar entre trfico al que se aplica
proteccin de PSec y trfico que tiene permiso para evitar o pasar por alto a PSec, refi
rindose en el primer caso al trfico de P a SA especficas.
El medio por el que el trfico P se relaciona con SA especficas (o a ninguna SA en
el caso del trfico al que no se aplica PSec) es la base de datos de polticas de seguri
dad (SPD, Security Policy Database). En su forma ms simple, una SPD contiene entra
das, cada una de las cuales define un subconjunto de trfico P y seala una SA para ese
trfico. En entornos ms complejos, puede haber mltiples entradas que se relacionan
potencialmente con una sola SA o con varas SA asociadas con una nica entrada a la
SPD. Con el fin de tratar este aspecto ms detalladamente, se hace referencia a la docu
mentacin relevante sobre PSec.
Cada entrada de la SPD se define por un conjunto de valores de campos del proto
colo P y de protocolos de capas superiores, llamados selectores. En efecto, estos selec
tores se usan para filtrar trfico saliente y establecer la correspondencia con una SA en
particular. El procesamiento de trfico saliente obedece a la siguiente secuencia general
para cada paquete P :
1. Comparar los valores de los campos adecuados del paquete (los campos del
selector) con la SPD para encontrar una entrada coincidente de la SPD, que sea
lar cero o ms SA.
2. Determinar la SA, si la hubiese, para este paquete y su SPI asociado.
3. Llevar a cabo el procesamiento P S e c necesario (por ejemplo, procesamiento
AH o ESP).
Los siguientes selectores determinan una entrada de la SPD:
Direccin IP d e desta puede ser una nica direccin P, una lista o rango de
direcciones o una direccin comodn (mscara). Las dos ltimas son necesarias
para permitir que ms de un sistema de destino comparta la misma SA (por ejem
plo, detrs de un cortafuegos).
Direccin IP fuentes puede ser una nica direccin IP, una lista o rango de direc
ciones o una direccin comodn (mscara). Las dos ltimas son necesarias para
permitir que ms de un sistema fuente comparta la misma SA (por ejemplo, detrs
de un cortafuegos).
www.FreeLibros.org
186 Fundamentos de seguridad en redes. Aplicaciones y estndares
ID de usuario: un identificador de usuario obtenido del sistema operativo. No es
un campo de las cabeceras IP ni de capas superiores, sino que est disponible si
PSec se ejecuta en el mismo sistema operativo que el usuario.
Nivel d e confidencialidad de los dalos: se usa para los sistemas que proporcio
nan seguridad en el flujo de informacin (por ejemplo, secreta o no clasificada).
Protocolo d e la capa de transporte: se obtiene del protocolo IP v4 o del campo
siguiente cabecera de IPv6. Puede ser un nmero de protocolo individual, una lis
ta de nmeros de protocolo o un rango de nmeros de protocolo.
Protocolo EPSec (AH o ESP o AH/ESP): si est presente, ste se obtiene del
protocolo IPv4 o del campo siguiente cabecera de IPv6.
Puertos fuente y destino: pueden ser valores individuales de puertos TCP o
UDP, una lista enumerada de puertos o un puerto comodn.
Clase IPvffc se obtiene de la cabecera de IPv6. Puede ser un valor especfico de
clase IPv6 o un valor comodn.
Etiqueta d e flujo IPvffc se obtiene de la cabecera IPv6. Puede ser un valor espe
cfico de la etiqueta de flujo IPv6 o un valor comodn.
Tipo de servicio IPv4 (TOS, TypeofServkt : se obtiene de la cabecera de IPv4.
Puede ser un valor especfico del tipo de servicio de IPv4 o un valor comodn.
MODO TRANSPORTE Y MODO TNEL
Tanto AH como ESP permiten dos modos de uso: modo transporte y modo tnel. La
operacin de estos dos modos se entiende ms fcilmente a partir de la descripcin de
AH y ESP, que se tratan en las secciones 6.3 y 6.4, respectivamente. Aqu se ofrece una
breve introduccin.
Modo transporte
El modo transporte proporciona proteccin principalmente a los protocolos de capas
superiores. Es decir, la proteccin del modo transporte se extiende a la carga til de un
paquete IP. Algunos ejemplos incluyen un segmento TCP o UDP o un paquete ICMP, que
operan directamente encima de IP en la pila de protocolos de un host Normalmente, el
modo transporte se usa para la comunicacin extremo a extremo entre dos hosts (por
ejemplo, un cliente y un servidor o dos estaciones de trabajo). Cuando un host ejecuta AH
o ESP sobre IPv4, la carga til consiste en los datos que habitualmente siguen a la ca
becera IP. Para IPv6, la carga til consiste en los datos que normalmente siguen a la cabe
cera IP y a cualquier cabecera de extensin de IPv6 que est presente, con la posible
excepcin de la cabecera de opciones de destino, que se puede incluir en la proteccin.
ESP en modo transporte cifra y, de manera opcional, autentifica la carga til de IP,
pero no la cabecera IP. AH en modo transporte autentifica la carga til de IP y partes
seleccionadas de la cabecera IP.
Modo tnel
El modo tnel proporciona proteccin al paquete IP completo. Para conseguirlo, despus
de que se han aadido los campos AH y ESP al paquete IP, el paquete completo ms los
campos de seguridad se tratan como carga til de un paquete IP exterior nuevo con
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 1 8 7
una nueva cabecera IP exterior. El paquete original entero, o interior, viaja a travs de
un tnel desde un punto de la rea IP a otro; ningn router a lo largo del camino pue
de examinar la cabecera IP interior. Como el paquete original est encapsulado, el
nuevo paquete, que es mayor, puede tener direcciones de origen y destino totalmente
diferentes, lo cual aade seguridad. El modo tnel se usa cuando uno o los dos extremos
de una SA es una pasarela de seguridad, como podra ser un cortafuegos o un router que
implementa IPSec. Con el modo tnel, una serie de hosts en redes, detrs de cortafue
gos pueden estar implicados en comunicaciones seguras sin implementar IPSec. Los
paquetes no protegidos generados por dichos hosts se transmiten por un tnel a travs
de redes externas por medio de asociaciones de seguridad en modo tnel, establecidas
por el software PSec en el cortafuegos o el router seguro en los lmites de la red local.
A continuacin se ofrece un ejemplo del funcionamiento de IPSec en modo tnel. El
host A de una red genera un paquete IP con la direccin de destino del host B en otra
red. Este paquete se encamina desde el host origen a un cortafuegos o /o/fr seguro en
los lmites de la red de A. El cortafuegos filtra todos los paauetes que salen para deter
minar si se necesita procesamiento IPSec. Si este paquete de A a B requiere IPSec, el
cortafuegos realiza el procesamiento IPSec y encapsula el paquete con una cabecera IP
exterior. La direccin IP de origen de este paquete IP exterior es el cortafuegos, y la
direccin de destino puede ser un cortafuegos que conforma la frontera de la red local
de B. Ahora, este paquete se encamina al cortafuegos de B, y los routers intermedios
slo examinan la cabecera IP exterior. En el cortafuegos de B, se elimina la cabecera IP
exterior y el paquete exterior se enva a B.
T a b l a 6 . 2 F u n c i o n a l i d a d d e l m o d o t n e l y d e l m o d o t r a n s p o r t e
S A e n m o d o t r a n s p o r t e S A e n m o d o t n e l
AH A u t e n t i f i c a l a c a rg a til d e I P y
las p a rt e s s e l e c c i o n a d a s d e la
c a b e c e r a IP y d e las ca bec era s
d e e x t e n s i n d e I P v 6 .
A u t e n t i f i c a t o d o e l p a q u e t e IP
i n t e r n o ( c a b e c e r a i n t e r i o r ms
carga t i l d e I P ) m s las p a rt e s
s e l e c c i o n a d a s d e l a c a b e c e r a IP
e x t e r i o r y las c a be c e ra s
e x t e r n a s d e e x t e n s i n d e IP v 6 .
ESP Cifra l a c a rg a t i l d e I P y
c u a l q u i e r c a b e c e r a de
e x t e n s i n d e I P v 6 q u e s i g a a la
c a b e c e r a ESP.
Cifra el p a q u e t e I P i n t e r i o r .
ESP con
a u t e n t i f i c a c i n
Cifra la carga til d e IP y
c u a l q u i e r c a b e c e r a d e e x t e n s i n
d e IPv6 q u e siga a la c a bec era
ESP A u t e n t i f i c a la carga til de
IP, pe ro n o la c a b e c e r a IR
Cifra el p a q u e t e I P i n t e r i o r .
A u t e n t i f i c a el p a q u e t e IP
i n t e r i o r .
ESP en modo tnel cifra y, de manera opcional, autentifica el paquete IP interior
completo, incluyendo la cabecera IP interior. AH en modo tnel autentifica el paquete
IP interior completo y las partes seleccionadas de la cabecera IP exterior.
La Tabla 6.2 resume la funcionalidad del modo de transporte y del modo tnel.
www.FreeLibros.org
188 Fundamentos de seguridad en redes. Aplicaciones y estndares
6 . 3 CABECERA DE AUTENTIFICACIN
La cabecera de autentificacin proporciona soporte para la integridad de los datos y la
autentificacin de paquetes IP. La caracterstica de integridad de los datos garantiza que
no es posible que se produzca modificacin no detectada en el contenido de un paquete
durante la transmisin. La caracterstica de autentificacin permite que un sistema final
o dispositivo de red autentifique al usuario o aplicacin y filtre el trfico adecuadamen
te; tambin evita los ataques de suplantacin de direccin que se observan hoy en da en
Internet. La AH tambin protege contra los ataques de repeticin que se describen ms
adelante en esta seccin.
La autentificacin se basa en el uso de un cdigo de autentificacin de mensajes
(MAC, Message Authentication Cod), tal y como se explic en el Captulo 3; de ah que
las dos partes deban compartir una clave secreta.
La cabecera de autentificacin se compone de los siguientes campos (Figura 6.3):
Cabecera sgnente (odio bits): identifica el tipo de cabecera que est inmedia
tamente despus de sta.
Longitud de cargi til (odiobits): longitud de la cabecera de autentificacin en
palabras de 32 bits, menos dos. Por ejemplo, la longitud predeterminada del cam
po de datos de autentificacin es de 96 bits, o tres palabras de 32 bits. Con una
cabecera fija de tres palabras, hay un total de seis palabras en la cabecera, y el
campo longitud de carga til tiene un valor de cuatro.
Reservado (16 bits): para usos posteriores.
ndice d e parmetros d e seguridad (32 bits): identifica una asociacin de segu
ridad.
Nmero d e se c u e i a (32 bits): un valor de un contador que se incrementa
monotnicamente, que se trata ms tarde.
0 8 16 3 1
/ ~ / /
C a b e c e r a
s i g u i e n t e
L o n g i t u d
d e c a r g a t il
RE SERVADO
n d i c e d e p a r m e t r o s d e s e g u r i d a d o S P I
N m e r o d e s e c ue nc i a
D a t o s d e a u t e n t i f i c a c i n ( v a r i a b l e )
Figura 6.3 C a b e c e r a d e a u t e n t i f i c a c i n I P S e c
www.FreeLibros.org
Captulo 6 / Seguridad IP 1 8 9
Datos de autentificacin (variable): un campo de longitud variable (debe ser un
nmero entero de palabras de 32 bits) que contiene el valor de comprobacin de
integridad (ICV, Integrity Check Valu), o el MAC para este paquete, que se dis
cutir ms tarde.
SERVICIO CONTRA REPETICIONES
Un ataque de repeticin es aquel en que un atacante obtiene una copia de un paquete
autentificado y lo transmite ms tarde al destino previsto inicialmente. El recibo de
paquetes IP autentificados duplicados puede interrumpir de algn modo un servicio o
tener otras consecuencias negativas. El campo nmero de secuencia sirve para impedir
tales ataques. En primer lugar, analizaremos la generacin de nmeros de secuencia por
parte del emisor, y luego observaremos cmo se procesa por el receptor.
Cuando se establece una nueva SA, el emisor inicializa un contador de nmeros de
secuencia a 0. Cada vez que se enva un paquete con esta SA, el emisor incrementa el
contador y coloca el valor en el campo nmero de secuencia As, el primer valor que
se ha de usar es 1. Si el servicio contra repeticiones est habilitado (predeterminado),
el emisor no debe permitir que el nmero de secuencia sobrepase 232 - 1 para volver
a reiniciarse en 0, ya que en ese caso habra mltiples paquetes vlidos con el mismo
nmero de secuencia. Si se alcanza el lmite de 232 - 1, el emisor debera terminar esta
SA y negociar una nueva SA con una clave nueva.
Debido a que IP es un servicio sin conexin y no fiable, el protocolo no garantiza que
los paquetes se enviarn en orden, ni tampoco que todos los paquetes sern enviados. Por
consiguiente, el documento de autentificacin IPSec dicta que el receptor debera imple-
mentar una ventana de tamao W, con un valor predeterminado de W= 64. El extremo
derecho de la ventana representa el nmero de secuencia ms alto, TV, recibido hasta el
momento para un paquete vlido. Para cualquier paquete con un nmero de secuencia
entre TV- W+ 1 y TVque haya sido recibido correctamente (por ejemplo, adecuadamente
autentificado), se marca la posicin correspondiente en la ventana (Figura 6.4). Cuando
se recibe un paquete, el procesamiento procede como se explica a continuacin:
1. Si el paquete recibido cae dentro de la ventana y es nuevo, se comprueba el
MAC. Si el paquete est autentificado, se marca la ranura correspondiente en la
ventana.
2. Si el paquete recibido est a la derecha de la ventana y es nuevo, se comprueba
el MAC. Si el paquete est autentificado, la ventana avanza de forma que el
nmero de secuencia sea el extremo derecho de la ventana, y se marque en la
ventana la ranura correspondiente.
3. Si el paquete recibido est a la izquierda de la ventana, o si falla la autentifica
cin, se descarta el paquete; este hecho se puede registrar.
VALOR DE COMPROBACIN DE INTEGRIDAD
El campo datos de autenticacin contiene un valor conocido como valor de compro
bacin de la integridad o, como ya se ha indicado, ICV. El ICV es un cdigo de auten
tificacin de mensajes o una versin truncada de un cdigo producido por un algoritmo
MAC. La especificacin actual dicta que una implementacin adecuada debe permitir
www.FreeLibros.org
190 Fundamentos de seguridad en redes. Aplicaciones y estndares
HMAC-MD5-96
HMAC-SHA-1-96
Los dos usan el algoritmo HMAC, el primero de ellos con el cdigo hash MD5 y el
segundo con el cdigo hash SHA-1 (estos algoritmos se describieron en el Captulo 3).
En ambos casos, el valor HMAC total se calcula, pero luego se trunca usando los pri
meros 96 bits, que es la longitud predeterminada para el campo datos de autenticacin.
A v a n z a l a v e n t a n a si
un p a q u e t e v l i d o
se r e c i b e a l a de r e c h a
Ta m a o f i j o d e v e n t a n a W
M a r c a d o si s e r e c i b e N o m a r c a d o si a n n o se
un p a q u e t e v l i d o ha recibido u n p a q u e t e v li do
Figura 6.4 M e c a n i s m o c o n t r a r e p e t i c i o n e s
El MAC se calcula sobre
Los campos de cabecera IP que no cambian durante la transmisin (invariables) o
que son predecibles en valor en la llegada en el punto final para la SA de AH. Los
campos que pueden cambiar durante la transmisin y cuyo valor a la llegada es
impredecible se fijan a cero para el clculo tanto en el origen como en el destino.
La cabecera AH, a excepcin del campo datos de autenticacin Este campo se
fija a cero para el clculo tanto en el origen como en el destino.
Los datos completos de los protocolos de nivel superior, que se suponen invaria
bles durante la transmisin (por ejemplo, un segmento TCP o un paquete IP inte
rior en modo tnel).
Para IPv4, los ejemplos de campos variables son la longitud de cabecera de Internet y
la direccin del origen. Un ejemplo de un campo variable pero predecible es la direc
cin de destino (con enrutado de origen flexible o estricto). Ejemplos de campos varia
bles que se fijan a cero antes del clculo del ICV son los campos tiempo de vida y check-
sum de cabecera. Obsrvese que los campos de direccin de origen y destino estn
protegidos para prevenir la suplantacin de direccin.
Para IPv6, los ejemplos en la cabecera base son versin (invariable), dileccin de desti
no (variable pero predecible) y etiqueta de flujo (variable y fijada a cero para el clculo).
MODOS TRANSPORTE Y TNEL
La Figura 6.5 muestra las dos formas en que se puede usar el servicio de autentificacin
IPSec. En un caso, se proporciona autentificacin directamente entre el servidor y las
www.FreeLibros.org
Captulo 6 / Seguridad IP 191
Servidor
Autentificacin extremo
a extremo
Red interna
Router cortafuegos
Autentificacin extremo
a intermedio
Autentificacin
extremo a extremo
Figura 6.5 A u t e n t i f i c a c i n e x t r e m o a e x t r e m o f r e n t e a e x t r e m o a i n t e r m e d i a r i o
estaciones de trabajo clientes; la estacin de trabajo puede estar en la misma red que el
servidor o en una red exterior. Mientras la estacin de trabajo y el servidor compartan
una clave secreta protegida, el proceso de autentificacin es seguro. Este caso utiliza una
SA en modo transporte. En el otro caso, una estacin de trabajo remota se autentifica a
s misma ante el cortafuegos colectivo, ya sea para el acceso a toda la red interna o por
que el servidor solicitado no permite la caracterstica de autentificacin. Este caso utili
za una SA en modo tnel.
En este subapartado, nos fijaremos en el mbito de autentificacin que proporciona
AH y la localizacin de la cabecera de autentificacin para los dos modos. Las conside
raciones son, en cierto modo, diferentes para IPv4 e IPv6. La Figura 6.6a muestra paque
tes tpicos IPv4 e IPv6. En este caso, la carga til IP es un segmento TCP; tambin podra
ser una unidad de datos para cualquier otro protocolo que use IP, como UDP o ICMP
Para AH <m modo transporte usando IPv4, la AH se inserta despus de la cabecera
IP original y antes de la carga til de IP (por ejemplo, un segmento TCP); esto se ilus
tra en la parte superior de la Figura 6.6b. La autentificacin cubre el paquete completo,
excluyendo campos variables de la cabecera IPv4 que estn fijados a cero para el clcu
lo del MAC.
En el contexto de IPv6, AH se considera una carga til de extremo a extremo; es
decir, no la examinan ni la procesan wuters intermedios. Por lo tanto, la AH aparece des
pus de la cabecera base IPv6 y las cabeceras de extensin salto en salto (hop byhop),
enrutamento y fragmento. Las cabeceras de extensin de opciones de destino podran
aparecer antes o despus de la cabecera AH, dependiendo de la semntica deseada. Nue
vamente, la autentificacin cubre el paquete completo, excluyendo campos vairables que
se fijan a cero para el clculo del MAC.
Para AH en modo tnel se autentifica el paquete IP original completo y la AH se
inserta entre la cabecera IP original y la nueva cabecera IP externa (Figura 6.6c).
La cabecera IP interna contiene las direcciones finales de origen y destino, mientras que
una cabecera IP externa puede contener diferentes direcciones IP (por ejemplo, direc
ciones de cortafuegos u otras pasarelas de seguridad).
www.FreeLibros.org
192 Fundamentos de seguridad en redes. Aplicaciones y estndares
IPv4
C a b e c e r a IP
o r i g i n a l
TCP D a t o s
I P v 6
C a b e c e r a IP
o r i g i n a l
C a b e c e r a s d e e x t e n s i n
(si e s t n p r e s e n t e s )
T C P Datos
( a ) A n t e s d e a p l i c a r A H
- < - A u t e n t i f i c a d o , m e n o s lo s c a m p o s v a r i a b l e s ^ *
C a b e c e r a IP
o r i g i n a l
A H T C P Datos
< --------------------------A u t e n t i f i c a d o , m e n o s l o s c a m p o s v a r i a b l e s ----------------------------------
C a b e c e r a IP
o r i g i n a l
h o p - b y - h o p , d e s t ,
e n r u t a m i e n t o , f r a g m e n t o
AH d e s t TCP D a t o s
( b ) M o d o t r a n s p o r t e
A u t e n t i f i c a d o , m e n o s l o s c a m p o s v a r i a b l e s
e n l a n u e v a c a b e c e r a IP
N u e v a
c a b e c e r a IP
AH
C a b e c e r a IP
o r i g i n a l
TCP D a t o s
A u t e n t i f i c a d o , m e n o s los c a m p o s v a r i a b l e s e n l a n u e v a c a b e c e r a I P y sus
c a be c e ra s d e e x t e n s i n
N u e v a C a b ecer as AH C a b e c e r a IP C a b e c e r a s
TCP Datos
c a b e c e r a IP d e e x t e n s i n o r i g i n a l d e e x t e n s i n
(c) M o d o t n e l
Figura 6.6 m b i t o d e a u t e n t i f i c a c i n d e A H
Con el modo tnel, AH protege el paquete IP interior completo, incluyendo la
cabecera IP interior completa. La cabecera IP exterior (y en el caso de IPv6, las cabe
ceras de extensin IP externas) se protege, a excepcin de los campos variables e
impredecibles.
6 . 4 ENCAPSULAMI ENTO DE LA CARGA TIL DE SEGURIDAD
El encapsulamiento de la carga til de seguridad proporciona servicios de confidencia
lidad, incluyendo confidencialidad del contenido de los mensajes y confidencialidad
limitada del flujo de trfico. Como caracterstica opcional, ESP tambin puede ofrecer
los mismos servicios de autentificacin que AH.
www.FreeLibros.org
Captulo 6 / Seguridad IP 193
EL FORMATO ESP
La Figura 6.7 muestra el formato de un paquete ESP. Contiene los siguientes campos:
Indice d e parmetros d e seguridad (32 bife): identifica una asociacin de segu
ridad.
Nmero d e secuencia (32 bits): el valor de un contador que se incrementa mon
tonamente; proporciona la funcin antirrepeticin, como se explic para AH.
Datos de cargi til (variable): es un segmento de la capa de transporte (modo
de transporte) o un paquete IP (modo tnel) protegido mediante cifrado.
Relleno (a255bytes): la finalidad de este campo se trata ms tarde.
Bit: o 16 24 31
ndice de parmetros d e seguridad
c
'2
f !
73 c
1 s
2 .2 ro
S 73
3 2
<31
l -
f 8
Nmero d e secuencia
/' / \
Datos d e carga t il (variable)
\
N
Relleno (0-2^5 bytesj
Longitud
de relleno
Cabecera
siguiente
Datos de autentificacin (variable)
Figura 6.7 F o r m a t o ESP de IPSec
Lon^tud d e relleno (ocho bits): indica el nmero de bytes de relleno en el cam
po inmediatamente anterior.
Cabecera sedente (odio bits): identifica el tipo de datos que contiene el campo de
datos de carga til identificando la primera cabecera en esa carga til (por ejemplo,
una cabecera de extensin en IPv6 o un protocolo de la capa superior como TCP).
Datos de autentificacin (variable): un campo de longitud variable (debe ser un
nmero entero de palabras de 32 bits) que contiene el valor de comprobacin de
integridad calculado sobre el paquete ESP menos el campo de datos de autentifi-
cacia
ALGORITMOS DE CIFRADO Y AUTENTIFICACIN
Los campos datos de carga til\ relleno, longitud de relleno y cabecera siguiente se
cifran mediante el servicio ESP. Si el algoritmo utilizado para cifrar la carga til requie
www.FreeLibros.org
194 Fundamentos de seguridad en redes. Aplicaciones y estndares
re datos de sincronizacin criptogrfica, como puede ser un vector de inicializacin (IV,
Intializaton Vector), entonces estos datos pueden aparecer explcitamente al principio
del campo datos de carga til Si se incluye, un IV no se cifra normalmente, aunque con
frecuencia se considera que es parte del texto cifrado.
La especificacin actual dicta que una implementacin adecuada debe permitir DES
en modo CBC (descrito en el Captulo 2). A otros algoritmos se les ha asignado identi
ficadores en el documento DOI y podran, por lo tanto, usarse fcilmente para el cifra
do; estos incluyen
Triple DES de tres claves
RC5
IDEA
Triple IDEA de tres claves
CAST
Blowsh
Muchos de estos algoritmos se describen en el Captulo 2.
Como con AH, ESP permite el uso de un MAC con una longitud predeterminada de
96 bits. Tambin como con AH, la especificacin actual dicta que una implementacin
adecuada debe permitir HMAC-MD5-96 y HMAC-SHA-1-96.
RELLENO
El campo de relleno sirve para los siguientes propsitos:
S un algoritmo de cifrado requiere que el texto claro sea un mltiplo de un nme
ro de bytes (por ejemplo, el mltiplo de un solo bloque para un cifrador de blo
que), el campo de relleno se usa para expandir el texto claro (que consiste en los
campos datos de carga til, relleno, longitud de relleno y cabecera siguiente)
para alcanzar la longitud necesaria.
El formato ESP requiere que los campos longitud de relleno y cabecera siguien
te estn correctamente alineados en una palabra de 32 bits. El campo relleno se
usa para garantizar esta alineacin.
Se puede aadir relleno adicional para proporcionar confidencialidad parcial del
flujo de trfico, disimulando la longitud real de la carga til.
MODO TRANSPORTE Y MODO TNEL
La Figura 6.8 muestra dos formas de utilizacin del servicio ESP de IPSec. En la parte
superior de la figura, el cifrado (y de manera opcional, la autentificacin) se proporcio
na directamente entre dos hosts. La Figura 6.8b ilustra cmo se puede usar la operacin
del modo tnel para establecer una red virtual privada. En este ejemplo, una organiza
cin tiene cuatro redes privadas conectadas entre s en Internet. Los hosts de las redes
internas usan Internet para el transporte de datos pero no interactan con otros hosts
basados en Internet. Finalizados los tneles en la pasarela de seguridad para cada red
interna, la configuracin permite que los hosts eviten la implementacin de la capacidad
de seguridad. La primera tcnica usa una S A en modo transporte, mientras que la segun
da se vale de una SA en modo tnel.
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 195
Figura 6.8 C i f r a d o e n m o d o t r a n s p o r t e f r e n t e a c i f r a d o e n m o d o t n e l
En esta seccin, nos centramos en el mbito de ESP para los dos modos. Las consi
deraciones varan de IPv4 a IPv6. Al igual que con el mbito de AH, usaremos los for
matos de paquetes de la Figura 6.6a como punto de inicio.
ESP en modo transporte
ESP en modo transporte se usa para cifrar y, de manera opcional, para autentificar los
datos transportados por IP (por ejemplo, un segmento TCP), como se puede observar en
la Figura 6.9a. Para este modo, usando IPv4, la cabecera ESP se inserta en el paquete IP
inmediatamente antes de la cabecera de la capa de transporte (por ejemplo, TCP, UDP,
ICMP) y despus del paquete IP se coloca una terminacin ESP (los campos relleno,
longitud de relleno y cabecera siguiente)', si se elige autentificacin, se aade el campo
datos de autenticacin ESP despus de la terminacin ESP. Se cifran el segmento ente
ro de la capa de transporte ms la terminacin ESP. La autentificacin cubre todo el tex
to cifrado ms la cabecera ESP.
www.FreeLibros.org
196 Fundamentos de seguridad en redes. Aplicaciones y estndares
Autentificado
Cifrado
Cabec. IP Cabec.
. \ x s
v - e K '
. \ \ x
X X X X X X X X '
f f f f f f f f f
, V / \ D a f c V v V
\ \ \ . . . .
x x
Tq/ to Aut.
original
ESP -F.SP ESP
f
Autentificado
Cifrado -
Cabec. IP
original
hop-by-hop, dest,
enrutamiento,
fragmento
Cabec.
ESP
* \ \
fe.rf
* \ \
x x x x
/ / / /
\ \ \ \
/ / s /
. x x x x x x x x x
f f f f f f f f f
, X \ X [ Wf t cX \ \ X
b X X X X X X X X X
f f f f f f f f f
X X
w .
w -
/ /
Aut.
ESP
(a) Modo transporte
Autentificado-
Cifrado _
Nueva
> / f /
. X X X X
f f fr
x x x x x
f f f f f f f f f ,
X X X X X X X X X
V %
Aut.
ESP
IPv4 cabecera
IP
Cabec.
ESP
ABoCxIR
..b^ral...
- / f f
\ w v
X X X X V
f f f f
' f f - f f f f f t
x x x x x x x x x
f f f f f f f f f 1
f e
xc v r x
Autentificado
Cifrado
Nueva
cabecera
IP
f f f f f f f f f f f f f f f f f f f f f f f
L
IPv6
Cabeceras
de extensin
Cabec.
ESP dgex?em>je(i
X X X X X
v ^ v
X X X X V
x x x x x x x x x
X X X X X X X X X
T/rTv.
ES?/
X X
Aut.
ESP
(c) Modo tnel
Figura 6.9 m b i t o d e c i f r a d o y a u t e n t i f c a c i n d e E S P
En el contexto de IPv6, ESP se considera una carga til de extremo a extremo; es
decir, no se examina ni se procesa por wuters intermedios. Por lo tanto, la cabecera ESP
aparece despus de la cabecera base IPv6 y las cabeceras de extensin hop-by-hop, enru-
tamentoy fragmento. La cabecera de extensin de opciones de destino podra aparecer
antes o despus de la cabecera ESP, dependiendo de la semntica deseada. Para EPv6, el
cifrado cubre el segmento completo del nivel de transporte ms la terminacin ESP ms
la cabecera de extensin de opciones de destino si ocurre despus de la cabecera ESP.
Nuevamente, la autentifcacin cubre el texto cifrado y la cabecera ESP.
La operacin del modo transporte se puede resumir de la siguiente manera:
L En el origen, el bloque de datos formado por la terminacin ESP y el segmento
completo de la capa de transporte se cifra y el texto claro de este bloque se sus
tituye por su texto cifrado para formar el paquete IP para la transmisin. La
autentifcacin se aade si se elige esta opcin.
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 1 9 7
2. Luego, el paquete se encamina al destino. Cada router intermedio necesita exa
minar y procesar la cabecera IP y cualquier cabecera de extensin IP de texto
claro, pero no necesita examinar el texto cifrado.
3. El nodo de destino examina y procesa la cabecera IP ms cualquier cabecera de
extensin IP de texto claro. Luego, basndonos en el SPI en la cabecera ESP, el
nodo de destino descifra el resto del paquete para recuperar el segmento en tex
to claro de la capa de transporte.
La operacin del modo de transporte proporciona confidencialidad para cualquier aplica
cin que lo use, evitando, de esta forma, la necesidad de implementar confidencialidad en
cada aplicacin individual. Este modo de operacin tambin es razonablemente eficaz,
aadiendo una parte pequea a la longitud total del paquete IP. Una desventaja de este
modo es que es posible analizar el trfico en los paquetes transmitidos.
ESP en modo tnel
ESP en modo tnel se utiliza para cifrar un paquete IP entero (Figura 6.9b). Para este
modo, la cabecera ESP se antepone al paquete y luego se cifran el paquete y la termi
nacin ESP. Este mtodo se puede usar para contrarrestar el anlisis del trfico.
Como la cabecera IP contiene la direccin de destino y, posiblemente, informacin
sobre las directivas de enrutamiento de origen y la opcin salto en salto, no es posible
simplemente transmitir el paquete IP cifrado precedido de la cabecera ESP. Los routers
intermedios no podran procesar un paquete as. Por consiguiente, es necesario encap-
sular el bloque completo (cabecera SP ms texto cifrado ms datos de autentificacin,
en caso de estar presentes) con una nueva cabecera IP que contenga suficiente informa
cin para el enrutamiento pero no para el anlisis de trfico.
Mientras el modo transporte es adecuado para proteger conexiones entre hosts que
permiten la caracterstica ESP, el modo tnel es til en una configuracin que incluye un
cortafuegos u otro tipo de pasarela de seguridad que protege una red fiable frente a redes
externas. En este ltimo caso, el cifrado se produce slo entre un host externo y la pasa
rela de seguridad, o entre dos pasarelas de seguridad. Esto libera a los hosts de la red
interna de la carga de procesamiento del cifrado y simplifica la distribucin de claves
reduciendo el nmero de claves necesarias. Adems, dificulta el anlisis del trfico basa
do en el destino final.
Consideremos el caso en el que un host externo desea comunicarse con un host en
una red interna protegida por un cortafuegos, y en el que ESP se implementa en el host
externo y los cortafuegos. Para la transferencia de un segmento de la capa de transporte
del host externo al interno se llevan a cabo los siguientes pasos:
1. El origen prepara un paquete IP interno con una direccin de destino del host
interno de destino. Este paquete est precedido de una cabecera ESP; luego, el
paquete y la terminacin ESP se cifran y se pueden aadir los datos de autenti
ficacin. El bloque resultante se encapsula con una nueva cabecera IP (cabecera
base ms extensiones opcionales como las opciones de enrutamiento y salto en
salto para IPv6) cuya direccin de destino es el cortafuegos; esto conforma el
paquete externo IP
www.FreeLibros.org
198 Fundamentos de seguridad en redes. Aplicaciones y estndares
2. El paquete externo se encamina al cortafuegos destino. Cada router intermedio
necesita examinar y procesar la cabecera IP externa ms cualquier cabecera
externa de extensin IP, pero no necesita examinar el texto cifrado.
3L El cortafuegos destino examina y procesa la cabecera IP externa y cualquier
cabecera de extensin IP externa. Luego, basndose en el SPI de la cabecera
ESP, el nodo de destino descifra el resto del paquete para recuperar el paquete
IP interior en texto claro. Este paquete, luego, se transmite a la red interna.
4 El paquete interno se encamina a travs de cero o ms routers en la red interna
hacia el host de destino.
6 . 5 COMBI NACIN DE ASOCIACIONES DE SEGURIDAD
Una SA individual puede implementar el protocolo AH o el ESP pero no los dos. A
veces, un flujo de trfico particular pedir los servicios proporcionados por AH y ESP.
Adems, un flujo de trfico particular puede requerir servicios IPSec entre hosts y, para
ese mismo flujo, servicios separados entre pasarelas de seguridad, como, por ejemplo,
cortafuegos. En todos estos casos, se deben emplear varias SA para el mismo flujo de
trfico con el objetivo de conseguir los servicios IPSec deseados. El trmino grupo de
asociaciones de seguridad se refiere a una secuencia de asociaciones de seguridad a tra
vs de las cuales se debe procesar el trfico para proporcionar un conjunto de servicios
IPSec. Las SA en un grupo pueden finalizar en distintos extremos o los mismos.
Las asociaciones de seguridad se pueden combinar de dos formas:
Transpcrte adyacente: se refiere a la aplicacin de ms de un protocolo de segu
ridad al mismo paquete IP, sin invocar el modo tnel. Este enfoque para la com
binacin de AH y ESP permite un solo nivel de combinacin; un mayor grado de
anidamiento no produce beneficios adicionales ya que el procesamiento se reali
za en una instancia IPSec: el destino (final).
Anidamiento de tundes se refiere a la aplicacin de varias capas de protocolos
de seguridad mediante modo tnel IP. Este enfoque permite mltiples niveles de
anidamiento, ya que cada tnel puede originarse o terminar en un sitio IPSec dife
rente a lo largo del recorrido.
Los dos enfoques se pueden combinar, por ejemplo, haciendo que una SA de transpor
te entre hosts viaje parte del camino a travs de una SA tnel entre pasarelas de segu
ridad.
Un aspecto interesante que surge al considerar los grupos de SA es el orden en el que
se puede aplicar la autentificacin y el cifrado entre un par dado de extremos finales y
las formas de hacerlo. A continuacin examinaremos este aspecto y luego se observarn
combinaciones de SA que implican al menos un tnel.
AUTENTIFICACIN MS CONFIDENCIALIDAD
El cifrado y la autentificacin se pueden combinar para transmitir un paquete IP con
confidencialidad y autentificacin entre hosts. Analizaremos varios enfoques.
www.FreeLibros.org
Captulo 6 / Seguridad IP 1 9 9
Este enfoque se ilustra en la Figura 6.9. En l, el usuario aplica ESP a los datos que se
han de proteger y luego aade el campo de datos de autentificacin. Existen dos casos:
ESP en modo transporte la autentificacin y el cifrado se aplican a la carga til
de IP enviada al host, pero la cabecera IP no est protegida.
ESP en modo tnel: la autentificacin se aplica al paquete IP completo enviado
a la direccin IP externa de destino (por ejemplo, un cortafuegos), y la autentifi
cacin se realiza en ese destino. El paquete IP interno completo est protegido por
un mecanismo de privacidad, para su envo al destino IP interno.
Para los dos casos, la autentificacin se aplica al texto cifrado, en vez de al texto claro.
Transporte adyacente
Otra forma de aplicar autentificacin despus del cifrado es usar dos SA de transporte
agrupadas, donde la interna es una SA de ESP y la externa una SA de AH. En este caso,
ESP se usa sin su opcin de autentificacin. Debido a que la SA interna es una SA de trans
porte, el cifrado se aplica a la carga til IP. El paquete resultante est formado por una
cabecera IP (y posiblemente extensiones de cabecera IPv6) seguida de un ESP. Luego, se
aplica AH en modo transporte, para que la autentificacin cubra el ESP ms la cabecera IP
original (y extensiones) excepto los campos variables. La ventaja de este enfoque con res
pecto a usar simplemente una sola SA de ESP con la opcin de autentificacin ESP resi
de en que la autentificacin abarca ms campos, incluyendo las direcciones IP de origen y
de destino. La desventaja se halla en el uso de dos SA en vez de una.
Grupo tnel/transporte
El uso de autentificacin antes del cifrado podra ser preferible por varios motivos. En
primer lugar, como los datos de autentificacin estn protegidos mediante cifrado, es
imposible que nadie intercepte el mensaje y altere los datos de autentificacin sin ser
detectado. Segundo, se puede desear almacenar informacin de autentificacin con el
mensaje en el destino para una referencia posterior. Es ms conveniente hacer esto si la
informacin de autentificacin se aplica al mensaje sin cifrar; de otro modo, el mensaje
tendra que volver a cifrarse para verificar la informacin de autentificacin.
Un enfoque para la aplicacin de autentificacin antes del cifrado entre dos hostses
usar un grupo formado por una SA de transporte AH interna y una SA tnel ESP exter
na. En este caso, la autentificacin se aplica a la carga til IP ms la cabecera IP (y
extensiones) a excepcin de los campos variables. El paquete IP resultante luego se pro
cesa en modo tnel por ESP; el resultado es que todo el paquete interno autentificado se
cifra y se aade una nueva cabecera IP externa (y extensiones).
COMBINACIONES BSICAS DE ASOCIACIONES DE SEGURIDAD
El documento de arquitectura IPSec presenta cuatro ejemplos de combinaciones de SA
que deben ser soportadas por hosts IPSec adecuados (por ejemplo, estacin de trabajo,
Opcin ESP con autentificacin
www.FreeLibros.org
200 Fundamentos de seguridad en redes. Aplicaciones y estndares
servidor) o pasarelas de seguridad (por ejemplo, cortafuegos, router), que se ilustran en
la Figura 6.10. La parte inferior de cada caso en la figura representa la conexin fsica
de los elementos; la parte superior representa la conexin lgica mediante una o ms SA
anidadas. Cada SA puede ser tanto AH o ESP. Para asociaciones de seguridad host a
host, el modo puede ser transporte o tnel; si no, debe ser modo tnel.
En el caso 1, toda la seguridad se proporciona entre sistemas finales que implemen-
tan IPSec. Para que dos sistemas finales se comuniquen mediante una SA, deben
compartir las claves secretas apropiadas. Las siguientes son algunas de las posibles
combinaciones:
Pasarela
de
aguridad
Pasarela
de
seguridad
H o s t *
I n t ra n e t
L o c a L .
I n t ra n e t
Local
I n t e rn e t
SA t n e l
Una o
d o s SA
H o s t *
Pasarela de
se g u r i d a d *
Pasarela d e H o s t
s e g u r i d a d *
In t ra n e i
Local
I n t r a n e t
Local
I n t e r n e t
AS t n e l
H o s t *
Una o d o s SA
(b) Caso 2 (d) Caso 4
* = i m p l e m e n t a IPSec
Figura 6.10 C o m b i n a c i n b s i c a d e a s o c i a c i o n e s d e s e g u r i d a d
a AH en modo transporte
h ESP en modo tnel
c AH seguida de ESP en modo transporte (una SA ESP dentro de una SA AH)
d. Cualquiera de a, b o c dentro de una AH o ESP en modo tnel.
Ya hemos discutido cmo se pueden usar estas combinaciones para permitir autenti
ficacin, cifrado, autentificacin antes del cifrado y autentificacin despus del cifrado.
Para el caso la seguridad se proporciona slo entre pasarelas (routers; cortafuegos,
etc.) y ningn host implementa IPSec. Este caso ilustra el modo tnel en una red virtual
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 201
privada. El documento de la arquitectura de seguridad especifica que slo se necesita
una SA tnel para este caso. El tnel podra permitir AH, ESP o ESP con la opcin de
autentificacin. No se requieren tneles anidados porque los servicios IPSec se aplican
al paquete interno completo.
El caso 3 se construye sobre el caso 2 aadiendo seguridad de extremo a extremo. Se
permiten las mismas combinaciones discutidas para los casos 1 y 2. El tnel de pasarela
a pasarela proporciona autentificacin o confidencialidad o ambos para todo el trfico
entre sistemas finales. Cuando el tnel de pasarela a pasarela es ESP, tambin proporcio
na una forma limitada de confidencialidad del trfico. Los hosts individuales pueden
implementar cualquier servicio IPSec adicional requerido para ciertas aplicaciones o para
ciertos usuarios por medio de asociaciones de seguridad ae extremo a extremo.
El caso 4 proporciona soporte para un host remoto que usa Internet para llegar al cor
tafuegos de una organizacin y luego acceder a algn servidor o estacin de trabajo de
trs del cortafuegos. Slo se requiere el modo tnel entre el host remoto y el cortafuegos.
Como en el caso 1, se pueden usar una o dos SA entre el host remoto y el local.
6 .6 GESTIN DE CLAVES
La parte de gestin de claves de IPSec implica la determinacin y distribucin de claves
secretas. Un requisito habitual es el de cuatro claves para la comunicacin entre dos apli
caciones: parejas de transmisin y recepcin tanto para AH como para ESP. El docu
mento de la arquitectura de IPSec asigna soporte para dos tipos de gestin de claves:
Manual: un administrador de sistema configura manualmente cada sistema con
sus propias claves y con las claves de otros sistemas que se comunican. Esto es
prctico para entornos pequeos relativamente estticos.
Automtica: un sistema automtico permite la creacin bajo demanda de claves
para asociaciones de seguridad y facilita el uso de claves en un sistema distribui
do grande con una configuracin cambiante.
El protocolo de gestin de claves automtico predeterminado para IPSec se conoce
como ISAKMP/Oakley y se compone de los siguientes elementos:
Protocolo d e detennmacin d e daves Oakky: Oakley es un protocolo de inter
cambio de claves que se basa en el algoritmo Diffie-Hellman pero que propor
ciona seguridad adicional. Oakley es genrico en el sentido de que no dicta for
matos especficos.
Asociacin d e segiridad y Protocolo d e gestin d e claves (ISAKMP, Inter
net SecurkyAssociatoa andKeyManagementProocot): ISAKMP proporcio
na un marco de trabajo para la gestin de claves en Internet y el soporte del pro
tocolo especfico, incluyendo formatos, para la negociacin de los atributos de
seguridad.
ISAKMP por s mismo no impone un algoritmo especfico de intercambio de claves;
consiste en un conjunto de tipos de mensaje que permiten el uso de una variedad de algo
ritmos de intercambio de claves. Oakley es el algoritmo especfico de intercambio de
claves de uso obligado con la versin inicial de ISAKMP.
Empecemos con una descripcin general de Oakley para pasar posteriormente al
ISAKMP.
www.FreeLibros.org
202 Fundamentos de seguridad en redes. Aplicaciones y estndares
PROTOCOLO DE DETERMINACIN DE CLAVES OAKLEY
Oakley es una mejora del algoritmo de intercambio de claves Diffie-Hellman. Recorde
mos que Diffie-Hellman implica la siguiente interaccin entre los usuarios A y B. Hay
un acuerdo previo sobre dos parmetros globales: q un nmero primo grande; y a, una
raz primitiva de q. A elige un entero aleatorio XA como su clave privada, y transmite a
B su clave pblica YA = a xA mod q. De la misma forma, B elige un entero aleatorio XB
como su clave privada, y transmite a A su clave pblica YB = a xB mod q. Ahora, cada
parte puede calcular la clave secreta de sesin:
K = (YXa mod q = (Ya)xb mod q = o.XaXb mod q
El algoritmo Diffie-Hellman tiene dos caractersticas interesantes:
Las claves secretas se crean slo cuando es necesario. No hay que almacenar cla
ves secretas durante un perodo largo de tiempo exponindolas a vulnerabilidad.
El intercambio no reauiere una infraestructura preexistente, sino un acuerdo sobre
los parmetros globales.
Sin embargo, hay una serie de debilidades en Diffie-Hellman, tal y como se seala en
[HUIT98]:
No proporciona informacin sobre las identidades de las partes.
Est expuesto al ataque por interceptacin (man-Jn-the-middle), en el que una ter
cera parte C suplanta a B mientras se comunica con A y suplanta a A mientras se
comunica con B. Tanto A como B acaban en la negociacin de una clave con C,
que puede observar el trfico y conducirlo entre A y B. El ataque por intercepta
cin se produce como sigue:
1. B enva su clave pblica YB en un mensaje dirigido a A (ver Figura 3.11).
2. El enemigo (E) intercepta este mensaje, guarda la clave pblica de B y enva
un mensaje a A que tiene el identificador de usuario de B, pero la clave pbli
ca de E es Ye. Este mensaje se enva de forma que parezca enviado por el sis
tema de B. A recibe el mensaje de E y almacena la clave pblica de E con el
identificador de usuario de B. De la misma forma, E enva un mensaje a B
con la clave pblica de E, fingiendo que proviene de A.
3. B calcula una clave secreta K\ basada en la clave privada de B y en Ye A cal
cula una clave secreta K2 basada en la clave privada de A y en Ye E calcula
K\ usando la clave secreta de E A^e YB y calcula K2 usando A^-e YA.
4 De ahora en adelante, E puede retransmitir mensajes de A a B y de B a A,
cambiando de forma adecuada sus cifrados en ruta de forma que ni A ni B
sabrn que estn compartiendo su comunicacin con E.
Requiere un elevado nmero de clculos. Como resultado, es vulnerable al ata
que de obstruccin (clogging), en el que un oponente solicita un gran nmero de
claves. La vctima gasta recursos considerables de computacin haciendo expo-
nencacin modular intil, en vez de trabajo real.
Oakley est diseado para tener las ventajas de Diffie-Hellman y contrarrestar sus pun
tos dbiles.
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 0 3
Caractersticas de Oakley
El algoritmo Oakley se caracteriza por cinco aspectos importantes:
1. Emplea un mecanismo conocido como cookies para impedir los ataques de obs
truccin.
2. Permite que las dos partes negocien un grupo: ste, bsicamente, especifica los
parmetros globales del intercambio de claves de Diffie-Hellman.
i Usa valores aleatorios (nonce) para proteger de ataques de repeticin.
4 Permite el intercambio de valores de clave pblica de Diffie-Hellman.
5. Autentifica el intercambio Diffie-Hellman para evitar ataques de interceptacia
Ya se ha tratado Diffie-Hellman. Pasemos ahora a cada uno de los dems elementos. En
primer lugar, consideremos el problema de los ataques de obstruccin. En este ataque,
un oponente falsifica la direccin origen de un usuario legtimo y enva una clave pbli
ca Diffie-Hellman a la vctima. Luego, la vctima realiza una exponencacin modular
para calcular la clave secreta. Mensajes repetidos de este tipo pueden obstruir 1siste
ma de la vctima con trabajo intil. El intercambio de cookies requiere que cada parte
enve un nmero pseudoaleatorio, la cookie, en el mensaje inicial, que la otra parte reco
noce. Este reconocimiento debe repetirse en el primer mensaje del intercambio de cla
ves Diffie-Hellman. Si la direccin fuente fue falsificada, el oponente no obtiene res
puesta. As, un oponente slo puede forzar a un usuario a generar reconocimientos y no
a realizar el clculo Diffie-Hellman.
ISAKMP obliga a que la generacin de cookies satisfaga tres requisitos bsicos:
1. La cookie debe depender de las partes especficas. Esto evita que un atacante
obtenga una cookie usando una direccin IP y un puerto UDP reales y usndola
luego para inundar a la vctima con solicitudes de direcciones IP o puertos ele
gidos de forma aleatoria.
2. No debe ser posible que alguien que no sea la entidad emisora genere cookies
que sean aceptadas por esa entidad. Esto implica que la entidad emisora usar
informacin secreta local en la generacin y posterior verificacin de una coo
kie. No debe ser posible deducir esta informacin secreta a partir de una cookie
particular. La importancia de este requisito se halla en que la entidad emisora no
necesita guardar copias de sus cookies, en cuyo caso seran ms vulnerables,
pero puede verificar el reconocimiento de una cookie entrante cuando sea nece
sario.
3. Los mtodos de generacin y verificacin de cookies deben ser rpidos para evi
tar ataques que intenten sabotear los recursos del procesador.
El mtodo recomendado para crear cookies es realizar un hash rpido (por ejemplo,
MD5) sobre las direcciones IP de origen y de destino, los puertos UDP fuente y destino
y un valor secreto generado localmente.
Oakley permite el uso de diferentes apupas para el intercambio de claves Diffie-
Hellman. Cada grupo incluye la definicin de los dos parmetros globales y la identidad
del algoritmo. La actual especificacin incluye los siguientes grupos:
www.FreeLibros.org
204 Fundamentos de seguridad en redes. Aplicaciones y estndares
Exponenciacin modular con mdulo de 768 bits
q= 2 768 - 2704 - 1 + 264 x (L2638 x n\ + 149686)
a = 2
Exponenciacin modular con mdulo de 1024 bits
g = 2 1024 _ 2 960 _ ! + 264 x (L2894 x + 129093)
a = 2
Exponenciacin modular con mdulo de 1536 bits
o Parmetros que deben determinarse
Grupo de curvas elpticas sobre 2155
o Generador (hexadecimal): X = 7B, Y = 1C8
Parmetros de curva elptica (hexadecimal): A = 0, Y = 7338F
Grupo de curvas elpticas sobre 2185
o Generador (hexadecimal): X = 18, Y = D
o Parmetros de curva elptica (hexadecimal): A = 0, Y = 1EE9
Los primeros tres grupos son el algoritmo clsico de Diffie-Hellman usando exponen-
dacin modular. Los ltimos dos grupos usan la curva elptica anloga a la de Diffie-
Hellman.
Oakley usa valores aleatorios (nances) para proteger de los ataques de repeticin.
Cada nonce es un nmero pseudoaleatorio generado localmente. Los nonces aparecen
en respuestas y se cifran durante ciertas partes del intercambio para asegurar su uso.
Se pueden usar tres mtodos de autcntificaciii con Oakley:
Firmas dctales: el intercambio se autentifica firmando un hash obtenible
mutuamente; cada parte cifra el hash con su clave privada. El hash se genera
usando parmetros importantes como identficadores de usuario y nonces.
Cifrado d e dave pblica: el intercambio se autentifica cifrando parmetros
como identficadores y nonces con la clave privada del emisor.
Cifrado d e dave simtrica: se puede usar una clave procedente de algn meca
nismo fuera de banda para autentificar el intercambio mediante el cifrado sim
trico de los parmetros de intercambio.
Ejemplo de intercambio Oakley
La especificacin Oakley incluye una serie de ejemplos de intercambios que estn per
mitidos por el protocolo. Para dar una idea de Oakley, presentamos un ejemplo, llama
do intercambio agresivo de clave en la especificacin, porque slo se intercambian tres
mensajes.
La Figura 6.11 muestra el protocolo de intercambio agresivo de claves. En el primer
paso, el iniciador (I) transmite una cooky el grupo que se va a usar, y la clave pblica
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 2 0 5
I - R: CKY,, OK_KEYX, GRP, gx, EHAO, NIDP, ID,. IDRl N,( SKi[ID| || IDr || N, || GRP || gx || EHAO]
R -> I: CKYr , CKY,, OK_KEYX, GRP, gy, EHAS, NIDP, IDr, ID,, NR, N,, SKR[IDR || ID, || NR|| N, || GRP || gy || gx || EHASJ
I R: CKY,, CKYr, O KKEYX , GRP, gx, EHAS, NIDP, ID,, IDr, N,, Nr , Sk,[ID, || IDr || N, || NR || GRP || gx || gM || EHAS)
No ta ci n:
I = In i c i a d o r
R = Replicante
CKY,, CKYR = Cookies de i n i c i a d o r y r e p l i c a n t e
OK_KEYX = T i p o d e m e n s a j e d e i n t e r c a m b i o d e claves
GRP = N o m b r e del g r u p o D if fi e -H e l lm a n para este i n t e r c a m b i o
g x, gy = c l a v e p b l i c a del i n i c i a d o r y del r e p l i c a n t e ; g ^ = clave d e sesin d e este i n t e r c a m b i o
EHAO, EHAS = Fu ncione s d e c i f r a d o , ha sh y d e a u t e n t i f i c a c i n o f r e c i d a s y seleccionadas
NIDP = i n d i c a q u e n o se usa c i f r a d o para el re s t o del mensaje
ID,, IDr = I d e n t i f i c a d o r del i n i c i a d o r y del r e p l i c a n te
N| , Nr = n o n c e a lea torio s u m i n i s t r a d o p o r el i n i c i a d o r o el r e p l i c a n t e para este i n t e r c a m b i o
SK|[X], S k r [ X ] = Indica la f i r m a s o b r e X usando la clave p r iv a d a (clave d e f i r m a ) del inic i a d o r, o del r e p l i
cante
Figura 6.11 E j e m p l o d e i n t e r c a m b i o a g r e s i v o d e c l a v e s O a k l e y
Diffie-Hellman de I para este intercambio. Tambin indica los algoritmos ofrecidos de
cifrado de clave pblica, hash y de autentificacin que se van a usar en este intercam
bio. Adems, se incluyen en el mensaje los identificadores de I y del replicante (R) y el
nonce de I para este intercambio. Por ltimo, I aade una firma usando la clave privada
de I que firma los dos identificadores, el nonce, el grupo, la clave pblica Diffie-Hell
man y los algoritmos ofrecidos.
Cuando R recibe el mensaje, verifica la firma usando la clave pblica de firma de I.
R reconoce el mensaje devolviendo la cooke de I, el identificador y el nonce, as como
el grupo. R tambin incluye una cookie en el mensaje, la clave pblica Diffie-Hellman
de R, los algoritmos seleccionados (que deben estar entre los algoritmos ofrecidos), el
identificador de R y el nonce de R para este intercambio. Por ltimo, R aade una firma
usando la clave privada de R que firma los dos identificadores, los dos nonces, el grupo,
las dos claves pblicas Diffie-Hellman y los algoritmos seleccionados.
Cuando I recibe el segundo mensaje, verifica la firma usando la clave pblica de R.
Los valores nonce en el mensaje aseguran que no es la repeticin de un mensaje anti
guo. Para completar el intercambio, I debe enviar un mensaje de vuelta a R para verifi
car que I ha recibido la clave pblica de R.
ISAKMP
ISAKMP define los procedimientos y los formatos de los paquetes para establecer,
negociar, modificar y eliminar asociaciones de seguridad. Como parte del estableci
miento de la SA, ISAKMP define las cargas tiles para intercambiar la generacin de
claves y los datos de autentificacin. Los formatos de las cargas tiles proporcionan un
marco de trabajo consistente independiente del protocolo especfico de intercambio de
claves, del algoritmo de cifrado y del mecanismo de autentificacin.
www.FreeLibros.org
206 Fundamentos de seguridad en redes. Aplicaciones y estndares
Formato de la cabecera ISAKMP
Un mensaje ISAKMP se compone de una cabecera ISAKMP seguida de una o ms car
gas tiles. Todo esto se transfiere en un protocolo de transporte. La especificacin obli
ga a que las implementaciones permitan el uso de UDP para el protocolo de transporte.
La Figura 6.12a muestra el formato de cabecera para un mensaje ISAKMP. Consta
de los siguientes campos:
Cootie d d iniciador (Gt b i t s ) : cookie de la entidad que inici el establecimien
to de la SA, notificacin de SA o eliminacin de la misma.
Cookie del replicante (64 bits): cookie de la entidad que responde; nula en el pri
mer mensaje del iniciador.
S e d e n te carga tO (odio bits): indica el tipo de la primera carga til del men
saje; las cargas tiles se discuten en el siguiente subapartado.
Versin mayor (cuatro bits): indica la versin mayor que se usa del ISAKMP.
Versin menor (cuatro bits): indica la versin menor en uso.
Tipo d e intercambio (odio bits): indica el tipo de intercambio; se discute ms
adelante en esta seccin.
Indicadores (odio bits): indica las opciones especficas fijadas para este intercam
bio ISAKMP. Dos bits definidos hasta ahora: el bit de citado (encrypton bit) se
fija si todas las cargas tiles que siguen a la cabecera se cifran usando el algoritmo
de cifrado para esa SA. El bit de garanta (commit bit) se usa para asegurar que el
material cifrado no se recibe antes de terminar el establecimiento de la SA.
Bit: 0 8 16 24 31

Cookie del iniciador


-
Cookie del replicante
-
Siguiente carga
til
Versin! Versin
m a y o r | menor
Tipo de
intercambio
Indicadores
Identificador de mensaje
Longitud
(a) cabecera ISAKMP
Bit: 0 8 16 31
Siguiente carga RESERVADO
Longitud de carga til
(b) cabecera genrica de carga til
F i g u r a 6 . 1 2 F o r m a t o s I S A K M P
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 0 7
Identificada* d e mensaje(32 bits): identificador nico para este mensaje.
Longitud (32 bife): longitud del mensaje total (cabecera y todas las cargas ti
les) en octetos.
Tipos de carga til ISAKMP
Todas las cargas tiles ISAKMP empiezan con la misma cabecera genrica de carga til
que muestra la Figura 6.12b. El campo siguiente carga til tiene un valor de 0 si es la
ltima carga til del mensaje; si no, su valor es el tipo de la carga til siguiente. El cam
po longitud de carga til ndica la longitud en octetos de esa carga til, incluyendo la
cabecera genrica de carga til.
La Tabla 6.3 resume los tipos de cargas tiles definidos para ISAKMP, y presenta los
campos, o parmetros, que son parte de cada carga til. La cargitO deSA se usa para
empezar el establecimiento de una SA. En esta carga til, el parmetro dominio de inter
pretacin identifica el DOI en el que se est llevando a cabo la negociacin. El DOI
PSec es un ejemplo, pero ISAKMP puede usarse en otros contextos. El parmetro situa
cin define la poltica de seguridad para esta negociacin; bsicamente, se especifican
los niveles de seguridad requeridos para el cifrado y la confidencialidad (por ejemplo,
nivel de confidencialidad, compartimento de seguridad).
La cargitO d e propuesta contiene informacin usada durante la negociacin de la
SA. La carga til indica el protocolo para esta S A (ESP o AH) para la cual se estn nego
ciando servicios y mecanismos. La carga til tambin incluye el SPI de la entidad emi
sora y el nmero de transformaciones. Cada transformacin est contenida en una car
ga til de transformaciones. El uso de varias cargas tiles de transformaciones permite
que el iniciador ofrezca varias posibilidades, de las cuales el replicante debe elegir una
o rechazar la oferta.
La cargp til d la transformacin define una transformacin de seguridad que se
debe usar para asegurar el canal de comunicaciones para el protocolo designado. El
parmetro nmero de transformaciones sirve para identificar esta carga til concreta con
el objetivo de que el replicante pueda usarlo para indicar la aceptacin de esta transfor
macin. Los campos identificacin de transformacin y atributos identifican una trans
formacin especfica (por ejemplo, 3DES para ESP, HMAC-SHA-1-96 para AH) con
sus atributos asociados (por ejemplo, longitud de hash).
La cargi til del intercambio de daves se puede usar para una variedad de tcni
cas de intercambio de claves, incluyendo Oakley, Diffie-Hellman y el intercambio de
claves basado en RSA que usa PGP. El campo de datos de intercambio de claves con
tiene los datos necesarios para generar una clave de sesin y depende del algoritmo de
intercambio de claves que se ha utilizado.
La car^t de identificacin se usa para determinar la identidad de las entidades
que se comunican y se puede usar para determinar la autenticidad de la informacin.
Normalmente, el campo datos de identifcacin contiene una direccin IPv4 o IPv6.
www.FreeLibros.org
T
a
b
l
a

6
.
3

T
i
p
o
s

d
e

c
a
r
g
a

t
i
l

I
S
A
K
M
P
2 0 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
. 1
1 1
5 1

V ) Z3
O"

f>
2 c
3
t 'O
"o
-
3
5 5
S
E l
S o o
-Q
. q
5 O
a s
4
= C

8 ~

~ o
2

E
3
C
C
3
>
o
_c
i

T3
C
O
o


s , 2
C 3

I 5
3
DO-
S o o
3 0 0
Q C
m 2 E
8
w w
O O
*o

c
B o
c o
_
s
<2 8
>
11
o
. 2 o
O (O
O F
s ? = =
o
c
2
2 2
S s
3 <
D gtO
+- 52
W 3
3 5 c
, *= o
CO o
o
i
E
s

_c

O
C/>
s
c
0
2

O
-D

-O

'C
5

*
c -2
1 o
O? -O
.2
i
E
s

* -
c
2

o.
S I
a t

C
2
*-*
o
>

o
"O
8
=
c
8
o .
Q_
) "O
C
s
s ' l
S.2
w O

<55
w '
O Q
.9- o
**
OT"O
- 8
s - g
o 3
C k-
2
W 3
O
Oy,
8 -2
i
sg
I I s
S 2
OT _ Q.
-O O
8 03
Q- C
_ .Q
8 g
S

C
3
k-
O
Q.
w
o
D
2

O)
OT
2

c
.2
*
c
o
o

c
3
k_
o
Q.
>
O
"O
2

O)
OT
O
8 4
. ?
*
o 8
o E
E
2 8
o
^
-O
2 c
Q-'O
8 2
o
(/) 8
o
c
s.

3
O-
<
(/)

c
3
8
B
c
c
'O
o
2
2
o.
b

*-<
c

D
O
c
E
&
8 ^
2 -
o co
k_
O. V)
*
2 c
-o o
k- o
0 co
T3 c
l!
3
s
rf-g
2 o
I w
,2
1 i
E 2
' 3 -
Z .2

o
c
o
o
8

s <
co

V>
"O
I O
8 3

O
E c
2
2
1 E
o r
&
C

TJ

D
O
Q.
P
8 - 0
I I
S i

33
.O- W

0
l l
t =
8
2 o
T3 (O
2
w j
* !
73
i S
c
vO
o
s
X =
2
i 1
8
2 c
2 ;
o . .
5 :
o
2

E
1 %
Q-
(/)

D
O
C

E
2
o"
8
O S kl
o - E
o
c c
8 CL
E CO
S e
- o C/3

^ D
2
T3

'C
3
O)

D
C
vO
o

5
o <
2

3
o.
2
o_
8
o
c o
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 0 9
La cargi til d d certificado transfiere un certificado de clave pblica. El campo
codicacin del certfcado indica el tipo de certificado o la informacin referente al
ste, que puede incluir la siguiente:
Certificado X.509-PKCS#7
Certificado PGP
Clave firmada DNS
Certificado X.509 - firma
Certificado X.509 - intercambio de claves
Tokens de Kerberos
Lista de revocacin de certificados (CRL)
Lista de revocacin de autoridades (ARL)
Certificado SPKI
En cualquier momento del intercambio ISAKMP, el emisor puede incluir una carga til
de sofiotiid d e certificado para solicitar el certificado de las otras entidades comuni
cantes. La carga til puede presentar ms de un tipo de certificado aceptable y ms de
una autoridad de certificacin aceptable.
La cargi til hash contiene datos generados por una funcin hash sobre alguna par
te del mensaje y/o estado ISAKMP. Esta carga til puede usarse para verificar la inte
gridad de los datos en un mensaje y para autentificar a las entidades negociadoras.
La cargi til d e firma contiene datos generados por una funcin de firma digital
sobre alguna parte del mensaje y/o estado ISAKMP. Esta carga til se usa para verificar
la integridad de los datos en un mensaje y puede usarse para servicios de no repudio.
La c a r g i t O nonce contiene datos aleatorios que se usan para garantizar la validez
temporal durante un intercambio y proteger de ataques de repeticin.
La cargi til d e notificacin contiene la informacin de error o la informacin de
estado asociada con esta SA o esta negociacin de SA. Se han definido los siguientes
mensajes de error ISAKMP:
Tipo de carga til invlido
DOI no permitido
Situacin no permitida
Cookie invlida
Versin mayor invlida
Versin menor invlida
Tipo de intercambio invli
do
Indicadores invlidos
Identificacin de mensaje
invlida
Identificador de protocolo
invlido
SPI invlido
Identificador de transfor
macin invlido
Atributos no permitidos
Ninguna propuesta elegida
Mala sintaxis de propuesta
Carga til mal formada
Codificacin de certifica
do invlida
Certificado invlido
Mala sintaxis de solicitud
de certificado
Autoridad de certificacin
invlida
Informacin hash invlida
Fall la autentificacin
Firma invlida
Informacin de clave inv
lida
Notificacin de direccin
www.FreeLibros.org
210 Fundamentos de seguridad en redes. Aplicaciones y estndares
El nico mensaje de estado ISAKMP definido hasta ahora es Conectado. Adems de
estas notificaciones ISAKMP, se usan las notificaciones especficas DOI. Para IPSec, se
definen los siguientes mensajes adicionales de estado:
Tiempo de vida d d replicante: comunica el tiempo de vida de la SA elegido por
el replicante.
Estado de repeticin: se usa para la confirmacin positiva de la eleccin del
replicante en cuanto a si el replicante realizar deteccin antirrepeticiones o no.
Contado inicial: informa a la otra parte que sta es l a primera SA establecida
con el sistema remoto. Entonces el receptor de esta notificacin podra eliminar
cualquier SA existente que tenga para el sistema emisor basndose en que el sis
tema emisor ha reiniciaao y ya no tiene acceso a esas SA.
La carga tfl d e damnacin indica una o ms SA que el emisor ha eliminado de su
base de datos y que, por lo tanto, ya no son vlidas.
Intercambios ISAKMP
ISAKMP proporciona un marco de trabajo para el intercambio de mensajes, donde los
tipos de carga til sirven como pilares de construccin. La especificacin identifica cin
co tipos predeterminados de intercambio que deberan permitirse; stos se resumen en
la Tabla 6.4. En la Tabla, SA se refiere a la carga til de una SA con cargas tiles aso
ciadas de Protocolo y Autentificacin.
El intercambio base permite que el material de intercambio de claves y autentifi-
cacn se transmita junto. Esto minimiza el nmero de intercambios a costa de no pro
porcionar proteccin de identidad. Los dos primeros mensajes proporcionan cookies y
establecen una S A con el protocolo y las transformaciones acordadas; ambas partes usan
un nance para evitar ataques de repeticin. Los dos ltimos mensajes intercambian el
material de clave y los identificadores de usuario, con la carga til AUTH que se usa para
autentificar claves, identidades y los noncesde los dos primeros mensajes.
El intercambio d e proteccin d e identidad expande el intercambio base para pro
teger las identidades de los usuarios. Los dos primeros mensajes establecen la SA. Los
dos siguientes mensajes realizan el intercambio de claves, con nonces para la proteccin
contra repeticiones. Una vez que la clave de sesin ha sido calculada, las dos partes
intercambian mensajes cifrados que contienen informacin de autentificacin, como fir
mas digitales y, opcionalmente, certificados que validan las claves pblicas.
El intercambio d e slo autentificacin se usa para realizar autentificacin mutua,
sin intercambio de claves. Los dos primeros mensajes establecen la SA. Adems, el
replicante usa el segundo mensaje para transportar su identificador y utiliza la autentifl
cacin para proteger el mensaje. El iniciador enva el tercer mensaje para transmitir su
identificador autentificado.
El intercambio a g r a v o reduce el nmero de intercambios a costa de no proporcio
nar proteccin de identidad. En el primer mensaje, el iniciador propone una SA con
opciones ofrecidas de protocolo y transformacin asociadas. El iniciador tambin
empieza el intercambio de claves y proporciona su identificador. En el segundo mensa
je, el replicante indica su aceptacin de la SA con un protocolo y una transformacin
particulares, completa el intercambio de claves y autentifica la informacin transmitida.
En el tercer mensaje, el iniciador transmite un resultado de autentificacin que cubre la
informacin previa, cifrada usando la clave de sesin secreta compartida.
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 1 1
El intercambio informativo se usa para la transmisin unidireccional de informa
cin para la gestin de SA.
Tabla 6.4 T i p o s d e i n t e r c a m b i o I S A K M P
Intercambio Nota
(a) Intercambio base
Empieza la negociacin S A ISAKMP
Acuerdo sobre la S A bsica
G a v e generada; identidad del iniciador verifi
cada por e l replicante
Identidad del replicante verificada por e l inicia
dor; clave generada; S A establecida
(b ) Intercambio de proteccin de identidad
Empieza la negociacin SA-ISAKMP
Acuerdo sobre la S A bsica
Clave generada
Clave generada
Identidad del iniciador verificada por e l repli
cante
Identidad del replicante verificada por e l inicia
dor; S A establecida
(c ) Intercambio slo de autentificacin
(1) I - R: SA; NONCE Empieza la negociacin SA-ISAKMP
(2) R L SA; NONCE; IDR; AUTH Acuerdo sobre l a S A bsica; identidad del
replicante verificada por el iniciador; S A esta
blecida
(3) I > Rr IDi; AUTH Identidad del iniciador verificada por e l repli
cante; S A establecida
(d ) Intercambio a ^ t s v o
(1) I - Rs SA; KE; NONCE; ID, Empieza l a negociacin SA-ISAKMP y el
intercambio d e claves
(2) R -> L SA; KE; NONCE; IDR; AUTH Identidad del iniciador verificada por e l replican
te; clave generada; acuerdo sobre la S A bsica
(3) * I -> R: AUTH Identidad del replicante verificada por e l inicia
dor; S A establecida
(c ) Intercam bio inform ativo
(1) * I -> R: N/D Notificacin o eliminacin de error o estado
Notacin:
I = iniciador
R = replicante
* = significa cifrado de carga til despus de la cabecera ISAKMP
(1) I -> R: S A
(2) R -> L S A
(3) I - > R: KE; NONCE
(4) R - > L KE; NONCE
(5) * I R: ID,; AUTH
(6) * R I : IEfo; AUTH
(1) I -> R : SA; NONCE
(2) R - > I: SA; NONCE
(3) I -> R: KE; ID; AUTH
(4) R -* L KE; IDR; AUTH
www.FreeLibros.org
212 Fundamentos de seguridad en redes. Aplicaciones y estndares
6 .7
6 .7
BIBLIOGRAFIA Y SITIOS WEB RECOMENDADOS
IPv6 e IPv4 se tratan ms detalladamente en [STALOO]. En [COMEOO] y [STEV94] se
encuentra una buena explicacin de la comunicacin entre redes o nternetworkng e
IPv4. [HUIT98] proporciona una descripcin tcnica sencilla de los distintos RFC que
forman la especificacin IPv6; ofrece una discusin sobre la finalidad de las distintas
caractersticas y la operacin del protocolo. [MILL98] trata tambin IPv6, resaltando los
aspectos prcticos y de implementacin. [CHEN98] presenta una buena discusin sobre
el diseo de IPSec. [FRAN01] y [DORA99] son anlisis ms exhaustivos de IPSec.
CHEN98 Cheng, P., et al. A Security Architecture for the Internet Protocol. IBM
Systems Journal, nmero 1, 1998.
COMEOO Comer, D. Internetworking with TCP/IP, Volume 1: Principies, Proto-
cols and Architecture. Upper Saddle River, NJ: Prentice Hall, 2000.
DORA99 Doraswamy, N., y Harkins, D. IPSec. Upper Saddle River, NJ: Prentice
Hall, 1999.
ERANOI Frankel, S. Demystifying the IPSec Puzzle. Boston: Artech House, 2001.
HUIT98 Huitema, C. IPv6 : The New Internet Protocol. Upper Saddle River, NJ:
Prentice Hall, 1998.
MILLOS Miller, S. IPv6 : The New Internet Protocol. Upper Saddle River, NJ:
Prentice Hall, 1998.
STALOO Stallings, W. Data and Computer Communications, 6.a edicin. Upper
Saddle River, NJ: Prentice Hall, 2000.
STEV94 Stevens, W. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA:
Addison-Wesley, 1994.
Sitios web recomendados:
Carl a d d protocolo d e s l i n d a d BP (ipsec): ltimos RFC y borradores de Inter
net para IPSec.
Noticias sobre el pupo d e trab a j o d e seglaridad IP: documentos del erupo de
trabajo, archivos de correo, artculos tcnicos relacionados y otro material til.
Recursos d e seglaridad IP (IPSEC): lista de empresas que implementan IPSec,
estudio de implementacin y otro material til.
TRMINOS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
TERMINOS CLAVE
Asociacin de seguridad
(AS)
Asociacin de seguridad
de Internet y protocolo
de gestin de claves
(ISAKMP)
Ataque de repeticin
Cabecera de autentificacin
(AH)
Encapsulamiento de la carga
til de seguridad (ESP)
IPv4
IPv6
Modo transporte
Modo tnel
Protocolo de determinacin
de claves Oakley
Seguridad IP
Servicio antirrepeticin
www.FreeLibros.org
Captulo 6 / Seguridad IP 213
PREGUNTAS DE REPASO
6 1 . Proporciona algunos ejemplos de aplicaciones de IPSec.
f i f i Qu servicios proporciona IPSec?
f i f i Qu parmetros identifican una SA y cules caracterizan la naturaleza de una
SA concreta?
f i 4 Cul es la diferencia entre modo transporte y modo tnel?
f i f i Qu es un ataque de repeticin?
f i f i Por qu ESP incluye un campo de relleno?
fi7. Cules son los enfoque bsicos sobre la agrupacin de distintas SA?
f i f i Qu papel desempea el protocolo de determinacin de claves Oakley e
ISAKMP en IPSec?
PROBLEMAS
f i l . Al tratar el procesamiento de AH, se mencion que no todos los campos de una
cabecera IP se incluyen en el clculo MAC.
a) Para cada campo de la cabecera IPv4, indica si el campo es invariable, varia
ble pero predecible, o variable (fijado a cero antes del clculo del ICV)-
b) Haz lo mismo para la cabecera IPv6.
c) Haz lo mismo para las cabeceras de extensin IPv6.
En cada caso, justifica tu decisin para cada campo.
f i f i Cuando se usa el modo tnel, se construye una nueva cabecera IP externa.
Indica, para IPv4 e IPv6, la relacin de cada campo de la cabecera IP externa
y cada cabecera de extensin del paquete externo con el campo o cabecera de
extensin correspondiente del paquete IP interno. Es decir, indica qu valores
externos se derivan de valores internos y cules se construyen independiente
mente de los valores internos.
f i f i La autentificacin y el cifrado extremo a extremo se prefieren entre dos hosts:
Crea figuras similares a las Figuras 6.6 y 6.7 que muestren
a) Contigidad de transporte, con cifrado aplicado antes de la autentificacin.
b) Una SA de transporte agrupada en una SA en modo tnel, con cifrado apli
cado antes de la autentificacin.
c) Una SA de transporte agrupada en una SA en modo tnel, con autentifica
cin aplicada antes del cifrado.
f i 4 El documento de la arquitectura IPSec expresa que cuando dos SA en modo
transporte se agrupan para permitir protocolos AH y ESP en el mismo flujo
extremo a extremo, slo una ordenacin de los protocolos de seguridad pare
ce apropiada: realizando el protocolo ESP antes de realizar el protocolo AH.
Por qu se recomienda esto en vez de la autentificacin antes del cifrado?
www.FreeLibros.org
214 Fundamentos de seguridad en redes. Aplicaciones y estndares
6L& a) Cul de los tipos de intercambio ISAKMP (Tabla 6.4) corresponde al
intercambio agresivo de claves Oakley (Figura 6.11)?
b) Indica, para el intercambio agresivo de claves Oakley, qu parmetros de
cada mensaje corresponden a qu tipos de carga til SAKMP.
APNDICE 6 A C O M UN IC A C I N ENTRE REDES Y PROTOCOLOS
DE INTERNET
Este apndice proporciona una visin general de los protocolos de Internet. Empezamos
con un resumen del papel que desempea un protocolo de Internet en las comunicacio
nes entre redes. Luego, se introducen los dos protocolos de Internet principales, IPv4 e
IPv6.
EL PAPEL DE UN PROTOCOLO DE INTERNET
Un protocolo de Internet (IP) proporciona la funcionalidad para conectar entre s siste
mas finales a travs de varias redes. Con este fin, IP se implementa en cada sistema final
y en routers, que son dispositivos que proporcionan conexin entre redes. Los datos de
capas superiores en un sistema final origen se encapsulan en una unidad de datos del
protocolo IP (PDU) para ser transmitidos. Esta PDU luego se transmite a travs de una
o ms redes y routers para llegar al sistema final de destino.
El router debe poder afrontar una variedad de diferencias entre redes, incluyendo las
siguientes:
Esquemas de direccin: las redes pueden usar diferentes esquemas para asignar
direcciones a los dispositivos. Por ejemplo, una LAN 802 IEEE usa direcciones
binarias de 26 bits o de 48 bits para cada dispositivo en la red; una red pblica de
conmutacin de paquetes X.25 usa direcciones decimales de 12 dgitos (codifica
das como cuatro bits por dgito para una direccin de 48 bits). Se debe proporcio
nar alguna forma de direccin de red global, as como un servicio de directorio.
Tamaos mximos d e paquete: los paquetes de una red pueden haber sido divi
didos en partes pequeas para transmitirse a otra red, un proceso conocido como
frapMntan. Por ejemplo, Ethernet impone un tamao mximo de paquete de
1500 bytes; en redes X.25 es comn el tamao mximo de 1000 bytes. Un paque
te que se transmite en un sistema Ethernet y recogido por un router para la retrans
misin en una red X.25 puede tener que fragmentar en dos partes el paquete que
recibe.
Interfaces: las interfaces hardware y software a las distintas redes son diferentes.
El concepto de router debe ser independiente de estas diferencias.
Fiabilidad: distintos servicios de red pueden proporcionar cualquier cosa, desde
un circuito virtual fiable extremo a extremo hasta un servicio no fiable. La opera
cin de los routers no debera depender de la suposicin de fiabilidad de la red.
La operacin del router, como indica la Figura 6.13, depende de un protocolo de Inter
net. En este ejemplo, el protocolo de Internet (IP) del suite de protocolos TCP/IP reali-
www.FreeLibros.org
Captulo 6 / S e g ur ida d IP 2 1 5
za esa funcin. IP debe implementarse en todos los sistemas finales de todas las redes
as como en los routers. Aclems, cada sistema final debe tener protocolos compatibles
por encima de IP para comunicarse con xito. Los routers intermedios slo necesitan
tener protocolos hasta IP.
A p l i
cacin
----------
TCP -<----------
IP

LLC
MAC
Fsico
IP
LLC
MAC
Fsico Fsico
A p l i
cacin
TCP
IP
LLC
MAC
Fsico Fsico
IP
LLC
MAC
Fsico
F i g u r a 6 . 1 3 C o n f i g u r a c i n p a r a u n e j e m p l o d e T C P / I P
Consideremos la transferencia de un bloque de datos desde el sistema final X al sis
tema final Y en la Figura 6.13. La capa IP en X recibe bloques de datos que han de
enviarse a Y desde TCP en X. La capa IP adjunta una cabecera que especifica la direc
cin global de la internet de Y. Esa direccin tiene dos partes: identificador de red e iden
tificador de sistema final. Llamemos a este bloque paquete IP. Luego, IP reconoce que
el destino (Y) est en otra subred. Por lo tanto, el primer paso consiste en enviar el
paquete a un router, en este caso el router 1. Para realizarlo, IP pasa su unidad de datos
a LLC con la informacin apropiada sobre la direccin. LLC crea una PDU de LLC, que
se pasa a la capa MAC. Esta capa construye un paquete MAC cuya cabecera contiene la
direccin del router 1.
Luego, el paquete viaja a travs de la LAN al router 1. El router extrae las cabece
ras y las terminaciones del paquete y analiza la cabecera IP para determinar el destino
ltimo de los datos, en este caso Y. El router ahora debe tomar una decisin de enruta-
miento. Hay dos posibilidades:
1. El sistema final de destino Y est conectado directamente a una de las subredes
a la que est unida el router
www.FreeLibros.org
216 Fundamentos de seguridad en redes. Aplicaciones y estndares
2. Para alcanzar el destino, se deben cruzar uno o ms routers adicionales.
En este ejemplo, el paquete debe ser encaminado a travs del router 2 antes de llegar al
destino. As, el router 1 pasa el paquete IP al router 2 por medio de la red intermedia.
Con este fin, se usan los protocolos de esta red. Por ejemplo, si la red intermedia es una
red X.25, la unidad de datos IP se adapta en un paquete X.25 con informacin adecua
da de direcconamiento para llegar al router 2. Cuando este paquete llega al router 2, se
elimina la cabecera del paquete. El router determina que este paquete IP est destinado
a Y, que est conectado directamente a una subred a la que el router est unido. Por lo
tanto, el router crea un paquete con una direccin de destino de Y y lo enva a la LAN.
Finalmente, los datos llegan a Y, donde el paquete, LLC, y las cabeceras internet y las
terminaciones se pueden eliminar.
Este servicio que ofrece IP no es fiable. Es decir, IP no garantiza que todos los datos
sern entregados o que todos los datos que se enven llegarn en el orden correcto. Es
responsabilidad de la capa inmediatamente superior, en este caso TCP, resolver cual
quier error que se produzca. Este enfoque proporciona mucha flexibilidad. Como la
entrega no est garantizada, no hay requisito particular de fiabilidad en ninguna de las
subredes. As, el protocolo funcionar con cualquier combinacin de tipos de subred.
Como la secuencia del envo no est garantizada, los paquetes sucesivos pueden seguir
diferentes caminos a travs de la internet. Esto permite al protocolo reaccionar ante la
congestin o el fallo en la internet cambiando las rutas.
IPV4
Durante dcadas, la clave de la arquitectura del protocolo TCP/IP ha sido la versin 4
del protocolo de Internet (IP). La Figura 6.14a muestra el formato de la cabecera IP, que
consta de un mnimo de 20 octetos o 160 bits. Los campos son los siguientes:
Versin (cuatro bits): indica el nmero de versin, para permitir la evolucin del
protocolo; el valor es cuatro.
Longitud d e cabecera d e Internet (IHL) (cuatro bits): longitud de la cabecera
en palabras de 32 bits. El valor mnimo es cinco, para una longitud mnima de
cabecera de 20 octetos.
Tipo d e servido (odio bits): proporciona una gua para los mdulos IP de siste
mas finales y para los router a lo largo del recorrido del paquete, en trminos de
prioridad relativa del paquete.
Longitud total (16 bits): longitud total del paquete IP, en octetos.
Identificacin (16 bits): un nmero de secuencia que, junto con la direccin de
origen, la de destino y el protocolo del usuario, trata de identificar un paquete de
forma unvoca As, el identificador debera ser nico para la direccin fuente del
paquete, la direccin de destino y el protocolo de usuario durante el tiempo en que
el paquete permanezca en la internet.
Indicadores (tres bits): slo se definen dos de los bits. Cuando un paquete se frag
menta, el bit Ms (Mor) indica si ste es el ltimo fragmento del paquete original.
El bit de No Fragmentar (Dont Fragmenf) prohbe la fragmentacin una vez que
se ha fijado. Este bit puede ser til si se sabe que el destino no tiene la capacidad
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 1 7
Bi t : 1 6 1 9 31
Vrsin IHL Ti po d e servicio Longitud total
Identificacin
Indica
dores
Desplazamiento de fragmento
Tiempo d e vida Protocolo Suma de comprobacin de la cabecera
Direccin orig e n
Direccin d e destino
Opciones + relleno
(a) Cabecera IPv4
Bit: 0 4 12 16 31
o

de reensamblar fragmentos. Sin embargo, si se fija este bit, el paquete se ignorar


s excede el tamao mximo de una subred en ruta. Por lo tanto, si se fija este bit,
puede ser recomendable usar el enrutamiento de la fuente para evitar subredes con
un tamao mximo de paquete pequeo.
Desplazamiento d e fragpnoito (13 bits): indica el lugar en el paquete original al
que pertenece este fragmento, medido en unidades de 64 bits. Esto implica que los
fragmentos, menos el ltimo, deben contener un campo de datos que sea mltiplo
de 64 bits de longitud.
Tiempo d e vida (1 7 1 , time to Uv) (odio bits): especifica cunto tiempo, en
segundos, est permitido que un paquete est en la internet. Cada router que pro
cesa un paquete debe disminuir el TTL al menos en uno. Por lo tanto, el TTL es
similar al contador de saltos.
Protocolo (odio bits): indica el protocolo del nivel inmediatamente superior, que
va a recibir el campo de datos en el destino; as, este campo identifica el tipo de la
cabecera siguiente en el paquete despus de la cabecera IP.
Versin Clase d e trfico Etiqueta de f l u j o
Longitud d e carga ti l Cabecera siguiente Lmite d e salto
_
Direccin de orig e n
Direccin de destino
(b) Cabecera IPv6
F i g u r a 6 . 1 4 C a b e c e r a s IP
www.FreeLibros.org
2 1 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
Suma d e comprobacin de la cabecera (16 bits): un cdigo de deteccin de erro
res aplicado slo a la cabecera. Como algunos campos de la cabecera pueden cam
biar durante la transmisin (por ejemplo, tiempo de vida, campos relacionados con
la segmentacin), ste se vuelve a verificar y a calcular en cada router. El campo
de suma de comprobacin es la suma de 16 bits en complemento a uno de todas
las palabras de 16 bits de la cabecera. Para los clculos, el campo de suma de com
probacin se inicializa a un valor de cero.
Direccin d e origen (32 bits): codificada para permitir una ubicacin variable de
bits para especificar la red y el sistema final conectado a la red especificada (siete
y 24 bits, 14 y 16 bits, o 21 y ocho bits).
Direccin d e destino (32 bife): iguales caractersticas que la direccin de origen.
Opciones (variable): codifica las opciones solicitadas por el usuario emisor; pue
den incluir etiqueta de seguridad, enrutamento de origen, registro de enriamien
to y sellado de tiempo.
Relleno (variable): se usa para asegurar que la cabecera del paquete es un mlti
plo de 32 bits de longitud.
IPV6
En 1995, la IETF (Internet Engineering Task Forc), que desarrolla estndares de pro
tocolos para Internet, public una especificacin para el IP de la siguiente generacin,
conocido como IPng. Esta especificacin se convirti en 1996 en un estndar conocido
como IPv6. IPv6 proporciona una serie de mejoras funcionales al IP existente (conoci
do como IPv4), diseado para ajustarse a las altas velocidades de las redes actuales y a
la mezcla de flujo de datos, que incluyen vdeo y audio, que se estn haciendo ms
comunes. Pero detrs del desarrollo del nuevo protocolo se halla la necesidad imperan
te de nuevas direcciones. IPv4 usa una direccin de 32 bits para especificar un origen o
un destino. Con el crecimiento explosivo de Internet y las redes privadas conectadas a
Internet, esta longitud de direccin se hizo insuficiente para ajustarse a todos los siste
mas que necesitan direcciones. Como muestra la Figura 6.14b, IPv6 incluye campos de
direccin fuente y destino de 128 bits. Por ltimo, se espera que todas las instalaciones
que usan TCP/IP migren del actual IP a IPv6, pero este proceso durar muchos aos, s
no dcadas.
Cabecera IPv6
La cabecera IPv6 tiene una longitud fija de 40 octetos y consta de los siguientes campos
(Figura 6.14b):
Versin (nafro bife): nmero de versin del protocolo de Internet; el valor es seis.
Clase de trfico (ocbo bits): disponible originando nodos y/o reenviando routers
para identificar y distinguir entre diferentes clases o prioridades de paquetes IPv6.
El uso de este campo todava se est estudiando.
Etiqueta de flujo (20 bife): puede usarlo un host para etiquetar aquellos paquetes
para los que est solicitando un trato especial por parte de los routers en una red.
www.FreeLibros.org
Captulo 6 / Seguridad IP 219
El etiquetado del flujo puede ayudar en la reserva de recursos y en el procesa
miento de trfico en tiempo real.
Longitud d e cargp til (16 bits): longitud del resto del paquete que sigue a la
cabecera, en octetos. Es decir, es la longitud total de todas las cabeceras de exten
sin ms la PDU del nivel de transporte.
Cabecera s n e n te (odio bits): identifica el tipo de cabecera que sigue a la cabe
cera IPv6; ser una cabecera de extensin IPv6 o una cabecera de capa superior,
como TCP o UDP.
Limite de salto (odio bits): el nmero restante de saltos permitidos para este
paquete. El lmite de saltos lo fija el origen en un valor mximo deseado y dismi
nuye en uno por cada nodo que reenva el paquete. El paquete se ignora si el lmi
te de saltos llega a cero.
Direccin d e origen (128bits): la direccin del originador del paquete.
Direccin d e destino (128 bits): la direccin del receptor del paquete. Puede, de
hecho, no ser el destino ltimo deseado si una cabecera de extensin de enruta
miento est presente, como se explica ms tarde.
Aunque la cabecera IPv6 es mayor que la porcin obligatoria de la cabecera IPv4 (40
octetos frente a 20 octetos), contiene menos campos (ocho frente a 12). Por lo tanto, los
routers tienen que hacer menos procesamiento por cabecera, lo cual debera aumentar la
velocidad de enrutamiento.
Cabeceras de extensin IPv6
Un paquete IPv6 incluye la cabecera IPv6 que se acaba de explicar, y cero o ms cabe
ceras de extensin. Fuera de IPSec, se han definido las siguientes cabeceras de exten
sin:
Cabecera d e opciones salto <n salto: define opciones especiales que requieren
procesamiento salto en salto
Cabecera d e cnnitamkntoe proporciona enrutamiento extendido, similar al enru
tamiento fuente IPv4
Cabecera d e fr^nentoe contiene informacin sobre fragmentacin y reensam
blado
Cabecera de aita ficad ii: proporciona integridad y autentificacin de paquetes
Cabecera d e meapsubmento d e la carga til d e fflridad: proporciona pri
vacidad
Cabecera d e opciones d e destina contiene informacin opcional que ha de exa
minar el nodo ae destino
El estndar IPv6 recomienda que, cuando se usen varias cabeceras de extensin, las
cabeceras IPv6 aparezcan en el siguiente orden:
1. Cabecera IPv6: obligatoria, siempre debe aparecer en primer lugar
2. Cabecera de opciones salto en salto
www.FreeLibros.org
220 Fundamentos de seguridad en redes. Aplicaciones y estndares
3L Cabecera de opciones de destino: para las opciones que va a procesar el primer
destino que aparece en el campo direccin de destino IPv6 ms los siguientes
destinos presentados en la cabecera de enrutamiento
4 Cabecera de enrutamiento
5. Cabecera de fragmento
6l Cabecera de autentificacin
7 . Cabecera de encapsulamiento de carga til de seguridad
& Cabecera de opciones de destino: para las opciones que va a procesar slo el des
tino ltimo del paquete
La Figura 6.15 muestra un ejemplo de un paquete IPv6 que incluye una instancia de cada
cabecera que no es de seguridad. Obsrvese que la cabecera IPv6 y cada cabecera de
extensin incluye un campo de cabecera siguiente. Este campo identifica el tipo de
cabecera siguiente. Si la siguiente cabecera es una cabecera de extensin, entonces este
campo contiene el identificador del tipo de esa cabecera. Si no, este campo contiene el
identificador de protocolo del protocolo de la capa superior usando IPv6 (normalmente
un protocolo de la capa de transporte), usando los mismos valores que el campo proto
colo IPv4. En la figura, el protocolo de la capa superior es TCP, con lo que los datos de
la capa superior transportados por el paquete IPv6 constan de una cabecera TCP segui
da de un bloque de datos de aplicacin.
Octetos:
40
Variable
Variable
8
Variable
20 (parte variable opcional)
Variable
= Campo de siguiente cabecera
F i g u r a 6 . 1 5 P a q u e t e I P v 6 c o n c a b e c e r a s d e e x t e n s i n ( c o n t i e n e u n s e g m e n t o T C P )
Cabecera IPv6
Cabecera de opciones salto
en salto
Cabecera de enrutamiento
Cabecera de fragmento
Cabecera de opciones
de destino
Cabecera TCP
Datos de aplicacin
www.FreeLibros.org
Captulo 6 / Seguridad IP 2 2 1
La cabecera deopciones salto en salto lleva informacin opcional que, de estar pre
sente, debe ser examinada por cada wuter a lo largo del camino. La cabecera consta de
los siguientes campos:
S e d e n te cabecera (ocbo bits): identifica el tipo de cabecera que sigue a esta
cabecera.
Longitud d e la extensin d e la cabecera (odio bs): longitud de esta cabecera
en unidades de 64 bits, sin incluir los primeros 64 bits.
Opciones: contiene una o ms opciones. Cada opcin est formada por tres sub-
campos: un indicador, mostrando el tipo de opcin; una longitud; y un valor.
Hasta el momento se ha definido nicamente una opcin: la opcin carga til Jumbo,
que se usa para enviar paquetes IPv6 con cargas tiles mayores que 2! - 1 = 65.535
octetos. El campo datos de opciones de esta opcin tiene una longitud de 32 bits y da la
longitud del paquete en octetos, excluyendo la cabecera IPv6. Para estos paquetes, el
campo de longitud de carga til en la cabecera IP v6 debe estar a cero, y no debe haber
cabecera de fragmento. Con esta opcin, IPv6 permite tamaos de paquete de hasta ms
de 4.000 millones de octetos. Esto facilita la transmisin de paquetes grandes de vdeo
y permite que IPv6 haga el mejor uso de la capacidad disponible en cualquier medio de
transmisin.
La cabecera d e enratamiento contiene una lista de uno o ms nodos intermedios
que se han de visitar en el camino de destino del paquete. Todas las cabeceras de enru
tamiento empiezan con un bloque de 32 bits formados por cuatro campos de ocho bits,
seguidos de datos de enrutamiento especficos de un tipo dado de enrutamiento. Los cua
tro campos de ocho bits son siguiente cabecera, longitud de extensin de cabecera y
Tipo d e enratamkntoc identifica una variante particular de cabecera de enruta
miento. Si un wuter no reconoce el valor del tipo de enrutamiento, debe ignorar el
paquete.
ScgMf tos restantes nmero de nodos intermedios explcitos que todava hay
que visitar antes de llegar al destino final.
Adems de esta definicin general de cabecera, la especificacin IPv6 define la cabece
ra de enrutamiento del tipo 0. Cuando se usa esta cabecera, el nodo de origen no coloca
la direccin ltima de destino en la cabecera IPv6. En vez de eso, esa direccin es la lti
ma direccin de la cabecera de enrutamiento, y la cabecera IPv6 contiene la direccin
de destino del primer wuter deseado en el camino. La cabecera de enrutamiento no ser
examinada hasta que el paquete llegue al nodo identificado en la cabecera IPv6. En ese
punto, los contenidos de IPv6 y de la cabecera de enrutamiento se actualizan y se reen
va el paquete. La actualizacin consiste en colocar la siguiente direccin que ha de ser
visitada en la cabecera IPv6 y disminuir el campo de segmentos restantes de la cabece
ra de enrutamiento.
IPv6 requiere un nodo IPv6 para invertir las rutas en un paquete que recibe que con
tenga una cabecera de enrutamiento, para devolver un paquete al emisor.
La cabecera de fra^nento la usa una fuente cuando se necesita fragmentacin. En
IPv6, slo pueden llevarla a cabo los nodos de origen, no los routersa lo largo del cami
no de envo del paquete. Para sacar el mximo partido del entorno de comunicacin
entre redes, un nodo debe realizar un algoritmo de descubrimiento del camino que le
www.FreeLibros.org
222 Fundamentos de seguridad en redes. Aplicaciones y estndares
permita conocer la unidad de transmisin mxima (MTU) ms pequea que permite
cualquier subred en el camino.
En otras palabras, el algoritmo de descubrimiento del camino permite que un nodo
conozca el MTU de la subred que produce cuello de botella en el camino. Con este
conocimiento, el nodo fuente fragmentar, como se requiere, para cada direccin de des
tino dada. S no, la fuente debe limitar todos los paquetes a 1280 octetos, que es el MTU
mnimo que debe permitir cada subred.
Adems del campo cabecera siguiente, la cabecera de fragmento incluye los siguien
tes campos:
Desplazamiento d e frag^nento (13 bs): indica a qu lugar del paquete original
pertenece la carga til de este fragmento. Se mide en unidades de 64 bits. Esto
implica que los fragmentos (que no sean el ltimo fragmento) deben contener un
campo de datos que sea mltiplo de 64 bits de largo.
Res (dos bs): reservado para su uso en el futuro
Indicador M (un b): 1 = ms fragmentos; 0 = ltimo fragmento.
Identificacin (32 bs): diseado para identificar unvocamente al paquete origi
nal. El identificador debe ser nico para la direccin fuente del paquete y la direc
cin de destino durante el tiempo en el que el paquete est en la internet. Todos los
fragmentos con el mismo identificador, direccin de origen y direccin de destino
se vuelven a ensamblar para formar el paquete original.
La cabecera de opciones d e destino lleva informacin opcional que, de estar presente,
es examinada slo por el nodo de destino del paquete. El formato de esta cabecera es el
mismo que el de la cabecera de opciones salto en salto.
www.FreeLibros.org
C A P T U L O 7
Seguridad de la web
7.1 Consideraciones sobre seguridad en la web
A m e n a z a s a l a s e g u r i d a d d e l a w e b
E n f o q u e s p a r a l a s e g u r i d a d d e l t r f i c o e n l a w e b
7.2 SSL (Secure Socket Layer) y TLS ( Transport Layer Securty)
A r q u i t e c t u r a S S L
P r o t o c o l o R e c o r d d e S S L
P r o t o c o l o C h a n g e C i p h e r S p e c
P r o t o c o l o A l e r t
P r o t o c o l o H a n d s h a k e
C l c u l o s c r i p t o g r f i c o s
T L S
7.3 SET [Secure Electronic Transaction)
I n t r o d u c c i n a S E T
F i r m a d u a l
P r o c e s a m i e n t o d e l p a g o
7.4 Bibliografa y sitios web recomendados
7.5 Palabras clave, preguntas de repaso y problemas
P a l a b r a s c l a v e
P r e g u n t a s d e r e p a s o
P r o b l e m a s
www.FreeLibros.org
224 Fundamentos de seguridad en redes. Aplicaciones y estndares
Usa tu mentalidad
Despierta a la realidad
D l a c a t e I v e g o t y o u u n d c r m y s l t k d e Co l P orter
P
rcticamente todas las empresas, la mayora de las agencias gubernamentales y
muchos particulares disponen hoy en da de sitios web. El nmero de personas y
compaas con acceso a Internet est creciendo rpidamente, y todos disponen de
navegadores web grficos. Como consecuencia de esto, las empresas muestran gran en
tusiasmo con la implantacin de herramientas web para el comercio electrnico. Pero la
realidad es que Internet y la web son sumamente vulnerables ante peligros de diversos
tipos. A medida que las empresas adquieren conciencia de esta realidad, la demanda de
servicios web seguros aumenta
El tema de la seguridad en la web es extenso y puede, fcilmente, abarcar un libro
entero (se recomiendan algunos al final del captulo). El captulo comienza con una dis
cusin sobre los requisitos generales para la seguridad en la web para luego centrarse en
dos esquemas que son cada vez ms importantes como parte del comercio web:
SSLATLS y SET.
7.1 CONSIDERACIONES SOBRE SEGURIDAD EN LA WEB
La World Wide Web es, bsicamente, una aplicacin cliente/servidor que se ejecuta en
Internet y en las intranets TCP/IP. Como tal, las herramientas de seguridad y los enfo
ques discutidos anteriormente en este libro son importantes para la seguridad de la web.
Pero, como se destaca en [GARF97], la web presenta nuevos retos que generalmente no
se aprecian en el contexto de la seguridad de los computadores ni de la red:
Internet es bidireccional. Al contrario que los entornos de publicacin tradicio
nales, incluso los sistemas de publicacin electrnica que hacen uso de teletexto,
respuesta de voz o respuesta de fax, la web es vulnerable a los ataques a los servi
dores web desde Internet.
La web se emplea cada vez ms para presentar informacin de empresas y de pro
ductos y como plataforma para transacciones de negocios. Se puede perjudicar la
imagen y ocasionar prdidas econmicas si se manipulan los servidores web.
Aunque los navegadores web son muy fciles de usar, los servidores relativamen
te sencillos de configurar y gestionar y los contenidos web cada vez ms fciles de
desarrollar, el soware subyacente es extraordinariamente complejo. ste puede
ocultar muchos posibles fallos de seguridad. La corta historia de la web est llena
de ejemplos de sistemas nuevos y actualizados, instalados de manera adecuada,
que son vulnerables a una serie de ataques a la seguridad.
Un servidor web puede utilizarse como plataforma de acceso a todo el complejo
de computadores de una agencia o corporacin. Una vez comprometida la seguri
dad del servidor web, un atacante podra tener acceso a datos y sistemas fuera del
propio servidor pero que estn conectados a ste en el sitio local.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 225
Habitualmente, los clientes de servicios basados en web son usuarios ocasionales
y poco preparados (en lo que a seguridad se refiere). Estos usuarios no tienen por
qu ser conscientes de los riesgos que existen y no tienen las herramientas ni los
conocimientos necesarios para tomar medidas efectivas.
T a b l a 7.1 C o m p a r a c i n d e a m e n a z a s e n l a w e b [ R U B I 9 7 ]
A m e n a z a s C o n s e c u e n c i a s C o n t r a m e d i d a s
I n t e g r i d a d M o d i f i c a c i n d e d a
tos d e us ua r io
N a v e g a d o r c a b a l l o
d e Tr o y a
M o dif icac in d e m e
moria
M o d i f i c a c i n del
t r f i c o de l m e n s a j e
e n t r n s i t o
P r d i d a d e i n f o r
m a c i n
M q u i n a e n p e l i g r o
Vulnerabilidad al res
t o d e a m e n a z a s
S u m a d e c o m p r o
b a c i n (c h e c k s um )
c r i p t o g r f i c a
C o n f i d e n c i a l i
dad
E s c u c h a s o c u l t a s
en l a r e d
R o b o d e i n f o r m a
cin de l s e r v i d o r
R o b o d e da t o s del
cl i e n t e
I n f o r m a c i n s o b r e
la c o n f i g u r a c i n de
la r e d
I n f o r m a c i n s o b r e
q u c l i e n t e se c o
m u n i c a co n el s e r
v i d o r
P r d i d a d e i n f o r
m a c i n
P r d i d a d e p r i v a c i
da d
C i f r a d o , p r o x y w e b
D e n e g a c i n de
se rvi cio
I n t e r r u p c i n d e p r o
cesos de l us ua r i o
I n u n d a r l a m q u i n a
co n a m e n a z a s f r a u
d u l e n t a s
L l e n a r e l e s p a c i o
de d i s c o o l a m e
m o r i a
A i s l a r l a m q u i n a
m e d i a n t e a t a q u e s
de D N S
D e s t r u c t i v o
M o l e s t o
I m p i d e q u e los
usuarios fi n a li c e n su
tr a b a jo
D i f c i l d e p r e v e n i r
A u t e n t i f l c a c i n S u p l a n t a c i n de
us ua r io s l e g t i m o s
F a l s i f i c a c i n d e d a
tos
F a l s i f i c a c i n de
us u a r i o
C r e e r q u e l a i n f o r
m a c i n f a l s a es v
lida
T c n i c a s c r i p t o g r
fic a s
www.FreeLibros.org
2 2 6 Fundamentos de seguridad en redes. Aplicaciones y estndares
AMENAZAS A LA SEGURIDAD DE LA WEB
La Tabla 7.1 muestra un resumen de los tipos de amenazas a la seguridad que se afron
tan al usar la web. Esas amenazas se pueden agrupar en ataques pasivos y ataques acti
vos. Los pasivos incluyen escuchas del trfico de la red entre el navegador y el servidor
y la obtencin de acceso a informacin de un sitio web que se supone restringida. Los
ataques activos incluyen la suplantacin de otro usuario, la alteracin de mensajes en
trnsito entre cliente y servidor y la modificacin de informacin de un sitio web.
Otra manera de clasificar las amenazas a la seguridad de la web es en funcin de la
ubicacin de la amenaza: servidor web, navegador web y trfico de red entre navegador
y servidor. Los aspectos referentes a la seguridad del servidor y del navegador se en
marcan dentro de la categora de la seguridad de los sistemas de computadores; la
Parte IV de este libro trata el aspecto de la seguridad de los sistemas en general, pero
tambin es aplicable a la seguridad de los sistemas web. Los temas de la seguridad del
trfico encajan en la categora de la seguridad de la red y se tratan en este Captulo.
HTTP FTP SMTP
S/MIME PGP SET
HTTP FTP SMTP
SSL o TLS Kerberos SMTP HTTP
TCP TCP
U D P TCP
IP/IPSec IP IP
(a) N i v e l d e r e d ( b ) N i v e l d e t r a n s p o r t e (c) N i v e l d e a p l i c a c i n
Figura 7.1 U b i c a c i n r e l a t i v a d e l a s h e r r a m i e n t a s d e s e g u r i d a d e n l a p i l a
d e p r o t o c o l o s T C P / I P
ENFOQUES PARA LA SEGURIDAD DEL TRFICO EN LA WEB
Hay varios enfoques para proporcionar seguridad en la web. Dichos enfoques son simi
lares en los servicios que proporcionan y, hasta cierto punto, en los mecanismos que
usan, pero difieren en lo referente a su mbito de aplicabildad y en cuanto a su ubica
cin relativa dentro de la pila de protocolos TCP/IP.
La Figura 7.1 ilustra estas diferencias. Una forma de proporcionar seguridad en la
web es usar Seguridad IP (IPSecurity, Figura 7. la). La ventaja de usar IPSec es que es
transparente al usuario final y a las aplicaciones, proporcionando una solucin de pro
psito general. Adems, IPSec incluye una capacidad de filtrado, de manera que sola
mente el trfico seleccionado afecta a la carga de procesamiento de IPSec.
Otra solucin de propsito relativamente general es implementar la seguridad justo
encima de TCP (Figura 7. Ib). El principal ejemplo de este enfoque es Secure Sockets La
yer (SSL), y su sucesor, el estndar de Internet Transport Layer Security (TLS). En este
nivel, hay dos opciones de implementacin. SSL (o TLS) se podra proporcionar como
parte de la suite de protocolos y, de esta manera, ser transparente a las aplicaciones.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 227
Como alternativa, SSL se podra incluir en paquetes especficos. Por ejemplo, los nave
gadores Netscape y Microsoft Explorer vienen equipados con SSL, y la mayora de los
servidores web tienen el protocolo implementado.
El ltimo enfoque consiste en la inclusin de servicios de seguridad especficos de
las aplicaciones. La Figura 7.1c muestra ejemplos de esta arquitectura. La ventaja de
este enfoque es que el servicio se puede adecuar a las necesidades especficas de una
aplicacin. En el contexto de la seguridad en la web, un ejemplo importante de este en
foque es Secure Electronic Transaction (SET)
El resto de este captulo est dedicado a SSL/TLS y SET.
7.2 SSL (SECURE SOCKET LAYER) Y T L S (TRANSPORT LAYER SECURITY)
Netscape cre SSL. La versin 3 del protocolo se dise con la participacin pblica y
con el apoyo de la industria y se public como borrador de Internet. Posteriormente,
cuando se alcanz el consenso de presentar el protocolo para su estandarizacin en
Internet, se form el grupo de trabajo TLS dentro de la IETF con el objetivo de de
sarrollar un estndar comn. La primera versin publicada de TLS puede verse, bsica
mente, como SSLv3.1 y es muy similar y compatible con SSLv3.
La mayor parte de esta seccin est dedicada a SSLv3. Al final de la misma se des
criben las principales diferencias entre SSLv3 y TLS.
ARQUITECTURA SSL
SSL est diseado de forma que utilice TCP para proporcionar un servicio fiable y se
guro extremo a extremo. SSL no es un protocolo simple sino que tiene dos niveles de
protocolos, como se observa en la Figura 7.2.
El protocolo Record de SSL proporciona servicios de seguridad bsica a varios pro
tocolos de nivel ms alto. En particular, el Hypertext TransferProtocol (HTTP), que su
ministra el servicio de transferencia para la interaccin entre cliente y servidor web, pue
de operar encima de SSL. Se definen tres protocolos de nivel ms alto como parte de
SSL: Handshake Protocol Change Cipher Spec Protocol y Alert Protocol Esos proto
colos especficos de SSL se utilizan en la gestin de intercambios SSL y se examinarn
ms tarde en esta seccin.
Dos conceptos importantes de SSL son la sesin SSL y la conexin SSL, definidos
en las especificaciones de la siguiente manera:
C f l n a k n : una conexin es un transporte (segn la definicin del modelo de nive
les OSI) que proporciona un tipo de servicio idneo. Para SSL, tales conexiones
son relaciones de igual a igual. Las conexiones son transitorias. Cada conexin est
asociada con una sesin.
Sedn: una sesin SSL es una asociacin entre un cliente y un servidor. Las se
siones las crea el protocolo Handshake (o de negociacin). Las sesiones definen un
1 La Figura 7.1c muestra SET encima de HTTP; sta es una implementacin habitual. En algunas im
plementaciones, SET utiliza TCP directamente.
www.FreeLibros.org
228 Fundamentos de seguridad en redes. Aplicaciones y estndares
SSL SSL Change
Handshake C i p h e r Spec
SSL A l e r t
HTTP
Protocol Pro to co l
Protocol
SSL Record Pro t o co l
|
TCP
______________________________
IP
F i g u r a 7.2 R a d e p r o t o c o l o s S S L
conjunto de parmetros criptogrficos de seguridad, que se pueden compartir en
tre mltiples conexiones. Las sesiones se usan para evitar el costoso proceso de ne
gociacin de nuevos parmetros de seguridad para cada conexin.
Entre cualquier par de interlocutores (aplicaciones como el HTTP sobre cliente y ser
vidor), podra haber mltiples conexiones seguras. En teora, tambin podra haber mlti
ples sesiones simultneas entre las partes, pero en la prctica no se usa esta caracterstica.
En realidad hay un nmero de estados asociados con cada sesin. Una vez se esta
blece una sesin, hay un estado operativo para leer y escribir (por ejemplo, recibir y en
viar). Adems, durante el protocolo Handshake, se crean estados de lectura y escritura
pendientes. Al finalizar satisfactoriamente el protocolo Handshake, los estados pendien
tes se convierten en estados operativos.
Una fase de sesin se define por los siguientes parmetros (estas definiciones se han
extrado de la especificacin de SSL):
Idaitficador d e sesin (sessm idoitier): secuencia arbitraria de bytes elegida
por el servidor para identificar un estado de sesin activo o reanudable.
Certificado d l a entidad p a r (p&rcotfcaii}: certificado X509.v3 del par. Este
elemento puede ser nulo.
Mtodo d e compresin (cenpression m e t h o d el algoritmo usado para compri
mir datos antes del cifrado.
Especificacin d e tifiado {ciphfr spet)i especifica el grueso del algoritmo de ci
frado (tal como nulo, DES, etc.) y un algoritmo de hash (tal como MD5 o SHA-1)
usado para el clculo del MAC. Tambin define atributos criptogrficos como, por
ejemplo, el hash_size.
Clave maestra {nosto'secre^: contrasea de 48 bytes compartida entre cliente y
servidor.
Es reanudable {kresunobi}: indicador que refleja si la sesin se puede utilizar
para iniciar nuevas conexiones.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 2 2 9
Un estado de conexin se define por los siguientes parmetros:
Valores aleatorios del servidor y d d cliente (Server and t f k n t r a n d o n se
cuencias de bytes elegidas por el servidor y el cliente para cada conexin.
Clave secreta para MAC d e escritura d d servidor (S m e r nreM AC secret):
la clave secreta usada en operaciones MAC sobre datos enviados por el servidor.
Clave secreta para MAC d e escritura d d d ia it e (C lien t wrteMAC secret: la
clave secreta usada en operaciones MAC sobre datos enviados por el cliente.
Clave d e escritura d d servidor (Serta* wrte ley): la clave de cifrado conven
cional para los datos cifrados por el servidor y descifrados por el cliente.
Clave d e escritura d d cliente (Client nritehey): la clave de cifrado convencio
nal para los datos cifrados por el cliente y descifrados por el servidor.
Vector de inirfalfaiarin (IV, InitiaH zatkn vector): cuando se usa un cifrador de
bloque en modo CBC, se necesita un vector de inicializacin para cada clave. Este
campo lo inicializa primero el protocolo Handshake. A partir de ah el bloque final
de texto cifrado de cada registro se usa como vector de inicializacin (IV) del si
guiente registro.
Nmeros d e secuencia (Setpienceniunbm): cada parte mantiene nmeros de se
cuencia separados para los mensajes transmitidos y recibidos en cada conexin.
Cuando una de las partes enva o recibe un mensaje change cpherspec, se pone a
cero el nmero de secuencia correspondiente. Los nmeros de secuencia no pue
den exceder de 264-l.
PROTOCOLO RECORD DE SSL
El protocolo Record proporciona dos servicios a las conexiones SSL:
Confidencialidad: el protocolo Handshake define una clave secreta compartida
que se usa para cifrado convencional de la carga til de SSL.
Integridad d e mensajes: el protocolo Handshake tambin define una clave secre
ta compartida que se usa para formar un cdigo de autentificacin de mensajes
(MAC, message authentication code).
La Figura 7.3 indica las diferentes operaciones del protocolo Record. El protocolo toma
un mensaje de la aplicacin que se va a transmitir, fragmenta los datos en bloques ma
nejables, opcionalmente los comprime, le aade un MAC, realiza el cifrado, le aade
una cabecera y transmite la unidad resultante en un segmento TCP. Los datos recibidos
se descifran, se verifican, se descomprimen y se ensamblan. Luego, se envan a la apli
cacin receptora en algn nivel superior.
El primer paso es la fragnentarin Cada mensaje de nivel superior se fragmenta en
bloques de 214 bytes (16384 bytes) o ms pequeos. Despus, opcionalmente, se puede
aplicar la compresin. La compresin debe realizarse sin prdidas y no debe incremen
tar la longitud de los contenidos en ms de 1024 bytes2. En SLLv3 (as como en la ver-
2 Naturalmente, se espera que la compresin reduzca los datos, en vez de aumentarlos. De todas formas,
(febido a las convenciones del formato, e s posible que para bloques muy pequeos el algoritmo de compre
sin produzca una salida mayor que la entrada.
www.FreeLibros.org
2 3 0 Fundamentos de seguridad en redes. Aplicaciones y estndares
Datos d e a p l i c a c i n
F r a g m e n t a
C o m p r i m e
A a d e M A C
Cifra
A a d e ca bec era s
del p r o t o c o l o S S L
F i g u r a 7.3 O p e r a c i n d e l p r o t o c o l o R e c o r d d e S S L
sin actual de TLS), no se especifica ningn algoritmo de compresin, por lo que el al
goritmo de compresin por defecto es nulo.
El siguiente paso en el proceso es calcular un cdig de autoitifkacin de mensa
j e (MAC) sobre los datos comprimidos. Para este propsito, se usa una clave secreta
compartida. El clculo se define como:
hash(MAC_write_^ecret || pad_2 ||
/?as/?(MAC_wrte_secret || pad_l || seq_num || SSLCompressed.type ||
SSLCompressed.length || SSLCompressed.ffagment))
donde
MAC_write_secret
hash
pad_l
pad_2
seq_num
SSLCompressed.type
SSLCompressed.length
SSLCompressed. ff agment
concatenacin
clave secreta compartida
algoritmo hash criptogrfico; MD5 o SHA-1
el byte 0x36 (0011 0110) repetido 48 veces (384 bits)
para MD5 y 40 veces (320 bits) para SHA-1
el byte 0x5C (0101 1100) repetido 48 veces para MD5
y 40 veces para SHA-1
el nmero de secuencia para este mensaje
el protocolo de nivel superior usado para procesar este
fragmento
la longitud del fragmento comprimido
el fragmento comprimido (si no se usa compresin, el
fragmento de texto claro)
www.FreeLibros.org
Captulo 7 / Seguridad de la web 231
Obsrvese que esto es muy similar al algoritmo HMAC definido en el Captulo 3. La
diferencia se halla en que los dos valores de relleno (pad_l y pad_2) se concatenan en
SSLv3, mientras que en HMAC se suman con un OR exclusivo. El algoritmo MAC de
SSLv3 se basa en el borrador de Internet original para HMAC, que usa la concatenacin.
La versin final de HMAC, definida en el RFC 2104, utiliza XOR.
Lo siguiente es cifrar el mensaje comprimido ms el MAC usando cifrado simtrico.
El cifrado no puede incrementar la longitud del contenido en ms de 1024 bytes para
que la longitud total no exceda de 214 + 2048. Se permiten los siguientes algoritmos de
cifrado:
Cifradores de bloque Cifradores d e flujo
Algoritmo Tamao d e dave Algoritmo Tamao d e dave
IDEA 128 RC4-40 40
RC2-40 40 RC4-128 128
DES-40 40
DES 56
3DES 168
Fortezza 80
El algoritmo Fortezza se puede usar en un esquema de cifrado mediante tarjeta inte
ligente.
Para el cifrado de flujo, se cifra el mensaje comprimido ms el MAC. Obsrvese que
el MAC se calcula antes de realizar el cifrado y que el MAC se cifra junto con el texto
en claro o el texto en claro comprimido.
Para el cifrado de bloque, el relleno se puede aadir despus del MAC y antes de rea
lizar cifrado. El relleno se hace aadiendo un nmero de bytes de relleno seguidos de un
byte que indica la longitud del relleno. La cantidad total de relleno es la cantidad ms pe
quea tal que el tamao total de los datos que se van a cifrar (texto en claro ms el MAC
ms el relleno) es un mltiplo de la longitud del bloque de cifrado. Un ejemplo es un tex
to en claro (o texto comprimido si se usa compresin) de 58 bytes, con un MAC de 20
bytes (usando SHA-1), que se cifra usando una longitud de bloque de ocho bytes (por
ejemplo, con el DES). Con el byte que indica la longitud del relleno (padding.length), se
alcanza una longitud total de 79 bytes. Para hacer que el total sea un mltiplo de ocho se
aade un byte de relleno.
El paso final del proceso del protocolo Record consiste en aadir una cabecera, com
puesta por los siguientes campos:
Tipo d e contenido (odio bits): el protocolo de nivel superior usado para procesar
el fragmento interno.
Versin mayor (odio bits): indica la versin mayor de SSL en uso. Para SSLv3,
el valor es tres.
Versin menor (ocho bits): indica la versin menor en uso. Para SSLv3, el valor
es cero.
Longitud d e compresin (16 bits): la longitud en bytes del fragmento de texto en
claro (o comprimido, si es el caso). El valor mximo es 214+2048.
www.FreeLibros.org
2 3 2 Fundamentos de seguridad en redes. Aplicaciones y estndares
Los tipos de contenido definidos son change_cipher_spec, alert, handshake y applica-
tion_data. Los tres primeros son protocolos especficos de SSL que se discutirn a con
tinuacin. Obsrvese que no se hace distincin entre las diferentes aplicaciones (por
ejemplo, HTTP) que podran usar SSL; el contenido de los datos creados por dichas
aplicaciones es opaco para SSL.
La Figura 7.4 muestra el formato del protocolo Record de SSL.
PROTOCOLO CHANGE CIPHER SPEC
El protocolo Change CipherSpeces uno de los tres protocolos especficos de SSL que
utilizan el protocolo Record y, adems, es el ms simple. Este protocolo se compone de
un nico mensaje (Figura 7.5a), que contiene un nico byte con el valor 1. El nico pro
psito de este mensaje es hacer que un estado pendiente se copie en el estado operativo,
lo cual actualiza la suite de cifrado que se usar en esta conexin.
PROTOCOLO ALERT
El protocolo Alert se usa para transmitir las alertas relacionadas con SSL a la entidad
par. Como con otras aplicaciones que usan SSL, los mensajes de alerta se comprimen y
se cifran, segn se especfica en el estado en operativo.
Cada mensaje de este protocolo est formado por dos bytes (Figura 7.5b). El primer
byte toma el valor de aviso(l) o fatal (2) para hacer saber la gravedad del mensaje. Si el ni
vel es fatal, SSL termina la conexin inmediatamente. Otras conexiones de la misma se
sin pueden continuar, pero ya no se pueden establecer nuevas conexiones para esta se
sin. El segundo byte contiene un cdigo que indica la alerta especfica. Primero vamos a
enumerar las alertas que siempre son fatales (definiciones segn la especificacin de SSL):
o
Figura 7 . 4 F o r m a t o d e l m e n s a j e d e l p r o t o c o l o R e c o r d d e S S L
www.FreeLibros.org
Captulo 7 / Seguridad de la web 233
1 b y t e 1 b y t e 3 byte s > 0 byte s
T i p o L o n g i t u d Cont enido
(a) P r o to c o l o (c) P r o t o c o l o Hand shake
Change C p h e r Spec
1 b y t e 1 b y t e > 1 b y te
Nivel A l e rt a Cont enido op aco
(b) P r o t o c o l o (d) O t r o p r o t o c o l o d e n i v e l s u p e r i o r ( p o r e j e m p l o , HTTP)
A l e r t
F i g u r a 7.5 M e n s a j e s p a r a e l p r o c e s a m i e n t o d e l p r o t o c o l o R e c o r d d e S S L
mensaje inesperado (unetpeded_messa^: se recibi un mensaje inapropiado.
mar d e registro errneo (bad_record_ma^i se recibi un MAC incorrecto.
folio d e desccmprearin {decompnsskm_faOur^: la funcin de descompresin
recibi una entrada inadecuada (por ejemplo, no la puede descomprimir o la ha
descomprimido dando como resultado una longitud mayor de la permitida)
folio d e negociacin (handdtake_faSure): el emisor, dadas las opciones dispo
nibles, fue incapaz de negociar un conjunto de parmetros de seguridad acep
tables.
parmetro Qegil (legai parametei): un campo en un mensaje de negociacin
estaba fuera de rango o era inconsistente con otros campos.
El resto de alertas son las siguientes:
notificacin de c ia r e ( dcse_notif}): notifica al receptor que el emisor no envia
r ms mensajes en esta conexin. Se requiere que cada parte enve una alerta c l o -
s e _ n o t i f y antes de cerrar el lado que escribe de una conexin.
no coficado (no_caOfcate) : puede enviarse como respuesta a una solicitud de
certificado si no hay disponible un certificado apropiado.
certificado orrineo (bad_ceri6cae): un certificado recibido no es correcto (por
ejemplo, contiene una firma que no se pudo verificar).
certificado no permitido (imsupporiedi certfkat^: el tipo de certificado recibi
do no est permitido.
certificado revocado ( c&1 fkae_revahe4 : un certificado ha sido revocado por su
firmante.
calificado caducado (certifkate expuvd}: un certificado ha caducado.
www.FreeLibros.org
234 Fundamentos de seguridad en redes. Aplicaciones y estndares
certificado desconocido (certtkate_unknowri): algn otro asunto no especifi
cado se detect durante el tratamiento del certificado, considerndose ste ina
ceptable.
PROTOCOLO HANDSHAKE
La parte ms compleja de SSL es el protocolo Handshake. Este protocolo permite la au
tentificacin mutua de servidor y cliente y negociar un algoritmo de cifrado y de clcu
lo del MAC y las claves criptogrficas que se utilizarn para proteger los datos enviados
en un registro SSL. Este protocolo Handshake se utiliza antes de que se transmita cual
quier dato de aplicacin.
El protocolo Handshake consiste en una serie de mensajes intercambiados entre ser
vidor y cliente. Todos los mensajes tienen el formato que se muestra en la Figura 7.5c.
Cada mensaje tiene tres campos:
T i p a (un byte): indica uno de los 10 mensajes. La Tabla 7.2 enumera los tipos de
mensajes definidos.
Longitud (tresbytes): la longitud del mensaje en bytes.
Contenido (> un byte): los parmetros asociados con el mensaje; tambin apare
cen en la Tabla 7.2.
La Figura 7.6 muestra el intercambio inicial necesario para establecer una conexin
lgica entre el cliente y el servidor. El intercambio puede verse dividido en cuatro
fases.
Tabla 7.2 Tipos de mensajes del protocolo Handshake de SSL
T i p o d e m e n s a j e P a r m e t r o s
h e l l o _ r e q u e s t N u l o
c l e n t _ h e l l o Nfersin, v a l o r a l e a t o r i o , i d d e s e s i n , s u i t e d e c i f r a d o , m t o
do d e c o m p r e s i n
s e r v e r _ h e l l o Nfersin, v a l o r a l e a t o r i o , i d d e s e s i n , s u i t e de c i f r a d o , m t o
do d e c o m p r e s i n
c e r t i f c a t e C a d e n a d e c e r t i f i c a d o s X . 5 0 9 v 3
s e r v e r _ k e y _ e x c h a n g e P a r m e t r o s , f i r m a
c e r t i f i c a t e _ r e q u e s t T i p o , a u t o r i d a d e s
s e r v e r _ d o n e N u l o
c e r t i f i c a t e _ v e r i f y Fi r m a
c l i e n t _ k e y _ e x c h a n g e P a r m e t r o s , f i r m a
f i n i s h e d V a l o r h a s h
www.FreeLibros.org
Captulo 7 / Seguridad de la web 235
C l i e n t e S e r v i d o r
s ----------------------------------------
Fase 1
E st abl e cim i ento d e las capacidades d e s eg u
ri da d, i n c l u y e n d o v e r s i n del p r o t o c o l o , ID de
sesin, s u i t e de cif ra d o , m t o d o d e c o m p r e
s i n y l o s n m e r o s a l e a t o r i o s i n iciales.
Fase 2
El s e r v i d o r p u e d e e n v i a r u n c e r ti f i c a d o , i n t e r
c am bi o d e clave y s o l i c i t u d d e c e r t i f i c a d o . El
s e r v id o r seala el f i n a l d e la f a s e del m e n s a
j e h elio.
------ - k e u ~~~ " *
Fase 3
El c l i e n t e enva c e r t i f i c a d o , s i se l e so l i c i ta , el
i n t e r c a m b i o d e c l a v e , y p u e d e q u e en ve la
v e r i f i c a c i n d e cer tificado.
------ ^ ------- ^ es p ec
__________ "
Fase 4
I n t e rc a m b i o d e s u i t e de c i f ra d o y f i n a li z a c i n
del p r o t o c o l o Handshake.
O b s e r v a c i n : las t r a n s f e r e n c i a s
s om b re a d a s son m e n s a j e s o p c i o
na le s o d e p e n d i e n t e s d e la s ita -
d n q u e n o s i e m p r e s o n enviados.
Figura 7.6 Accin del protocolo Handshake
Fase 1. Establecimiento de las capacidades de seguridad
En esta Fase se inicia una conexin lgica y se establecen las capacidades de seguridad
asociadas con sta. El intercambio lo empieza el cliente, quien enva un mensaje
cfent_heflocon los siguientes parmetros:
Verdn: la versin ms alta de SSL con la que se puede entender el cliente.
Vakr aleatorio (randon): estructura aleatoria generada por el cliente, que con
siste en un sello de tiempo de 32 bits y 28 bytes producidos por un generador de
www.FreeLibros.org
236 Fundamentos de seguridad en redes. Aplicaciones y estndares
nmeros aleatorios seguro. Esos valores sirven como nonces y se usan durante el
intercambio de clave para prevenir ataques de repeticin.
Identificador de sesin (Sesin ID): un identificador de sesin de longitud varia
ble. Un valor distinto de cero indica que el cliente desea actualizar los parmetros
de una conexin existente o crear una nueva conexin en esta sesin. Un valor de
cero indica que el cliente desea establecer una nueva conexin en una nueva sesin.
Suhedecifcrio(CifJMS$ui*}: es una lista que contiene las combinaciones de al
goritmos criptogrficos admitidos por el cliente, en orden decreciente de preferen
cia. Cada elemento de la lista (cada suite de cifrado) define un algoritmo de inter
cambio de clave y una especificacin de cifrado (CipherSped)\ esto se discutir a
continuacin.
Mtodo d e compresin (Canpnssian MeihotJ: es una lista de mtodos de com
presin admitidos por el cliente.
Despus de enviar el mensaje cIient_hello, el cliente espera el mensaje saver_hetto,
que contiene los mismos parmetros que el mensaje client_hello. Para el mensaje ser
v e n te lio se aplican las siguientes convenciones. El campo Versin contiene una versin
ms baja que la sugerida por el cliente y la ms alta permitida por el servidor. El campo
con la estructura aleatoria (random) es generado por el servidor y es independiente del
campo Valor Aleatorio del cliente. Si el campo Identificacin de Sesin del cliente no es
cero, el servidor utiliza el mismo valor; en caso contraro, el campo Identificacin de Se
sin del servidor contiene el valor para una nueva sesin. El campo Suite de Cifrado con
tiene una nica suite de cifrado seleccionada por el servidor de entre las propuestas por
el cliente. El campo Mtodo de Compresin contiene el mtodo de compresin elegido
por el servidor de entre los propuestos por el cliente.
El primer elemento del parmetro Suite de Cifrado es el mtodo de intercambio de
clave (por ejemplo, la forma en que se intercambian las claves criptogrficas para el ci
frado convencional y el clculo de MAC). Se permiten los siguientes mtodos de inter
cambio de clave:
RSA: la clave secreta se cifra con la clave pblica RSA del receptor. Debe dispo
nerse de un certificado de clave pblica para la clave del receptor.
Diffie-HeBman fijo: ste es un intercambio de clave Diffie-Hellman en el cual el
certificado del servidor contiene los parmetros pblicos de Diffie-Hellman firma
dos por una autoridad de certificacin. Es decir, el certificado de clave pblica con
tiene los parmetros de clave pblica de Diffie-Hellman. El cliente proporciona sus
parmetros de clave pblica de Diffie-Hellman, en un certificado, si se solicita au
tentificacin del cliente, o en un mensaje de intercambio de clave. Este mtodo de
termina una clave secreta fija entre las dos partes, basada en los clculos de Diffie-
Hellman utilizando claves pblicas fijas.
Diffie-Heflman efimoo: esta tcnica se usa para crear claves secretas efmeras
(temporales, de un solo uso). En este caso, las claves pblicas de Diffie-Hellman
se intercambian firmadas con la clave privada RSA o DSS del emisor. El receptor
puede usar la correspondiente clave pblica para verificar la firma. Los certifica
dos se usan para autentificar las claves pblicas. sta parece ser la ms segura de
las tres opciones de Diffie-Hellman ya que proporciona una clave temporal y au
tentificada.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 237
Diffie-HdKman annimos se usa el algoritmo bsico de Diffie-Helman sin auten-
tificacn. Es decir, cada lado enva sus parmetros Diffie-Hellman pblicos al
otro, sin autentificacin. Este enfoque es vulnerable al ataque de interceptacin, en
el cual el atacante, utilizando Diffie-Hellman annimo, se conecta con ambas par
tes dirigiendo la comunicacin, mientras las partes creen que sta es directa.
Fortezza: la tcnica definida para el esquema de Fortezza.
Despus de la definicin de un mtodo de intercambio de clave se encuentra la especi
ficacin del cifrado (CpherSpec), la cual incluye los siguientes campos:
Algoritmo d e cifrado: cualquiera de los algoritmos mencionados anteriormente:
RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza
Algoritmo MAC: MD5 o SHA-1
Tipo d e cifrados en flujo o de bloque
Es exportable: verdadero o falso
Tamao d d hash 0, 16 bytes (para MD5) o 20 bytes (para SHA-1)
Material d e d a v e una secuencia de bytes que contiene datos utilizados para ge
nerar las claves de escritura
Tamao d d vector d e inidalzadn: el tamao del vector de inicializacin para
el cifrado en modo CBC
Fase 2. Autentificacin del servidor e intercambio de clave
El servidor comienza esta Fase enviando su certificado, si necesita ser autentificado; el
mensaje contiene uno o una cadena de certificados X.509. El mensaje d e certificado es
necesario para cualquier acuerdo sobre el mtodo de intercambio de clave excepto para
el mtodo Diffie-Hellman annimo. Obsrvese que si se usa Diffie-Hellman fijo, este
mensaje de certificado funciona como un mensaje de intercambio de clave del servidor
porque contiene los parmetros Diffie-Hellman pblicos del servidor.
Luego, se puede enviar un mensajeserver_hey_exdtangR si es necesario. No es ne
cesario en los siguientes casos: (1) el servidor ha enviado un certificado con los par
metros Diffie-Hellman fijos, o (2) se va a usar intercambio de clave RSA. El mensaje de
intercambio de clave del servidor es necesario para lo siguiente:
Diffie-Hdlman annimoc el contenido del mensaje se compone de dos valores
globales de Diffie-Hellman (un nmero primo y una raz primitiva de ese nmero)
ms la clave Diffie-Hellman pblica del servidor (ver la Figura 3.10).
Diffie-Hdlman cfimotK el contenido del mensaje incluye los tres parmetros Dif
fie-Hellman proporcionados por Diffie-Hellman annimo, ms una firma de esos
parmetros.
Intercambio d e dave RSA, <n d cual d servidor est usando RSA pero tiene
ima dave RSA slo para firmar: por lo tanto, el cliente no puede simplemente
enviar una clave secreta cifrada con la clave pblica del servidor. En vez de esto,
el servidor debe crear un par de claves pblica/privada RSA temporales y usar el
www.FreeLibros.org
238 Fundamentos de seguridad en redes. Aplicaciones y estndares
mensaje de intercambio de clave del servidor para enviar la clave pblica. El con
tenido del mensaje incluye los dos parmetros de la clave pblica RSA temporal
(exponente y mdulo; ver la Figura 3.8) ms una firma de esos parmetros.
Fortezza
En cuanto a las firmas, se garantizan algunos detalles adicionales. Como es habitual, una
firma se crea tomando el hash de un mensaje y cifrndolo con la clave privada del emi
sor. En este caso el hash se define como:
hash(ClientHello.random || ServerHello.random || ServerParams)
As, el hash no slo cubre los parmetros Diffie-Hellman o RSA, sino tambin los
dos nonces extrados de los mensajes helio iniciales. Esto previene ataques de repeticin
y falsificacin. En el caso de una firma DSS, el hash se realiza usando el algoritmo
SHA-1. En el caso de una firma RSA, se calcula un hash con MD5 y otro con SHA-1,
y la concatenacin de los dos hash (36 bytes) se cifra con la clave privada del servidor.
Despus, un servidor no annimo (servidor que no usa Diffie-Hellman annimo)
puede solicitar un certificado al cliente. El meisaje r s c a t e raque incluye dos pa
rmetros: tipo de certificado (certifcate_type) y autoridades de certificacin (certica-
te_authoritied). El tipo de certificado indica el algoritmo de clave pblica y su uso:
RSA, slo firma
DSS, slo firma
RSA para Diffie-Hellman fijo; en este caso la firma se usa solamente para autent-
ficacin, enviando un certificado firmado con RSA
DSS para Diffie-Hellman fijo; tambin se usa solamente para autentificacin
RSA para Diffie-Hellman efmero
DSS para Diffie-Hellman efmero
Fortezza
El segundo parmetro en el mensaje de solicitud de certificado es una lista de los dife
rentes nombres de autoridades de certificacin aceptables.
El mensaje final de la Fase 2, y el nico que es obligatorio, es el mensaje
serverdone enviado por el servidor para indicar el final del mensaje heliode\ servidor
y dems mensajes relacionados. Despus de enviar este mensaje, el servidor esperar
para recibir una respuesta del cliente. Este mensaje no tiene parmetros.
Fase 3. Autentificacin del cliente e intercambio de clave
Tras recibir el mensaje server_done, el cliente debera verificar, si friese necesario, que
el servidor proporcion un certificado vlido y comprobar que los parmetros del helio
del servidor son aceptables. Si todo es satisfactorio, el cliente enva uno o ms mensa
jes respondiendo al servidor.
Si el servidor ha solicitado un certificado, el cliente comienza esta Fase enviando un
mensaje d e certificada Si no hay disponible ningn certificado adecuado, el cliente en
va la alerta no certifcate.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 239
Luego est el mms aj e cKent_key_exdhange que debe enviarse en esta Fase. El con
tenido del mensaje depende del tipo de intercambio de clave, como se explica a conti
nuacin:
RSA: el cliente genera un valor de 48 bytes previo de la clave maestra (pre-master
secrei) y cifra con la clave pblica obtenida del certificado del servidor o con la cla
ve RSA temporal obtenida de un mensaje de intercambio de clave del servidor. Su
uso en el clculo de una clave maestra (master secrei) se explica ms tarde.
Diffie-Heflman efmero o annimo: se envan los parmetros Diffie-Hellman p
blicos del cliente.
Diffie-Hellman fijo: los parmetros Diffie-Hellman pblicos del cliente se envia
ron en un mensaje de certificado, por lo que el contenido de este mensaje es nulo.
Fortezza: se envan los parmetros Fortezza del cliente.
Por ltimo, en esta fase, el cliente puede enviar un mensaje coifficate_ e ^ p a r a pro
porcionar verificacin explcita de un certificado del cliente. Este mensaje slo se enva
despus de algn certificado del cliente que tenga capacidad de firma (por ejemplo, to
dos los certificados excepto los que contengan parmetros de Diffie-Hellman fijos). Este
mensaje firma un cdigo hash basado en los mensajes precedentes y se define de la si
guiente manera:
CertificateVerify.sgnature. md5_hash
MD5(master_secret || pad_21| MD5 (handshake_messages || master_secret || pad_l));
Certificate.signature.sha_hash
SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_l));
donde pad_l y pad_2 son los valores definidos anteriormente para el MAC, hands-
hake_messages se refiere a todos los mensajes del protocolo de negociacin (Handsha
ke) enviados o recibidos comenzando en el saludo del cliente (dient_hello) pero sin
incluirlo, y clave maestra (master_secret) es la clave calculada, cuya generacin se ex
plicar ms tarde en esta seccin. Si la clave privada del usuario es DSS, entonces se usa
sta para cifrar el hash SHA-1. Si la clave privada del usuario es RSA, se usa sta para
cifrar la concatenacin de los hash MD5 y SHA-1. En ambos casos, el fin es verificar
que el cliente es el propietario de la clave privada en concordancia con el certificado del
cliente. Incluso, s alguien est usando de forma fraudulenta el certificado del cliente, se
ra incapaz de enviar este mensaje.
Fase 4. Finalizacin
Esta Fase completa el establecimiento de una conexin segura. El cliente enva un mm-
saje fhange_dpher_specy copia la especificacin de cifrado pendiente en la especifi
cacin de cifrado operativa. Obsrvese que este mensaje no se considera parte del pro
tocolo de negociacin sino que se enva utilizando el protocolo Change Cipher Spec. El
cliente entonces enva inmediatamente un mensaje fiiAAer/usando los nuevos algorit
mos, claves y secretos. El mensaje de finalizacin verifica que el intercambio de clave y
los procesos de autentificacin frieron satisfactorios. El contenido del mensaje de fina
lizacin es la concatenacin de dos valores hash.
www.FreeLibros.org
240 Fundamentos de seguridad en redes. Aplicaciones y estndares
MD5(master_secret || pad2 || MD5(handshake_messages || Sender || master_secret ||
padl))
SHA(master_secret II pad2 II SHA(handshake_messages II Sender II master_secret II
padl))
donde Sender es un cdigo que identifica oue el emisor es el cliente y handshake_mes-
sages son todos los datos de los mensajes ael protocolo de negociacin hasta este men
saje, pero sin incluir a ste ltimo.
En respuesta a esos dos mensajes, el servidor enva su propio mensaje change_ci-
pher_spec, transfiriendo la especificacin de cifrado pendiente a la especificacin de ci
frado operativa, y enva su mensaje nished. En este punto la negociacin se ha com
pletado, y el servidor y el cliente pueden comenzar a intercambiar datos del nivel de
aplicacin.
CLCULOS CRIPTOGRFICOS
Otros dos aspectos de inters son la creacin de la clave maestra compartida (masterse-
cretj mediante del intercambio de clave y la generacin de parmetros criptogrficos a
partir de la clave maestra.
Creacin de la clave maestra
La clave maestra compartida es un valor de un solo uso de 48 bytes (384 bits) generado
para esta sesin mediante el intercambio seguro de claves. La creacin se realiza en dos
pasos. Primero, se intercambia un valor previo de la clave maestra (pre_master_secrei) .
Segundo, ambas partes calculan la clave maestra. Para el intercambio del valor previo de
la clave maestra existen dos posibilidades:
RSA: el cliente genera un valor de 48 bytes previo a la clave maestra, lo cifra con
la clave pblica RSA del servidor y se lo enva a ste. El servidor descifra el texto
cifrado con su clave privada para recuperar el valor previo de la clave maestra.
Diffie-Heflman: el cliente y el servidor generan una clave pblica de Diffie-Hell
man. Despus se las intercambian y cada lado realiza los clculos Diffie-Hellman
para crear el valor previo de la clave maestra.
Ahora ambos lados calculan la clave maestra de la siguiente forma:
master_secret = MD5(pre_master_secret || SHA(A || pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHA(BB || pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHA(CCC || pre_master_secret ||
ClientHello.random || ServerHello.random))
donde ClientHello.random y ServerHello.random son los dos valores nonces intercam
biados en el mensaje de saludo inicial (helio).
www.FreeLibros.org
Captulo 7 / Seguridad de la web 2 4 1
La especificacin de cifrado (CipherSpecd) necesita una clave para MAC de escritura
del cliente (client wrte MAC se ere f), una clave para MAC de escritura del servidor {ser-
ver write MAC secrei), una clave de escritura del cliente [client wrte kety), una clave de
escritura del servidor {server write key), un vector de inicializacin o IV (initialization
vectot) del cliente y un IV del servidor, lo cual se genera a partir de la clave maestra en
ese orden. Estos parmetros se crean aplicando una operacin hash a la clave maestra
para producir una secuencia de bytes seguros con suficiente longitud como para dispo
ner de todos los parmetros necesarios.
La generacin de los parmetros a partir de la clave maestra usa el mismo formato
que la generacin de la clave maestra a partir del valor previo de sta:
key_block = MD5(master_secret || SHA(A' || master_secret ||
ServerHello.random || ClientHello.random)) ||
MD5(master_secret || SHAfBB' || master_secret ||
ServerHello.random || ClientHello.random)) ||
MD5(master_secret || SHA('CCC' || master_secret ||
ServerHello.random || ClientHello.random)) || . . .
hasta que se haya generado salida suficiente. El resultado de esta estructura algortmica
es una funcin pseudoaleatoria. La clave maestra puede verse como el valor semilla
pseudoaleatorio de la funcin. Los nmeros aleatorios del cliente y del servidor pueden
verse como valores salt para complicar el criptoanlisis (vase el Captulo 9 para el tra
tamiento del uso de valores salt).
TLS
TLS (TransportLayerSecurity) es una iniciativa de estandarizacin de la IETF cuyo ob
jetivo es producir una versin estndar de Internet de SSL. TLS se define como un Es
tndar Propuesto de Internet en el RFC 2246. El RFC 2246 es muy similar a SSLv3. En
esta seccin se destacarn las diferencias.
Generacin de parmetros criptogrficos
Nmero de versin
El formato del registro de TLS es el mismo que el de SSL (Figura 7.4), y los campos de
cabecera tienen el mismo significado. La nica diferencia radica en los valores de ver
sin. Para la versin actual de TLS, la versin mayor es tres y la menor, uno.
Cdigo de Autentificacin de Mensaje (MAC, Message Authentication Code)
Hay dos diferencias entre los esquemas MAC de SSLv3 y TLS: el algoritmo presente y el
alcance de los clculos del MAC. TLS utiliza el algoritmo HMAC definido en el RFC
2104. Recurdese la definicin del algoritmo HMAC que se ofrece en el Captulo 3:
www.FreeLibros.org
242 Fundamentos de seguridad en redes. Aplicaciones y estndares
HMACk(M) = H[(JC opad) || H [ ( ^ ipad) \ \ M]]
donde
H = funcin hash anidada (para TLS, MD5 o SHA-1)
M = mensaje de entrada a HMAC
K+ = clave secreta rellena con ceros a la izquierda de forma que su longitud sea
igual a la longitud del bloque del cdigo hash (para MD5 y SHA-1, la longi
tud de bloque =512 bits)
ipad = 00110110 (36 en hexadecimal) repetido 64 veces (512 bits)
opad = 01011100 (5C en hexadecimal) repetido 64 veces (512 bits)
SSLv3 usa el mismo algoritmo, excepto que los bytes de relleno se concatenan con
la clave secreta en vez de aplicrseles el XOR con la clave secreta rellena hasta la lon
gitud del bloque. El nivel de seguridad debera ser el mismo en ambos casos.
Para TLS, el clculo del MAC abarca los campos indicados en la siguiente expresin:
HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type ||
TLS Compressed. versin || TLSCompressed.length || TLSCompressed.fragment))
El clculo del MAC cubre todos los campos cubiertos por el clculo en SSLv3, ms
el campo TLSCompressed.versin, que es la versin del protocolo que se est em
pleando.
Funcin pseudoaleatoria
TLS usa una funcin pseudoaleatoria conocida como PRF (PseudoRandom Functior)
para expandir valores secretos en bloques de datos tiles para generacin de claves o va
lidacin. El objetivo es utilizar un valor secreto compartido relativamente pequeo, pero
generar bloques de datos ms grandes de forma segura contra los ataques a las funcio
nes hash y a los MAC. La PRF se basa en la siguiente funcin de expansin de datos
(Figura 7.7).
La funcin de expansin de datos utiliza el algoritmo HMAC, con MD5 o con SHA-
1 como funcin hashe base. Como se puede ver, ?_hash puede repetirse tantas veces
como sea necesario para producir la cantidad de datos que se necesita. Por ejemplo, si
P_SHA-1 se us para generar 64 bytes de datos, tendra que haberse iterado cuatro ve
ces para obtener 80 bytes de datos, de los cuales los ltimos 16 seran descartados. En
este caso, P_MD5 tambin tendra que haberse iterado cuatro veces, produciendo exac
tamente 64 bytes de datos. Obsrvese que cada repeticin implica dos ejecuciones de
HMAC, cada una de las cuales a su vez implica dos ejecuciones del algoritmo de hash
base.
Para hacer que la PRF sea lo ms segura posible, utiliza dos algoritmos hash, de ma
nera que su seguridad est garantizada si uno de los algoritmos se mantiene seguro. PRF
se define como
PRF(secret, label, seed) = P_MD5(S1, label || seed) P_SHA-1(S2, label || seed)
www.FreeLibros.org
Captulo 7 / Seguridad de la web 2 4 3
Semilla
i

Longitud = tamao del hash
Figura 7 . 7 F u n c i n P _ h a s h d e T L S ( s e c r e t o , s e m i l l a )
P_hash = HMAC_hash(secret, A(l) || seed) ||
HMAC_hash(secret, A(2) || seed) ||
HMAC_hash(secret, A(3) || seed) || ...
donde A0 se define como
A(0) = seed
A (J) = HMAC_hash(secret, A(i-l))
PRF toma como entrada un valor secreto, una etiqueta de identificacin y un valor
semilla y produce una salida de longitud arbitraria. La salida se crea dividiendo el va
lor secreto en dos mitades (S1 y S2) y realizando P_hash sobre cada mitad, usando MD5
en una mitad y SHA-1 en la otra Los dos resultados se suman con OR exclusivo para
producir la salida; con este fin, P_MD5 generalmente tiene que ser repetido ms veces
que P_SH A-1 para producir igual cantidad de datos para la entrada de la funcin OR ex
clusivo.
www.FreeLibros.org
244 Fundamentos de seguridad en redes. Aplicaciones y estndares
Cdigos de alerta
TLS admite todos los cdigos de alerta definidos en SSLv3 con la excepcin de la aler
ta no certificado (no_certifcat). En TLS se ha definido un nmero de cdigos adicio
nales, de los cuales, los siguientes son siempre fatales:
fallo d e descifrado (deciypaa_fa3edp. un texto cifrado se descifr de manera no
vlida; bien porque no result un mltiplo par de la longitud de bloque o bien por
que los valores de relleno, cuando se comprobaron, eran incorrectos.
sobrecarga d e r a s t r o (recard_ovao^: un registro TLS se recibi con una car
ga til (texto cifrado) cuya longitud excede de 244 + 2048 bytes, o el texto desci
frado result con una longitud mayor que 214 + 1024 bytes.
autoridad de certificacin desconocida {tnlatonn ca): se recibi una cadena o
cadena parcial vlida de certificados, pero el certificado no se acept porque el cer
tificado de la CA no se pudo localizar o no se pudo comprobar con una CA cono
cida o confiable.
acceso dcnegido ( access_ daiietf: se recibi un certificado vlido, pero al aplicar
el control de acceso, el emisor decidi no continuar con la negociacin.
error de decodificacin (d r o r fe o n v ): un mensaje no se pudo decodificar por
que algn campo estaba fuera de su rango especificado o la longitud del mensaje
era incorrecta.
restriccin d e portacin (expart_rfstrctot): se detect una negociacin en
desacuerdo con las restricciones de exportacin de la longitud de la clave.
versin d d protocolo (prviocol_imoa: se reconoci la versin del protocolo
que el cliente intent negociar, pero el servidor no la admite.
seguridad insuficknte (msufBcknt_seamtfi: devuelta en vez de fallo de la ne
gociacin cuando la negociacin ha errado especficamente porque el servidor ne
cesita cifradores ms seguros que los que tiene el cliente.
error interno un error interno no relacionado con el interlocutor
ni con el funcionamiento del protocolo hace imposible continuar.
El resto de nuevas alertas son las siguientes:
error de descifrado ( deaypt_m oi): fallo de alguna operacin criptogrfica du
rante la negociacin, entre las que se incluyen no poder verificar una firma, desci
frar un intercambio de clave o validar un mensaje de finalizacin.
cancelado per usuario (user_cancefeif: la negociacin se ha cancelado por al
guna razn no relacionada con fallos del protocolo.
no renegociacin {m_renego4atiorif: enviado por un cliente en respuesta a una
solicitud de saludo (hello_request) o por el servidor en respuesta a un saludo del
cliente (client_hello) despus de la negociacin inicial. Normalmente, cualquie
ra de esos mensajes activara la renegociacin, pero esta alerta indica que el
emisor no es capaz de renegociar. Este mensaje siempre es un aviso de precau
cin.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 245
Hay pequeas diferencias entre las suites de cifrado disponibles en SSLv3 y en TLS:
Intercambio d e dave: TLS permite todas las tcnicas de intercambio de claves
permitidas en SSLv3 con la excepcin de Fortezza.
Algoritmos d e cifrado simtrico: 'ILS incluye todos los algoritmos de cifrado si
mtricos encontrados en SSLv3, con la excepcin de Fortezza.
Tipos de certificado de cliente
TLS define los siguientes tipos de certificados requeridos en un mensaje de solicitud de
certificado: rsa_sign, dss_sign, rsa_fixed_dh y dss_fixed_dh. Todos estn definidos en
SSLv3. Adems, SSLv3 incluye rsa_ephemeral_dh, dss_ephemeral_dh y fortezza_kea.
Diffie-Hellman efmero implica firmar los parmetros de Diffie-Hellman con RSA o
DSS; para TLS, los tipos rsa_sign y dss_sgn se usan para esa funcin; no es necesario
un tipo separado de firma para firmar los parmetros de Diffie-Hellman. TLS no inclu
ye el esquema Fortezza.
Mensajes certificate_verify y finished
En el mensaje certicate_verify de TLS, los /?as/?MD5 y SHA-1 se calculan solamente
sobre los mensajes de negociacin. Recurdese que para SSLv3, el clculo del hash tam
bin inclua la clave maestra y los valores de relleno (pads). Estos campos extra no pa
recen suponer mayor seguridad.
Como con el mensaje de finalizacin en SSLv3, el de TLS es un hash basado en la
clave maestra compartida, los mensajes previos de la negociacin y una etiqueta que
identifica al servidor o al cliente. Los clculos son ligeramente diferentes. Para TLS te
nemos:
PRF(master_secret, finished_label, MD5(handshake_messages) || SHA-l(handshake_messages))
donde nished_Iabel es la ristra client nished para el cliente y server nished para el
servidor.
S u i t e s de cifrado
Clculos criptogrficos
El valor previo de la clave maestra (pre_master_secre) para TLS se calcula de la mis
ma manera que en SSLv3. Como en SSLv3, en TLS se calcula la clave maestra como
una funcin hash del valor previo de clave maestra y los dos nmeros aleatorios (ran-
dom) de los mensajes helio. EL clculo en TLS difiere del de SSLv3 y se define de la
siguiente manera:
master_secret =
PRF(pre_master_$ecret, "master secret", Client Hello.random || Server_Hello.random)
www.FreeLibros.org
2 4 6 Fundamentos de seguridad en redes. Aplicaciones y estndares
El algoritmo se aplica hasta producir 48 bytes pseudoaleatorios de salida. La gene
racin del material del bloque de claves (claves secretas para MAC, claves de cifrado de
sesin y vectores de inicializacin) se define de la siguiente forma:
key_block =
PRF(master_secret, "key expansin",
SecurityParameters.server_random || SecurityParameters.client_random)
hasta que se haya generado la cantidad suficiente de salida. Como en SSLv3, el bloque
de claves (key_blockj es una funcin de la clave maestra y de los nmeros aleatorios del
cliente y del servidor, pero para TLS, el algoritmo es diferente.
Relleno
En SSL, la cantidad de relleno aadido antes del cifrado de los datos de usuario es la m
nima necesaria, de manera que el tamao total de los datos que se van a cifrar es un ml
tiplo de la longitud del bloque de cifrado. En TLS, la cantidad de relleno puede ser cual
quier cantidad, como mximo hasta 255 bytes, para que el total sea mltiplo de la
longitud del bloque de cifrado. Por ejemplo, si el texto en claro (o comprimido si se usa
compresin) ms el MAC ms el byte de longitud del relleno {padding. Jength) es de 79
bytes, entonces la longitud de relleno, en bytes, puede ser uno, nueve, 17, etc. hasta 249.
Puede usarse una longitud variable del relleno para frustrar ataques basados en el anli
sis de las longitudes de los mensajes intercambiados.
7.3 SET (SECURE ELECTRONIC TRANSACTION)
SET es una especificacin abierta de cifrado y seguridad diseada para proteger tran
sacciones con tarjetas de crdito en Internet. La versin actual, SETvl, surgi a partir de
la peticin de MasterCard y Visa para crear un estndar de seguridad en febrero de 1996.
Un gran nmero de compaas se implicaron en el desarrollo de las especificaciones ini
ciales, entre las que se incluyen IBM, Microsoft, Netscape, RSA, Tersa y Verisign. En
1996 se comenz con numerosas pruebas del concepto, y en 1998 estaba disponible la
primera serie de productos orientados a SET.
SET no es un sistema de pago en s mismo, sino que ms bien es un conjunto de pro
tocolos de seguridad y formatos que permite a los usuarios emplear las infraestructuras
existentes de pago por tarjeta de crdito, de forma segura, en una red abierta como In
ternet. Bsicamente, SET proporciona tres servicios:
Proporciona un canal de comunicacin seguro entre todas las partes implicadas en
la transaccin
Proporciona confianza mediante el uso de certificados digitales X.509v3
Asegura la privacidad porque la informacin solamente est disponible cuando y
donde es necesario a las partes de una transaccin.
SET es una especificacin compleja definida en tres libros publicados en mayo de 1997:
www.FreeLibros.org
Captulo 7 / Seguridad de la web 247
Libro I: descripcin de negocios (Business Descriptior) (80 pgs.)
Libro 2: gua del programador (Programmers Guide) (629 pgs.)
Libro 3: definicin formal del protocolo (Formal Protocol Dention) (262 pgs.)
Esto hace un total de 971 pginas de especificaciones. Por el contrario, el tamao de
las especificaciones de SSLv3 es de 63 pginas y las de TLS de 80. Por tanto, en esta
seccin solamente se proporcionar un resumen de las muchas facetas de las especifi
caciones.
INTRODUCCIN A SET
Una buena manera de comenzar la discusin sobre SET es observando los requisitos que
exigen los negocios a SET, sus caractersticas fundamentales y los participantes en las
transacciones SET.
Requisitos
El Libro 1 de las especificaciones de SET enumera los siguientes requisitos para el pro
cesamiento de pago con tarjetas de crdito en Internet y en otras redes:
Proporcionar confidencialidad de la informacin d e pago y d e pedidoc es ne
cesario asegurar a los titulares de tarjetas que esta informacin est segura y acce
sible solamente a los receptores pertinentes. La confidencialidad tambin reduce el
riesgo de fraude en la transaccin, ya sea por una de las partes o por terceras par
tes dainas. SET utiliza cifrado para proporcionar confidencialidad.
Asegirar la integridad d e todos los datos transmitidos: esto es, asegurar que no
se producen cambios en el contenido de los mensajes SET durante la transmisin.
Para proporcionar integridad se utilizan firmas digitales.
Proporrionar autentifcacin d e que un titular de tarjeta es d usuario kgtim o
de in a cuenta de tarjeta de crditoe un mecanismo que enlace al titular de tarje
ta con un nmero especfico de cuenta reduce la incidencia de fraudes y los costes
globales del procesamiento de pago. Para verificar que un titular de tarjeta es un
usuario legtimo de una cuenta vlida se utilizan firmas digitales y certificados.
Proporcionar autentifcacin deque d comerciante puede aceptar transaccio
nes con tarjetas d e crdito a travs d e su relacin con una oitidad financiera:
este requisito es complementario del anterior. Los titulares de tarjetas necesitan po
der identificar a los comerciantes con los que realizan transacciones seguras. Otra
vez, se utilizan firmas digitales y certificados.
Asegurar d u so d e las mejores prcticas d e s a n id a d y tcnicas d e diseo de
sistemas para proteger a todas las partes legitimas m una transaccin d e co-
m o tio electrnica SET es una especificacin probada basada en protocolos y al
goritmos criptogrficos muy seguros.
Crear im protocolo que no dependa d e los mecanismos d e seguridad d e trans-
porteniqueevitesu uso: SET puede operar con seguridad sobre una pilaTCP/IP
www.FreeLibros.org
2 4 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
pura. Sin embargo, SET no interfiere en el uso de otros mecanismos de seguri
dad, tales como IPSec y SSL/TLS.
Facilitar y fomentar la interoperabilidad entre proveedores de software y re
des: los protocolos y formatos de SET son independientes de la plataforma hard
ware, del sistema operativo y del software Web.
Caractersticas fundamentales de SET
Para cumplir con los requisitos recin expuestos, SET incorpora las siguientes caracte
rsticas:
Confidencialidad d e informacin: la informacin de la cuenta del titular y del
pago est segura mientras viaja por la red. Una caracterstica interesante e impor
tante de SET es que evita que el comerciante conozca los nmeros de las tarjetas
de crdito; stos se proporcionan solamente al banco emisor. Para proporcionar
confidencialidad se utiliza cifrado convencional con DES.
Integridad d e los datos: la informacin enviada del pago efectuado con una tar
jeta desde el usuario hacia el comerciante incluye informacin del pedido, datos
personales e instrucciones de pago. SET garantiza que los contenidos del mensaje
no son alterados durante el trnsito. Las firmas digitales RSA, usando cdigos
hash SHA-1, proporcionan integridad a los mensajes. Ciertos mensajes se prote
gen tambin con HMAC usando SHA-1.
Autentificacin d e cuenta d d titular: SET permite a los comerciantes verificar
que un titular de tarjeta es un usuario legtimo de un nmero de cuenta de tarjeta
vlido. SET utiliza certificados digitales X.509v3 con firmas RSA para este pro
psito.
Autentificacin d d comodante: SET permite que los titulares verifiquen que un
comerciante tiene una relacin con una institucin financiera que le permite acep
tar tarjetas de pago. Con este fin, SET usa certificados digitales X.509v3 con fir
mas RSA.
Obsrvese que, al contrario que IPSec y SSL/TLS, SET proporciona slo una opcin
para cada algoritmo criptogrfico. Esto tiene sentido porque SET es una nica aplica
cin con un nico conjunto de requisitos, mientras que IPSec y SSL/TLS estn destina
dos a una variedad de aplicaciones.
Participantes de SET
La Figura 7.8 indica los participantes en el sistema SET, el cual incluye los siguientes:
Titular d e tarjeta o comprador: en el entorno electrnico, los consumidores y
entidades de compra interactan con los comerciantes desde computadores perso
nales en Internet. Un titular de tarjeta es un poseedor autorizado de una tarjeta de
pago (por ejemplo, MasterCard, Visa) que ha sido emitida por un emisor.
Vendedor: un vendedor es una persona u organizacin que tiene bienes y servicios
para vender a los titulares de tarjetas. Normalmente, esos bienes y servicios se
ofrecen en sitios web o por correo electrnico. Un vendedor que acepta tarjetas de
pago debe tener una relacin con un banco adquisidor.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 249
Emisor o banco d d comprador: es una institucin financiera como, por ejemplo,
un banco, que proporciona la tarjeta de pago al titular. Generalmente, las cuentas
se solicitan y se abren por correo electrnico o en persona. En ltima instancia, el
emisor es el responsable del pago de los dbitos del titular.
Adquisidor o banco d d vendedor: es una institucin financiera que establece una
cuenta con un vendedor y procesa las autorizaciones de tarjeta de pago y los pa
gos. Los vendedores, normalmente, aceptan ms de una marca de tarjeta de crdi
to pero no quieren tratar con mltiples asociaciones financieras o con mltiples
emisores individuales. El adquisidor proporciona autorizacin al vendedor indi
cndole que la cuenta de una tarjeta dada est activa y que la compra propuesta no
excede el lmite de crdito. El adquisidor tambin proporciona transferencia elec
trnica de pagos a la cuenta del vendedor. Posteriormente, el emisor realiza el re
embolso al adquisidor a travs de algn tipo de red de pago para transferencias
electrnicas de fondos.
Pasarela d e pago: esta funcin la realiza el adquisidor o una tercera parte designa
da a tal efecto que procesa los mensajes de pago del vendedor. La pasarela de pago
interacta entre SET y las redes de pago existentes de los bancos para realizar fun
ciones de autorizacin y de pago. El vendedor intercambia mensajes SET con la pa
sarela de pago en Internet, mientras que la pasarela de pagos tiene algunas conexio
nes directas o en red con los sistemas de procesamiento financiero del adquisidor.
A u to r i d a d d e c e r t if ic a c i n (C A ): sta es una entidad de confianza para emitir cer
tificados de clave pblica X.509v3 para titulares, vendedores y pasarelas de pago.
El xito de SET depender de una infraestructura de CA disponible para este pro
psito. Como se indic en captulos anteriores, se usa una jerarqua de autoridades
de certificacin, de forma que los participantes no necesiten ser certificados direc
tamente por una autoridad raz.
V e n d e d o r
Figura 7.8 Componentes del comercio electrnico seguro
www.FreeLibros.org
250 Fundamentos de seguridad en redes. Aplicaciones y estndares
Ahora se describe brevemente la secuencia de acciones necesarias para realizar una
transaccin. Luego se vern algunos de los detalles criptogrficos.
1. El comprador abre una cuenta El comprador obtiene una cuenta de tarjeta
de crdito como, por ejemplo, MasterCard o Visa, con un banco capacitado
para trabajar con pagos electrnicos y con SET.
2. El comprador redbeun certificada Despus de una verificacin satisfacto
ria de identidad, el comprador recibe un certificado digital X.509v3 firmado
por el banco. El certificado verifica la clave pblica RSA del comprador y su
fecha de caducidad. Tambin establece, garantizada por el banco, la relacin
entre el par de claves del comprador y su tarjeta de crdito.
3. Los vendedores tienen sus propios certificados. Un vendedor que acepta
cierta marca de tarjeta debe poseer dos certificados para dos claves pblicas
propiedad del vendedor: uno para firmar mensajes y otro para el intercambio
de claves. El vendedor tambin necesita una copia del certificado de clave p
blica de la pasarela de pago.
4 El comprador hace un pedida ste es un proceso que podra implicar que el
comprador navegue en el sitio web del vendedor para seleccionar productos y
determinar su precio. Luego enva una lista de productos que desea comprar al
vendedor, quien devuelve un formulario de pedido con la lista de productos, sus
precios, el precio total y un nmero de pedido.
5i S e verifica al vendedor. Adems del formulario de pedidos, el vendedor enva
una copia de su certificado, de manera que el comprador pueda verificar que
est tratando con un comercio vlido.
fi S e a n ia n la orden d e compra y la de paga El comprador enva la orden de
compra y la informacin de pago al vendedor, junto con su certificado. La pri
mera confirma la compra de los productos del formulario de pedido. La segun
da contiene los detalles de la tarjeta de crdito. La informacin de pago se ci
fra para que el vendedor no pueda leerla. El certificado del comprador permite
que ste sea verificado por el vendedor.
7. El v o id a k r solicita la autorizacin d d paga El vendedor enva la informa
cin de pago a la pasarela de pago, solicitando autorizacin que confirme que
el crdito disponible del comprador es suficiente para realizar la compra.
& El vendedor confirma la orden de compra El vendedor enva confirmacin
de la orden de compra al comprador.
9. El vmdedor suministra los produdas o servidos. El vendedor enva los pro
ductos o proporciona los servicios al comprador.
10l El vendedor solicita el paga Esta solicitud se enva a la pasarela de pago, la
cual maneja todo el procesamiento de pagos.
FIRMA DUAL
Antes de ver en detalle el protocolo SET, vamos a tratar una innovacin importante in
troducida en SET: la firma dual. La finalidad de la firma dual es asociar dos mensajes
www.FreeLibros.org
Captulo 7 / Seguridad de la web 251
destinados a dos receptores diferentes. En este caso, el comprador quiere enviar la in
formacin de orden de compra (OI, order nformation) al vendedor y la informacin de
pago (PI, payment informador!) al banco. El vendedor no necesita conocer el nmero de
la tarjeta de crdito del comprador, y el banco no necesita saber los detalles del pedido
del comprador. ste obtiene una proteccin extra en trminos de privacidad mantenien
do esos dos elementos separados. Sin embargo, los dos elementos deben estar asociados
de forma que se puedan utilizar para resolver disputas si fuera necesario. La asociacin
es necesaria para que el comprador pueda probar que este pago est destinado a esta or
den de compra y no para otro producto o servicio.
Para entender la necesidad de esta asociacin, supongamos que los compradores en
van al vendedor dos mensajes -uno de OI firmado y uno de PI firmado- y el vendedor
pasa el de PI al banco. S el vendedor puede capturar otra OI de este comprador, el ven
dedor podra reclamar que este OI va con el PI en vez de la OI original. La asociacin
de los mensajes evita esta situacin.
La Figura 7.9 muestra el uso de la firma dual para satisfacer los requisitos reseados
en el prrafo anterior. El comprador calcula el hash (utilizando SHA-1) de la PI y el hash
de la OI. Concatena los dos hash y calcula el hash del resultado. Por ltimo, el compra
dor cifra el hash final con su clave privada de firma, creando la firma dual. La operacin
se puede resumir como:
DS = E ^ H f H f P I ) || H(OI))]
donde KRq es la clave de firma privada del comprador. Ahora supongamos que el ven
dedor est en posesin de la firma dual (DS, dual signa tur), la OI y el resumen del
mensaje de PI (PIMD). El vendedor tambin tiene la clave pblica del comprador, to
mada del certificado de ste. Entonces el vendedor puede calcular las siguientes dos
cantidades:
H(PIMD) | | H ( O D ) y D ^ p S ]
donde KUces la clave de firma pblica del comprador. Si esas dos cantidades son igua
les, entonces el vendedor ha verificado la firma. De manera similar, si el banco est en
posesin de la DS, la PI y un resumen del mensaje de OI (OIMD) y la clave pblica del
comprador, entonces el banco puede calcular lo siguiente:
H(H(PI) || O I M D ) y D ^ j D S ]
Otra vez, si esas dos cantidades son iguales, entonces el banco ha verificado la fir
ma. Resumiendo,
1. El vendedor ha recibido el mensaje de OI y ha verificado la firma.
2. El banco ha recibido el mensaje de PI y ha verificado la firma.
3. El comprador ha asociado los mensajes de OI y de PI y puede probar tal asocia-
cia
Por ejemplo, supongamos que el vendedor desea sustituir una OI por otra durante esta
transaccin para obtener provecho. Entonces tendra que encontrar otra OI cuyo hash
coincidiera con el OIMD existente. Con SHA-1, esto no se considera factible. Por eso,
el vendedor no puede asociar una OI diferente a la que se corresponde con el PI dado.
www.FreeLibros.org
252 Fundamentos de seguridad en redes. Aplicaciones y estndares
Pl
PIMD
Firma
d u a l
1 7 7 % ^
POMD
/ / / / , e
OIMD
*ezzs
Pl = I n f o r m a c i n d e pa g o PIMD = Resumen del m e n s a j e d e Pl
01= I n f o r m a c i n d e o r d e n d e c o m p r a OIMD = Resumen del m e n s a j e d e 01
H = Fu nci n h a sh (SHA-1) POMD = Resumen d e m e n s a j e d e o r d e n d e pago
|| = C onca tena cin E = C i f r a d o (RSA)
KRC = Cl a v e p r iv a d a d e f i r m a del c o m p r a d o r
Figura 7.9 Construccin de la firma dual
PROCESAMIENTO DEL PAGO
La Tabla 7.3 enumera los tipos de transacciones permitidos por SET. A continuacin ve
remos algunos detalles de las transacciones siguientes:
Solicitud de compra
Autorizacin de pago
Captura de pago
Solicitud de compra
Antes de que comience el intercambio de solicitud de compra, el comprador ha com
pletado la navegacin en el sitio web, la seleccin de productos o servicios y la solici
tud de compra. El final de esta fase preliminar ocurre cuando el vendedor enva un for
mulario de compra completo al comprador. Todos los pasos precedentes se realizan sin
la intervencin de SET
El intercambio de solicitud de compra se compone de cuatro mensajes: solicitud de
inicio, respuesta de inicio, solicitud de compra y respuesta de compra.
Para poder enviar mensajes SET al vendedor, el comprador debe tener una copia de
los certificados del vendedor y de la pasarela de pago. El comprador solicita los certifi
cados en el mensaje de soliad de mido, enviado al vendedor. Este mensaje incluye
la clase de tarjeta de crdito que usa el comprador. El mensaje tambin incluye un iden
tificador asignado por el comprador para el par solicitud/respuesta y un valor nonce uti
lizado para garantizar la validez temporal.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 253
Tabla 7.3 Tipos de transacciones SET
Re g is tr o d e t i t u l a r Los t i t u l a r e s d e b e n r e g i s t r a r s e co n u n a C A a n t e s d e q u e
p u e d a n e n v i a r m e n s a j e s S E T a l os v e n d e d o r e s .
Re g is tr o d e v e n d e d o r Los v e n d e d o r e s d e b e n r e g i s t r a r s e co n u n a C A a n te s d e
qu e p u e d a n i n t e r c a m b i a r m e n s a j e s S E T co n c o m p r a d o r e s
y p a s a r e l a s d e pa go .
S o l i c i t u d d e c o m p r a M e n s a j e de l c o m p r a d o r a l v e n d e d o r q u e c o n t i e n e la 01
p a r a el v e n d e d o r y l a Pl p a r a el ba nco .
A u t o r i z a c i n d e p a g o I n t e r c a m b i o e n t r e v e n d e d o r y p a s a r e l a d e p a g o q u e a u t o
r iza u n a c a n t i d a d d e t e r m i n a d a p a r a el p a g o d e u n a c o m
p r a co n u n a c u e n t a d e t a r j e t a d e c r d i t o d a d a .
C a p t u r a d e p a g o P e r m i t e a l v e n d e d o r s o l i c i t a r el p a g o a l a p a s a r e l a de
p a go .
I n f o r m e y e s t a d o d e
c e r t i f i c a d o
S i la C A es i n c a p a z d e c o m p l e t a r el p r o c e s a m i e n t o d e un a
s o l i c i t u d d e c e r t i f ic a d o r p i d a m e n t e , e n v i a r u n a r e s p u e s
t a al c o m p r a d o r o al v e n d e d o r i n d i c a n d o q u e el s o l i c i t a n t e
d e b e r v o l v e r r e a l i z a r l a c o m p r o b a c i n m s ta r d e . El t i
t u l a r o e l v e n d e d o r e n v a e l m e n s a j e d e i n f o r m e d e c e r t i f i
c a d o p a r a d e t e r m i n a r el e s t a d o d e l a s o l i c i t u d d e s t e y r e
c ib i r l o si la s o l i c i t u d h a s i d o a c e pt a da .
I n f o r m e d e c o m p r a P e r m i t e a l c o m p r a d o r c o m p r o b a r el e s t a d o d e p r o c e s a
m i e n t o d e u n a o r d e n d e c o m p r a d e s p u s d e r e c i b i r l a r e s
p u e s t a d e c o m p r a . O b s r v e s e q u e e s t e m e n s a j e n o i n c l u
y e i n f o r m a c i n c o m o el e s t a d o d e l o s p r o d u c t o s
s o l i c i t a d o s s i n o q u e i n d i c a el e s t a d o d e a u t o r i z a c i n , c a p
t u r a y p r o c e s a m i e n t o de l c r d i t o .
D e s h a c e r a u t o r i z a c i n P e r m i t e a l o s v e n d e d o r e s c o r r e g i r s o l i c i t u d e s d e a u t o r i z a
c in p r e v i a s . S i l a o r d e n d e c o m p r a n o s e p u e d e c o m p l e
t a r , el v e n d e d o r d e s h a c e l a a u t o r i z a c i n c o m p l e t a . Si p a r
t e d e l a o r d e n d e p e d i d o n o se p u e d e c o m p l e t a r ( c o m o
c u a n d o s e o r d e n a l a d e v o l u c i n d e a l g u n o o a l g u n o s d e
l o s p r o d u c t o s s o l i c i t a d o s ) , el v e n d e d o r d e s h a c e o d e s
c u e n t a l a c a n t i d a d c o r r e s p o n d i e n t e d e l a a u t o r i z a c i n .
D e s h a c e r ca ptu ra P e r m i t e a l o s v e n d e d o r e s c o r r e g i r e r r o r e s e n las s o l i c i t u
de s d e c a p t u r a t a l e s c o m o c a n t i d a d e s d e l a s t r a n s a c c i o n e s
i n t r o d u c i d a s e r r n e a m e n t e p o r u n e m p l e a d o .
C r d i t o P e r m i t e a u n v e n d e d o r r e a l i z a r u n a b o n o e n l a c u e n t a de l
c o m p r a d o r y a sea p o r l a d e v o l u c i n d e l os p r o d u c t o s o
p o r q u e se d a a r o n d u r a n t e l a e n t r e g a . O b s r v e s e q u e el
m e n s a j e d e c r d i t o d e S E T lo i n i c i a s i e m p r e e l v e n d e d o r ,
n u n c a el c o m p r a d o r . T o d a s las c o m u n i c a c i o n e s e n t r e c o m
p r a d o r y v e n d e d o r q u e h a y a n d a d o c o m o r e s u l t a d o el p r o
c e s a m i e n t o d e u n c r d i t o ( a b o n o ) o c u r r e n f u e r a d e SET.
D e s h a c e r c r d ito P e r m i t e a u n v e n d e d o r c o r r e g i r u n a s o l i c i t u d d e c r d i t o
p r e v i a .
S o l i c i t u d d e c e r t i f i c a d o
d e p a s a r e l a d e p a g o
P e r m i t e a u n v e n d e d o r c o n s u l t a r a l a p a s a r e l a d e p a g o y
r e c i b i r u n a c o pi a d e l o s c e r t i f i c a d o s a c t u a l e s d e f i r m a y de
i n t e r c a m b i o d e c l a v e d e l a p a s a r e la .
A d m i n i s t r a c i n p o r
lotes
P e r m i t e a u n v e n d e d o r c o m u n i c a r i n f o r m a c i n a l a p a s a
r el a d e p a g o r e f e r e n t e a lo te s de l v e n d e d o r
M e n s a j e d e e r r o r I n d i c a q u e el q u e c o n t e s t a r echaza u n m e n s a j e p o r q u e f a
lla n l a s c o m p r o b a c i o n e s d e v e r i f i c a c i n d e l c o n t e n i d o o
de l f o r m a t o .
www.FreeLibros.org
254 Fundamentos de seguridad en redes. Aplicaciones y estndares
M e n s a j e d e s o l i c i t u d
Pasado
p o r el v e n d e d o r
) a la pasarela
de pago
Recibido
p o r el v e n d e d o r
Pl = Informacin d e pago
01 = Informacin d e orden de compra
PIMD = Resumen d e l mensaje de Pl
OIMD = Resumen d e l mensaje de 01
E = Cifrado (RSA para asimtri co; DES
para simtrico)
Ks = Clave privada de f i r m a d e l comprador
KUb = Clave privada de f i r m a d e l comprador
Figura 7.10 El comprador enva la solicitud de compra
El vendedor genera una respuesta y la firma con su clave de firma privada. La res
puesta incluye el nonce recibido del comprador, otro nonce para que el comprador lo de
vuelva en el prximo mensaje y un identificador de transaccin para esta transaccin de
compra. Adems de la respuesta firmada, el mensaje de Respuesta d e Inicio incluye el
certificado de firma del vendedor y el certificado de intercambio de clave de la pasarela
de pago.
El comprador verifica los certificados del vendedor y de la pasarela por medio de sus
respectivas firmas de la autoridad de certificacin y entonces crea la 01 y la PL El iden-
tifcador de la transaccin asignado por el vendedor se coloca en la 01 y en la PL La 01
no contiene datos explcitos del pedido como son el nmero y el precio de los produc
tos. Lo que contiene es una referencia de la orden de compra generada durante el inter
cambio entre comprador y vendedor en la fase anterior al primer mensaje de SET Des
pus, el comprador prepara el mensaje de Solicitud d e Compra (Figura 7.10). Para este
propsito, el comprador genera una clave de cifrado simtrico de un solo uso, K$ El
mensaje incluye lo siguiente:
L Informacin relativa a la adquisicin. Esta informacin ser reenviada a la pa
sarela de pago por el vendedor y consiste en
La Pl
www.FreeLibros.org
Captulo 7 / S e g ur ida d de la web 255
La firma dual, calculada sobre PI y 01, firmada con la clave privada de firma
del comprador
El resumen del mensaje de la OI (OIMD)
El OIMD es necesario para que la pasarela de pago verifique la firma dual, como
se explic anteriormente. Todos esos elementos se cifran con K$ El elemento fi
nal es
El sobre digital. ste se forma cifrando K$ con la clave pblica de intercam
bio de clave de la pasarela de pago. Se le llama sobre digital porque debe abrir
se (descifrarse) antes de que se puedan leer los elementos mencionados pre
viamente.
El valor de Ks no est disponible para el vendedor. De esta manera, ste no puede leer
la informacin relativa al pago.
2. Informacin relativa a la orden d e compra Esta informacin es necesaria
para el vendedor y consiste en
La OI
La firma dual, calculada sobre la PI y la OI, firmada con la clave privada de
firma del comprador
El resumen del mensaje de PI (PIMD)
El PIMD lo necesita el vendedor para verificar la firma dual. Obsrvese que la
OI se enva sin cifrar (en claro).
3 Certificado del comprador. Contiene la clave pblica de firma del comprador.
Lo necesitan el vendedor y la pasarela de pago.
Cuando el vendedor recibe el mensaje de solicitud de compra, realiza las siguientes ac
ciones (Figura 7.11):
1. Verifica los certificados del comprador mediante sus firmas de la CA.
2. Verifica la firma dual utilizando la clave de firma pblica del comprador. Esto
garantiza que la orden de pedido no ha sido modificada durante el trnsito y que
ha sido firmada con la clave de firma privada del comprador.
3 Procesa el pedido y reenva la informacin de pago a la pasarela de pago para la
autorizacin (que se describe ms tarde).
4 Enva una respuesta de compra al comprador.
El mensaje de Respuesta d e Compra incluye un bloque de respuesta que reconoce el
pedido y referencia el nmero de transaccin correspondiente. Este bloque lo ha firma
do el vendedor con su clave de firma privada. El bloque y su firma se envan al com
prador, junto con el certificado de firma del vendedor.
Cuando el software del comprador recibe el mensaje de respuesta de compra, verifi
ca el certificado del vendedor y luego verifica la firma del bloque de respuesta. Final
mente, realiza algunas acciones basadas en la respuesta, tales como mostrar un mensaje
en la pantalla del usuario o actualizar una base de datos con el estado del pedido.
www.FreeLibros.org
256 Fundamentos de seguridad en redes. Aplicaciones y estndares
Mensaje
de s o l i c i t u d
S o b r e
d i g i t a l
X 2 2 X
PIMD
OI
F i r m a
d u a l
------


H
C e r t i f i c a d o
d e l c o m p r a d o r
Pasado
p o r el v e n d e d o r
a la pasarela
de pago
0 1 = I n f o r m a c i n d e o r d e n d e c o m p r a
O I M D = R e s u m e n d e l m e n s a j e d e P l
P O M D = R e s u m e n d e l m e n s a j e d e 0 1
D = D e s c r y p t i o n ( R S A )
H = Hash f u n c ti o n ( S H A - 1 )
KUC = Customer's p u b l i c signature key
O
H
POMD
*22223
HZZZZ3
Comp ara cin
OIMD
EZZZ2
POMD
KUC
Figura 7.11 El vendedor verifica la solicitud de compra del comprador
A u t o r i z a c i n d e pago
Durante el procesamiento de una orden de pedido de un comprador, el vendedor autori
za la transaccin con la pasarela de pago. La autorizacin de pago asegura que la tran
saccin fue aprobada por el emisor de la tarjeta. La autorizacin de pago garantiza que
el vendedor recibir el dinero; por lo tanto, el vendedor puede proporcionar los servicios
o productos al comprador. El intercambio de autorizacin de pago consta de dos men
sajes: solicitud de Autorizacin y Respuesta de Autorizacin.
El vendedor enva a la pasarela de pago un mensaje de Solitiid d e Autorizacin
que contiene lo siguiente:
L Informacin relativa a la adquisicin. Esta informacin se obtuvo del com
prador y consta de lo siguiente:
La Pl
La firma dual, calculada sobre la Pl y la OI, firmada con la clave privada de
firma del comprador
El resumen del mensaje de OI (OIMD)
El sobre digital
www.FreeLibros.org
Captulo 7 / Seguridad de la web 257
2 Informacin rdativa a la autorizacin. Esta informacin es generada por el
vendedor y consta de
Un bloque de autorizacin que incluye el identificador de la transaccin, fir
mado con la clave de firma privada del vendedor y cifrado con una clave si
mtrica de un solo uso generada por el vendedor
Un sobre digital. ste se forma cifrando la clave de un solo uso con la clave
de intercambio de clave pblica de la pasarela de pago.
3L Certificados. El vendedor incluye el certificado de clave de firma del compra
dor (utilizado para verificar la firma dual), el certificado de clave de firma del
vendedor (utilizado para verificar la firma del vendedor) y el certificado de in
tercambio de clave del vendedor (necesario en la respuesta de la pasarela de
pago).
La pasarela de pago realiza las siguientes tareas:
1. Verifica todos los certificados
2. Descifra el sobre digital del bloque de autorizacin para obtener y descifrar la
clave simtrica de ste
3. Verifica la firma del vendedor contenida en el bloque de autorizacin
4 Descifra el sobre digital del bloque de pago para obtener y descifrar la clave si
mtrica de ste
5. Verifica la firma dual contenida en el bloque de pago
ti. Verifica que el identificador de la transaccin recibido del vendedor coincide con
el recibido en el mensaje de PI (indirectamente) del comprador
7. Solicita y recibe una autorizacin del emisor de la tarjeta
Una vez obtenida la autorizacin del emisor de la tarjeta, la pasarela de pago devuelve
un mensaje de Respuesta de Autorizacin al vendedor que incluye los siguientes ele
mentos:
L Informacin relativa a la autorizacin. Incluye un bloque de autorizacin, fir
mado con la clave de firma privada de la pasarela y cifrado con una clave sim
trica de un solo uso generada por la pasarela. Tambin incluye un sobre digital
que contiene la clave de un solo uso cifrada con la clave de intercambio de cla
ve pblica del vendedor.
2. Informacin d d bono d e captura. Esta informacin se utilizar para efectuar
el pago ms tarde. Este bloque tiene la misma forma que el (1), es decir, un bono
de captura firmado y cifrado junto con un sobre digital. Este bono no es proce
sado por el vendedor, sino que debe ser devuelto, como est, con una solicitud
de pago.
3L Certificada El certificado de clave de firma de la pasarela.
Con la autorizacin de la pasarela, el vendedor puede proporcionar los productos o ser
vicios al comprador.
www.FreeLibros.org
258 Fundamentos de seguridad en redes. Aplicaciones y estndares
Captura de pago
Para cobrar el dinero, el vendedor realiza una transaccin de captura de pago con la pa
sarela de pago, que consta de un mensaje de solicitud de captura y otro de respuesta de
captura.
Para el mensaje de Solicitud de Captura, el vendedor genera, firma y cifra un blo-
oue de solicitud de captura, que incluye la cantidad que se va a cobrar y el identificador
ae la transaccin. El mensaje tambin incluye el bono de captura cifrado recibido re
cientemente (en la respuesta de autorizacin) para esta transaccin, as como los certifi
cados de clave de firma y clave de intercambio de clave del vendedor.
Cuando la pasarela de pago recibe el mensaje de solicitud de captura, descifra y ve
rifica el bloque de solicitud de captura y descifra y verifica el bloque del bono de cap
tura. Entonces comprueba la consistencia entre la solicitud de captura y el bono de
captura. Luego crea una solicitud de liquidacin que se enva al emisor de la tarjeta a
travs de una red privada de servicios de pago. Esta solicitud hace que se transfieran los
fondos a la cuenta del vendedor.
La pasarela, entonces, notifica al vendedor la realizacin del pago en un mensaje de
Respuesta de Captura El mensaje incluye un bloque de respuesta de captura firmado
y cifrado por la pasarela. Tambin incluye el certificado de clave de firma de la pasare
la. El software del vendedor almacena la respuesta de captura que se utiliza para su com
probacin con los pagos recibidos del adquisidor.
7.4 BIBLIOGRAFA Y SITIOS WEB RECOMENDADOS
[RESC01] trata en detalle SSL y TLS.
La mejor descripcin sobre SET se encuentra en el Libro 1 de las especificaciones,
disponible en el sitio web SET de MasterCard. Otra descripcin general muy til se en
cuentra en [MACG97]. [DREW99] es tambin una buena fuente.
DREW99 Drew, G. UsngSET forSecure Electronic Commerce. Upper Saddle Ri-
ver, NJ: Prentice Hall, 1999.
MACG97 Macgregor, R.; Ezvan, C.; Liguori, L.; y Han, J. Secure Electronic Trans-
actions: Credt Card Payment on the Web in Theory and Practice. IBM
RedBook SG244978-00, 1997. Disponible en www.redbooks.ibm.com.
RESCOI Rescorla, E. SSL and TLS: Designing and Building Secure Systems.
Reading, MA: Addison-Wesley, 2001.
Sitios web recomendados:
Pgina web SSL de Netscape contiene las especificaciones de SSL.
Transport Layer Security Charten ltimos RFCs y borradores de Internet sobre
TLS.
Pgina web SET de MasterCard: ltimos documentos sobre SET, glosario de
trminos, informacin de aplicacin.
SETCo: ltimos documentos SET y glosario de trminos, entre otros.
www.FreeLibros.org
Captulo 7 / Seguridad de la web 259
7.5 PALABRAS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
RELABRAS CLAVE
Adquisidor o banco del
vendedor
Autoridad de certifica
cin (CA)
Comprador/titular
Emisor de tarjeta
PREGUNTAS DE REPASO
7.1. Cules son las ventajas de cada uno de los tres enfoques de la Figura 7.1?
7.2. De qu protocolos se compone SSL?
7.3. Cul es la diferencia entre una conexin SSL y una sesin SSL?
7 .4 Cita y describe brevemente los parmetros que definen un estado de sesin de
SSL.
7 . 6 Cita y describe brevemente los parmetros que definen una conexin de sesin
de SSL.
7.6. Qu servicios proporciona el protocolo Record de SSL?
7.7. Qu pasos implica la transmisin del protocolo Record de SSL?
7 .6 Enumera y define brevemente las principales categoras de participantes de
SET.
7.9. Qu es una firma dual y cul es su propsito?
PROBLEMAS
7 .1 . Por qu hay un protocolo Change Cipher Spec separado en SSL y TLS, en
vez de incluir un mensaje change_cipher_spec en el protocolo Handshakel
7.2. Considera las siguientes amenazas a la seguridad Web y describe cmo se con
trarresta cada una mediante una caracterstica particular de SSL.
a) Ataque criptoanaltico de fuerza bruta: una bsqueda exhaustiva del espa
cio de claves para un algoritmo de cifrado convencional.
b) Ataque por diccionario de texto claro conocido: muchos mensajes contienen
texto claro predecible, como el comando GET de HTTP. Un atacante cons
truye un diccionario que contiene todos los posibles cifrados del mensaje de
texto claro conocido. Cuando un mensaje cifrado es interceptado, el atacan
te extrae la porcin que contiene el texto claro conocido cifrado y busca el
texto cifrado en el diccionario. El texto cifrado debera coincidir con una en
trada del diccionario cifrada con la misma clave secreta que el mensaje. Si
Firma dual SSL (Secare Socket Layer)
Pasarela de pago TLS (Transport Layer Secu-
SET (Secure Electronic rty)
Transaction) Vendedor
www.FreeLibros.org
260 Fundamentos de seguridad en redes. Aplicaciones y estndares
hubiera varas coincidencias, se puede probar aplicando cada una a todo el
texto cifrado para determinar cul es la correcta. Este ataque es especial
mente eficaz con claves de pequeo tamao (por ejemplo, claves de 40 bits).
c) Ataque de repeticin: los mensajes de negociacin de SSL anteriores son
repetidos.
d) Ataque de interceptacin: un atacante se interpone durante el intercambio
de clave, actuando como el cliente para el servidor y como el servidor para
el cliente.
Escucha de contraseas: se estn observando las contraseas de HTTP o el
trfico de otras aplicaciones.
0 Suplantacin IP: uso de direcciones IP robadas para conseguir que un
computador acepte datos fraudulentos.
g Secuestro de IP: el atacante interrumpe una conexin activa y autentificada
entre dos computadores hacindose pasar por uno de ellos.
h) Inundacin SYN: un atacante enva mensajes SYN de TCP solicitando una
conexin, pero no responde al mensaje final para establecer sta por com
pleto. El mdulo TCP atacado normalmente deja la conexin abierta du
rante unos pocos minutos. La repeticin continua de mensajes SYN puede
atascar el mdulo TCP.
7.3 Es posible en SSL, basndote en lo aprendido en este captulo, que un recep
tor reordene bloques de registro de SSL que llegan desordenados? Si es as, ex
plica cmo se puede hacer. Si no, por qu no?
www.FreeLibros.org
C A P T U L O 8
Seguridad en la
gestin de redes
8.1 Conceptos bsicos de SNMP
A r q u i t e c t u r a de gesti n de red
A r q u i t e c t u r a del p r o t o c o l o de g e s t i n de red
Ag e n t e s pr o x y
SNMPv2
8.2 Comunidades S N M P v l
C o m u n i d a d e s y n o m b r e s de c o m u n i d a d e s
Servicio de a u te n t if i c a c i n
Poltica de acceso
Se r v ic io pr o x y
8.3 SNMPv3
A r q u i t e c t u r a SNMP
Procesamiento de m e n s a j e s y m o d e l o de se gu ri d ad de u s u a ri o
C o n t r o l de acceso basado en vistas
8.4 Bibliografa y sitios web recomendados
8.5 Trminos clave, preguntas de repaso y problemas
T r m in o s clave
Preguntas de repaso
Problemas
www.FreeLibros.org
262 Fundamentos de seguridad en redes. Aplicaciones y estndares
El control de una gran fuerza es, en principio, e l mismo que el de unos pocos hombres;
slo es cuestin de dividirlos.
E l arte de Jadiara, S u n T z u
L
a importancia de las redes y los sistemas de procesamiento distribuido ha aumen
tado en el mbito de los negocios, el gobierno y otras organizaciones. En una
institucin dada, se tiende a establecer redes mayores y ms complejas para dar
cabida a ms aplicaciones y ms usuarios. A medida que se produce el crecimiento de
estas redes, se hacen evidentes dos hechos fundamentales:
La red, sus recursos asociados y las aplicaciones distribuidas se convierten en ele
mentos indispensables para la organizacin.
Pueden fallar ms cosas, inhabilitando la red o una parte de ella o reduciendo el
rendimiento a niveles inaceptables.
Una red extensa no se puede instalar y gestionar slo con el esfuerzo humano. La com
plejidad de un sistema de este tipo exige el uso de herramientas automatizadas de ges
tin de red. Si, adems, la red incluye equipamiento de mltiples distribuidores, aumenta
la necesidad de disponer de dichas herramientas, as como la dificultad en suministrar
las. En respuesta a esta necesidad, se han desarrollado estndares que tratan sobre la ges
tin de red, que abarcan servicios, protocolos y bases de datos de informacin de ges
tin. Hasta ahora, el estndar ms utilizado es el SNMP (Simple Network Management
Pro toe oi) .
Desde su publicacin en 1988, SNMP se ha usado en un nmero de redes cada vez
mayor y en entornos cada vez ms complejos. A medida que se extenda el uso de
SNMP, se necesitaban nuevas funcionalidades para ajustarse a las nuevas demandas.
Tambin, la importancia de proporcionar seguridad como parte de la gestin de redes se
hizo cada vez ms evidente. Para mejorar la funcionalidad, se defini la versin 2 de
SNMP'. Las mejoras de la seguridad fueron promulgadas en SNMPv3.
Este captulo describe la herramienta rudimentaria de seguridad de SNMPvl y el
conjunto de caractersticas de seguridad mucho ms extenso que ofrece SNMPv3.
8.1 CONCEPTOS BSICOS DE SN M P
Esta seccin ofrece una descripcin de los conceptos bsicos de SNMP.
ARQUITECTURA DE GESTIN DE RED
Un sistema de gestin de red es un conjunto de herramientas para supervisar y contro
lar la red y que se considera integrado en los siguientes sentidos:
1 La versin 2 se conoce como SNMPv2. Para distinguir la versin original de la nueva, la original se
conoce en la actualidad como SNMPvl.
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 263
Una sola interfaz de operador con un grupo de comandos potentes, pero sencillos,
para realizar la mayora de las tareas de gestin de red o, incluso, todas.
Una cantidad mnima de equipamiento separado. Es decir, la mayor p r t e del hard
ware y el software necesarios para la gestin de red est incorporada en el equipo
del usuario.
Un sistema de gestin de red se compone de hardware y software adicionales imple-
mentados entre los componentes de red existentes. El software que se emplea en las ta
reas de gestin de red reside en los host y en los procesadores de comunicaciones (por
ejemplo, procesadores frontales (front-end), controladores de grupos de terminales). Un
sistema de gestin de red est diseado para ver toda la red como una arquitectura uni
ficada, con direcciones y etiquetas asignadas a cada punto y los atributos especficos de
cada elemento y enlace conocidos por el sistema. Los elementos activos de la red pro
porcionan una retroalimentacin regular de la informacin de estado al centro de con
trol de red.
El modelo de gestin de red que se usa para SNMP incluye los siguientes elementos
fundamentales:
Estacin de gestin
Agente de gestin
Base de informacin de gestin
Protocolo de gestin de red
La estacin d e gestin es, normalmente, un dispositivo autnomo, pero puede ser una
capacidad implementada en un sistema compartido. En cualquier caso, la estacin de
gestin sirve como interfaz para que el administrador de red humano acceda al sistema
de gestin de red. La estacin de gestin, como mnimo, tendr:
Un conjunto de aplicaciones de gestin para el anlisis de los datos, recuperacin
de fallos, etc.
Una interfaz mediante la cual el administrador puede supervisar y controlar la red
La capacidad de trasladar los requerimientos del administrador de red a la super
visin y el control real de elementos remotos en la red
Una base de datos de informacin extrada de las MIB o bases de datos de infor
macin de gestin de todas las entidades gestionadas en la red
Slo los dos ltimos elementos estn sujetos a la normalizacin de SNMP.
El otro elemento activo en el sistema de gestin de red es el agmte d e gestin Las
plataformas principales, como hosts; puentes, routersy concentradores (hubs) se pueden
equipar con SNMP para que puedan ser gestionadas desde una estacin de gestin. El
agente responde a las solicitudes de informacin y accin provenientes de una estacin
de gestin y puede, de forma asincrona, proporcionar a la estacin de gestin informa
cin importante aunque no haya sido solicitada.
Para gestionar los recursos de la red, cada recurso se representa como un objeto. B
sicamente, un objeto es una variable de datos que representa un aspecto del agente ges
tionado. El conjunto de objetos se conoce como braede informacin d e gestin (MIB,
Management Information Bas). La MIB funciona como un conjunto de puntos de ac
www.FreeLibros.org
264 Fundamentos de seguridad en redes. Aplicaciones y estndares
ceso en el agente para la estacin de gestin. Estos objetos estn estandarizados en los
distintos tipos de sistemas (por ejemplo, todos los puentes tienen los mismos objetos de
gestin). Una estacin de gestin realiza la funcin de supervisin mediante la recupe
racin del valor de los objetos de la MIB. Tambin puede hacer que una accin tenga lu
gar en un agente o puede cambiar la configuracin de un agente modificando el valor de
objetos especficos.
La estacin de gestin y los agentes se comunican medante un protocolo de gestin
de red. El protocolo que se emplea para la gestin de redes TCP/IP es el protocolo sen
cillo de gestin de red (SNMP, Simple Network Management Protocol). Este protocolo
incluye las siguientes capacidades fundamentales:
G et permite a la estacin de gestin obtener el valor de los objetos del agente
S e t permite a la estacin de gestin establecer los valores de los objetos del agente
Notfy. permite al agente notificar los hechos significativos a la estacin de gestin
ARQUITECTURA DEL PROTOCOLO DE GESTIN DE RED
En 1988 se public la especificacin para SNMP y rpidamente se convirti en el es
tndar predominante de gestin de red. Una serie de distribuidores ofrecen estaciones de
gestin de red autnomas basadas en SNMP, y la mayora de los vendedores de puentes,
routers, estaciones de trabajo y computadores personales ofrecen paquetes de agente
SNMP que permiten que sus productos sean gestionados por una estacin de gestin
SNMP.
Como el nombre sugiere, SNMP es una herramienta sencilla para la gestin de red.
Define una base de informacin de gestin (MIB), limitada y de fcil implementacin,
de variables escalares y tablas de dos dimensiones, y define un protocolo ms eficiente
para permitir que un administrador obtenga y establezca variables de la MIB y que un
agente emita notificaciones no solicitadas, llamadas interceptaciones (traps). La robus
tez de SNMP se basa en esta simplicidad. SNMP se implementa fcilmente y consume
una cantidad moderada de recursos de procesador y de red. Adems, las estructuras del
protocolo y de la MIB son lo suficientemente sencillas para facilitar la interaccin entre
las estaciones de gestin y software de agente de diversos vendedores.
Las tres especificaciones fundamentales son:
Estructura eMcntificacin de la infcnnan degestida para redes b a s a d a s en
TCP/IP (RFC 1155): describe cmo se definen los objetos gestionados conteni
dos en la MIB
MIB para la gestin de red de redes basadas en TCP/IP: M1B-II (RFC 1213):
describe los objetos gestionados contenidos en la MIB
Protocolo ampie de gestin de red (RFC 1157): define el protocolo empleado
para gestionar estos objetos
SNMP se dise como protocolo del nivel de aplicacin para formar parte de la suite de
protocolos TCP/IP. Fue pensado para operar sobre UDP (UserDatagram Protocol), de
finido en la RFC 768. Para una estacin de gestin independiente, un proceso de admi
nistrador controla el acceso a la MIB central en la estacin de gestin y proporciona una
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 6 5
interfaz al administrador de red. El proceso de administrador consigue la gestin de la
red usando SNMP, que se implementa sobre UDP, IP y los protocolos dependientes de
la red de que se trate (por ejemplo, Ethernet, FDDI, X.25).
Cada agente tambin debe implementar SNMP, UDP e IP. Adems, hay un proceso
agente que interpreta los mensaje SNMP y controla la MIB del agente. Para un disposi
tivo agente que d soporte a otras aplicaciones, como FTP, se requiere TCP y UDP.
La Figura 8.1 ilustra el contexto del protocolo de SNMP. Desde una estacin de ges
tin se emiten tres tipos de mensaje SNMP en nombre de una aplicacin de gestin: Get-
Request, GetNextRequest y SetRequest. Los dos primeros son variaciones de la funcin
Get. Los tres mensajes son reconocidos por el agente mediante un mensaje GetRespon-
se, que se entrega a la aplicacin de gestin. Adems, un agente puede emitir un men
saje trap (de interceptacin) en respuesta a un hecho que afecta a la MIB y a los recur
sos gestionados implicados.
Debido a que SNMP se basa en UDP, que es un protocolo no orientado a conexin,
SNMP es, en s mismo, un protocolo no orientado a conexin. No se mantienen cone
xiones entre una estacin de gestin y sus agentes. En vez de ello, cada intercambio es
una transaccin separada entre una estacin de gestin y un agente.
Estacin d e g e s t i n S NMP A g e n t e SNMP
Figura 8 . 1 E l p a p e l d e S N M P
www.FreeLibros.org
266 Fundamentos de seguridad en redes. Aplicaciones y estndares
AGENTES PROXY
En SNMPvl todos los agentes y las estaciones de gestin deben disponer de UDP e IP.
Esto limita la gestin directa a ciertos dispositivos y excluye otros, como algunos puen
tes y mdems, que no admiten ninguna parte de la suite de protocolos TCP/IP. Adems,
puede haber numerosos sistemas pequeos (computadores personales, estaciones de tra
bajo, controladores programables) que implementen TCP/IP para dar cabida a sus apli
caciones, pero para los cuales no es deseable aadir la carga adicional que suponen
SNMP, la lgica de agente y el mantenimiento de la MIB.
Para acomodar los dispositivos que no implementan SNMP, se desarroll el concep
to de proxy. En este esquema, un agente SNMP acta como proxy para uno o ms dis
positivos; es decir, el agente SNMP acta en nombre de esos dispositivos.
La Figura 8.2 indica el tipo de arquitectura de protocolo ms habitual. La estacin de
gestin enva a su agente proxy peticiones relativas a un dispositivo. El agente proxy
convierte cada peticin al protocolo de gestin que usa el dispositivo. Cuando el agente
recibe una respuesta a una peticin, la pasa, a su vez, a la estacin de gestin. De igual
forma, si se transmite desde el dispositivo la notificacin de un evento al proxy, ste la
enva a la estacin de gestin en forma de mensaje trap.
SNMPv2 no slo permite el uso de la suite de protocolos TCP/IP, sino tambin de
otros. En particular, SNMPv2 est diseado para funcionar en la suite de protocolos
OSI. De esta forma, SNMPv2 se puede usar para gestionar una mayor variedad de con
figuraciones de red. Con respecto a los agentes proxy cualquier dispositivo que no im-
plemente SNMPv2 slo puede ser gestionado mediante un proxy Esto adems incluye
dispositivos SNMPvl. Es decir, si un dispositivo implementa el soware agente para
SNMPvl, se puede alcanzar desde un administrador SNMPv2 slo por un dispositivo
proxy que implemente el agente SNMPv2 y el software de administrador de SNMPvl.
Los casos descritos en el prrafo anterior se conocen en SNMPv2 como relaciones
proxy extranjeras. Adems, SNMPv2 permite una relacin proxy nativa en la que el dis
positivo representado admite SNMPv2. En este caso, un administrador SNMPv2 se co
munica con un nodo SNMPv2 que acta como agente. Este nodo luego acta como ad
ministrador para alcanzar el dispositivo representado, que acta como agente SNMPv2.
La razn de este tipo de comunicacin indirecta es la de permitir a los usuarios confi
gurar sistemas de gestin de red jerrquicos y descentralizados, como se explicar ms
tarde.
SNMPv2
La potencia de SNMP se halla en su sencillez. SNMP proporciona un conjunto bsico de
herramientas de gestin de red en un paquete fcil de implementar y de configurar. Sin
embargo, a medida que los usuarios se han ido basando cada vez ms en SNMP para ges
tionar redes en continua expansin con cargas de trabajo cada vez mayores, sus deficien
cias se han hecho demasiado evidentes. Estas deficiencias se dividen en tres categoras:
Falta de soporte para la gestin de red distribuida
Deficiencias funcionales
Deficiencias de seguridad
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 267
Agente proxy
Estacin de gestin
Proceso
de a d m i n i s t r a d o r
SNMP
UDP
IP
Protocolos
dependientes de la red
Figura 8.2 C o n f i g u r a c i n d e a g e n t e s proxy
Las dos primeras categoras de deficiencias se tratan en SNMPv2, que fue emitido
en 1993, con una versin revisada publicada en 1996 (actualmente los RFC 1901, de
1904 a 1908, 2578 y 2579). Muy pronto SNMPv2 obtuvo apoyo y una serie de vende
dores anunciaron sus productos en los meses posteriores a la publicacin del estndar.
Las deficiencias de seguridad han sido tratadas en SNMPv3.
En el resto de este subapartado, se resumen brevemente las nuevas caractersticas que
se proporcionan con SNMPv2. Las caractersticas de seguridad de SNMPvl y SNMPv3
se examinan detalladamente en las secciones 8.2 y 8.3 respectivamente.
Gestin de red distribuida
En un esquema tradicional de gestin de red centralizada, un computador de la configu
racin desempea la funcin de una estacin de gestin de red; puede haber una o dos
estaciones de gestin ms con la funcin de apoyo. Los dems dispositivos de la red con
tienen software agente y una MIB, para permitir la supervisin y el control desde la es
tacin de gestin. Como las redes aumentan su tamao y la carga de trfico, un sistema
centralizado es inviable. Hay demasiada carga en la estacin de gestin y demasiado tr
fico, con informes de cada uno de los agentes que tienen que guiarlos por toda la red ha
cia su destino. En tales circunstancias, funciona mejor un enfoque distribuido descen
tralizado (Figura 8.3). En un esquema descentralizado de gestin de red, puede haber
mltiples estaciones de gestin de alto nivel, que se podran denominar servidores de
gestia Cada uno de estos servidores podra gestionar directamente una parte del total
ae agentes. Sin embargo, para muchos de los agentes, el servidor de gestin delega res
ponsabilidad a un administrador intermedio. El administrador intermedio desempea la
funcin de administrador para supervisar y controlar los agentes bajo su responsabili-
Fu nci n d e cor relaci n
Proceso
de a d m i n i s t r a d o r
A r q u i t e c t u r a de
p r o t o c o l o uti l i za d a
p o r el d i s p o s i t i v o
re prese ntad o
SNMP
UDP
IP
Protocolos
dependientes de la red
Protocolos
dependientes de la red
Dispositvo
representado
Proceso
de a d m i n i s t r a d o r
A r q u i t e c t u r a de
p r o t o c o lo uti l i za d a
p o r e l d i s p o s i t i v o
represe ntad o
Protocolos
dependientes de la red
www.FreeLibros.org
268 Fundamentos de seguridad en redes. Aplicaciones y estndares
Figura 8.3 E j e m p l o d e c o n f i g u r a c i n d e g e s t i n d e r e d d i s t r i b u i d a
dad. Tambin funciona como agente para proporcionar informacin y aceptar el control
por parte de un servidor de gestin de nivel superior. Este tipo de arquitectura dispersa
la carga de procesamiento y reduce el trfico en la red.
SNMPv2 permite una estrategia de gestin de red muy centralizada as como una
distribuida. En el ultimo caso, algunos sistemas funcionan tanto con el papel de admi
nistrador como de agente. En su papel de agente, tal sistema aceptar rdenes de un sis
tema de gestin superior. Algunas de esas rdenes se relacionan con la MIB local en
el agente. Otras rdenes requieren que el agente acte como proxy para dispositivos
remotos. En este caso, el agente proxy asume el papel de administrador para acceder a
informacin en un agente remoto y luego asume el papel de un agente para pasar esa in
formacin a un administrador superior.
Mejoras funcionales
La Tabla 8.1 presenta las mejoras funcionales que se han realizado en SNMPv2. Los dos
protocolos se definen en trminos de un conjunto de comandos que se transmiten como
unidades de datos del protocolo (PDU, Protocol Data Unts). En el caso de SNMP vi,
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 269
hay cinco comandos. Un administrador emite el comando Get a un agente para obtener
valores de objetos en la MIB. El comando GetNext se beneficia del hecho de que los ob
jetos de una MIB se organizan en forma de rbol. Cuando se nombra un objeto en un co
mando GetNext, el agente encuentra el siguiente objeto en el rbol y devuelve su valor.
GetNext es til porque permite que un administrador recorra un rbol en un agente
cuando no conoce el conjunto exacto de objetos admitidos por ese agente. El comando
Set permite que un administrador actualice los valores en un agente; tambin se usa para
crear y borrar filas en tablas. Un agente usa el comando GetResponse para responder a
un comando del administrador. Por ltimo, el comando Trap permite que un agente en
ve informacin a un administrador sin esperar solicitud de gestin. Por ejemplo, un
agente podra estar configurado para enviar un Trap cuando Me una conexin o cuan
do el trfico exceda los lmites.
SNMPv2 incluye todos los comandos que se encuentran en SNMPvl ms dos nue
vos. El ms importante de ellos es el comando Inform. Este comando se enva de una es
tacin de gestin a otra y, al igual que el Trap, incluye informacin relativa a las condi
ciones y los eventos en el emisor. La ventaja de dicho comando es que se puede usar
para construir una configuracin en la que mltiples administradores cooperan para
compartir las responsabilidades de la gestin de una red grande.
T a b l a 8 . 1 C o m p a r a c i n d e las P D U d e S N M P v l y S N M P v 2
SNMPvl PDU SNMPv2 PDU Direccin Descripcin
G e t R e q u e s t G e t R e q u e s t De a d m i n i s t r a d o r a a g e n t e S o l ic it a v a l o r p a r a cada
o b j e t o e n u m e r a d o
G e t N e x t R e q u e s t G e t N e x t R e q u e s t De a d m i n i s t r a d o r a a g e n t e Solicita s i g u i e n t e v a l o r
pa ra c a d a o b j e t o e n u m e
r a do
G e t B u l k R e q u e s t De a d m i n i s t r a d o r a a g e n t e Solicita v a l o r e s m l t i p l e s
S e t R e q u e s t S e t R e q u e s t De a d m i n i s t r a d o r a a g e n t e E s t a b le c e v a l o r p a r a c a
da o b j e t o e n u m e r a d o
I n f o r m R e q u e s t De a d m i n i s t r a d o r a a d m i
n i s t r a d o r
T r a n s m i t e i n f o r m a c i n
no s o l i c i t a d a
G e t R e s p o n s e R e s p o n s e De a g e n t e a a d m i n i s t r a d o r
o de a d m i n i s t r a d o r a a d m i
ni str ado r ( S N M P v 2 )
R e s p o n d e a l a s o l i c i t u d
del a d m i n i s t r a d o r
T r a p S N M P v 2 - T r a p De a g e n t e a a d m i n i s t r a d o r T r a n s m i t e i n f o r m a c i n
no s o l i c i t a d a
El otro nuevo comando, GetBulk, permite que un administrador obtenga de una vez
un gran bloque de datos. Concretamente, este comando est diseado para la transmi
sin de tablas enteras con un comando.
www.FreeLibros.org
270 Fundamentos de seguridad en redes. Aplicaciones y estndares
Una ltima diferencia se halla en el hecho de que el comando Get es atmico en el
caso de SNMPvl pero no en el caso de SNMPv2. Si un comando Get de SNMPvl con
tiene una lista de objetos para los cuales se solicitan valores, y al menos uno de los ob
jetos no existe en el agente, entonces se rechaza el comando entero. Para SNMPv2, se
pueden devolver resultados parciales. El comando Get no atmico permite un uso ms
eficaz de la capacidad de la red por parte del administrador.
8 . 2 C OM UN ID A D ES S N M P v l
SNMPvl, tal y como se define en el RFC 1157, proporciona slo una herramienta rudi
mentaria de seguridad basada en el concepto de comunidad. Esta herramienta aporta un
cierto nivel de seguridad pero est abierta a distintos ataques [CERT02, JIAN02].
COMUNIDADES Y NOMBRES DE COMUNIDADES
Al igual que otras aplicaciones distribuidas, la gestin de red implica la interaccin de
una serie de entidades de aplicacin admitidas por un protocolo de aplicacin. En el caso
de la gestin de red SNMP, las entidades de aplicacin son las aplicaciones de adminis
trador y las aplicaciones agente que usan SNMP.
La gestin de red SNMP tiene varias caractersticas que no son comunes a todas las
aplicaciones distribuidas. La aplicacin implica una relacin de uno a muchos entre un
administrador y un grupo de agentes: el administrador puede obtener y establecer obje
tos en los agentes y puede recibir traps de los agentes. As, desde un punto de vista ope
rativo o de control, el administrador gestiona un nmero de agentes. Puede haber una se
rie de administradores, cada uno de los cuales gestiona todos los agentes, o un subgrupo,
de la configuracin. Estos subgrupos se pueden solapar.
Tambin necesitamos poder ver la gestin de red SNMP como una relacin de uno a
muchos entre un agente y un conjunto de administradores. Cada agente controla su pro
pia MIB local y debe ser capaz de controlar el uso de esa MIB por parte de una serie de
administradores. Existen tres aspectos de este control:
Servido d e autentificacin: el agente puede querer limitar el acceso a la MIB a
los administradores autorizados.
Poltica d e acceso: el agente puede querer conceder diferentes privilegios de ac
ceso a diferentes administradores.
Servicio / wmy. un agente puede actuar como proxy para otros agentes. Esto pue
de implicar la implementacin del servicio de autentificacin y/o poltica de acce
so para los otros agentes en el sistema proxy.
Todos estos aspectos se relacionan con la seguridad. En un entorno en el que la respon
sabilidad de los componentes de la red est dividida, por ejemplo, entre un nmero de
entidades administrativas, los agentes necesitan protegerse a s mismos y a sus MIB
frente al acceso no deseado o no autorizado. SNMP, como se define en el RFC 1157,
proporciona slo una capacidad primitiva y limitada para la seguridad, concretamente el
concepto de comunidad.
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 271
Una cmunidad SNMP consiste en una relacin entre un agente SNMP y un con
junto de administradores SNMP que define la autentificacin, el control de acceso y las
caractersticas del proxy. El concepto de comunidad es local, definido en el agente. El
agente establece una comunidad para cada combinacin deseada de autentificacin, con
trol de acceso y caractersticas del proxy. A cada comunidad se le asigna un nombre de
comunidad nico (en ese agente), y a los administradores en esa comunidad se les pro
porciona y deben emplear el nombre de comunidad en todas las operaciones Get y Set.
El agente puede establecer un nmero de comunidades, donde los administradores
miembros se pueden solapar.
Como las comunidades se definen localmente en el agente, diferentes agentes pue
den utilizar el mismo nombre. Esta identidad de nombres es irrelevante y no indica nin
guna similitud entre las comunidades definidas. As, un administrador debe mantenerse
al tanto del nombre o nombres de comunidad que estn asociados con cada uno de los
agentes a los que desea acceder.
SERVICIO DE AUTENTIFICACIN
La finalidad del servicio de autentificacin SNMPv 1 es garantizar al receptor que un men
saje SNMPv 1 proviene de la fuente de la que dice proceder. SNMPv 1 slo proporciona un
esquema trivial para la autentificacin. Cada mensaje (get o put requesi) de un adminis
trador a un agente incluye un nombre de comunidad. Este nombre funciona como una con
trasea, y se asume que el mensaje es autntico si el emisor conoce la contrasea.
Con esta forma limitada de autentificacin, muchos administradores de red son rea
cios a permitir otra cosa que no sea la supervisin de la red; es decir, operaciones get y
trap. El control de la red mediante una operacin set es claramente un rea ms sen
sible. El nombre de comunidad se podra usar para activar un procedimiento de auten
tificacin, con el nombre funcionando simplemente como un dispositivo inicial de
ocultacin de contrasea. El procedimiento de autentificacin podra implicar el uso de
cifrado/descifrado para funciones de autentificacin ms seguras. Sin embargo, esto es
capa del mbito del RFC 1157.
POLTICA DE ACCESO
Al definir una comunidad, un agente limita el acceso a su MIB a un conjunto seleccio
nado de administradores. Con el uso de ms de una comunidad, el agente puede pro
porcionar diferentes categoras de acceso a la MIB a diferentes administradores. Hay
dos aspectos relativos a este control de acceso:
Vista MIB deSNMP: subconjunto de los objetos de una MIB. Se pueden definir
diferentes vistas MIB para cada comunidad. El conjunto de objetos en una vista no
necesita pertenecer a un solo subrbol de la MIB.
Modo d e acceso SNMP: elemento del conjunto {READ-ONLY, READ-WRI-
75}(slo lectura, lectura-escritura). Se define un modo de acceso para cada comu
nidad.
La combinacin de una vista MIB y un modo de acceso se conoce como perfil de co-
im id a d SNMP. As, un perfil de comunidad se compone de un subconjunto definido
www.FreeLibros.org
272 Fundamentos de seguridad en redes. Aplicaciones y estndares
de la MIB en el agente, ms un modo de acceso para esos objetos. El modo de acceso
SNMP se aplica de manera uniforme a todos los objetos en la vista MIB. Por lo tanto, si
se selecciona el modo de acceso READ-ONLY, se aplica a todos los objetos en la vista y
limita el acceso de los administradores de esta vista a operaciones de slo lectura.
Un perfil de comunidad se asocia con cada comunidad definida por un agente; la
combinacin de una comunidad SNMP y un perfil de comunidad SNMP se conoce
como una poltica d e acceso SNMP. La Figura 8.4 ilustra los distintos conceptos que
se acaban de introducir.
Agente Conjunto de Vista MIB Modo de
SNMP administradores SN MP SNMP acceso SNMP
Comunidad SN MP Perfil de comunidad
(nombre de comunidad) SNMP
Poltica de acceso SNMP
Figura 8.4 Conceptos administrativos de SNMPvl
SERVICIO PROXY
El concepto de comunidad tambin es til para implementar el servicio proxy. Recorde
mos que un proxy es un agente SNMP que acta en nombre de otros dispositivos. Nor
malmente, los otros dispositivos son extranjeros, en el sentido de que no admiten TCP/IP
ni, por lo tanto, SNMP En algunos casos, el sistema que utiliza proxy puede admitir
SNMP, pero el proxy se utiliza para reducir la interaccin entre los dispositivos repre
sentados por l y los sistemas de gestin de red.
Para cada dispositivo que el sistema proxy representa, mantiene una poltica de ac
ceso SNMP. As, el proxy sabe qu objetos MIB se pueden usar para gestionar el siste
ma representado por el proxy (la vista MIB) y su modo de acceso.
8 . 3 S N M P v 3
En 1998, el grupo de trabajo SNMPv3 de la IETF produjo una serie de estndares pro
puestos de Internet, actualmente los RFC desde 2570 hasta 2576. Este conjunto de do
cumentos define un marco de trabajo para la incorporacin de caractersticas de seguri
dad en una capacidad general que incluye funcionalidad SNMPvl o SNMPv2. Adems,
los documentos definen un grupo especfico de capacidades para la seguridad en la red
y el control de acceso.
Es importante observar que SNMPv3 no es una sustitucin independiente de
SNMPvl y/o SNMPv2. SNMPv3 define una capacidad de seguridad para ser usada con-
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 273
juntamente con SNMPv2 (preferentemente) o SNMPvl. Adems, el RFC 2571 descri
be una arquitectura en la cual encajan todas las versiones actuales y futuras de SNMP
El RFC 2575 describe una herramienta de control de acceso, diseada para operar inde
pendientemente de la capacidad central de SNMPv3. En esta seccin, se ofrece una vi
sin general y un estudio de las capacidades definidas en los RFC del 2570 al 2576.
La Figura 8.5 indica la relacin entre las diferentes versiones de SNMP por medio
de los formatos involucrados. La informacin se intercambia entre una estacin de ges
tin y un agente en forma de mensaje SNMP. El procesamiento relativo a la seguridad
ocurre en el nivel de mensaje; por ejemplo, SNMPv3 especifica un Modelo de Seguri
dad de Usuario (USM, User Security Mode!) que utiliza campos en la cabecera del men
saje. La carga til de un mensaje SNMP es una unidad de datos del protocolo (PDU,
ProtocolData Unt) SNMPvl o SNMPv2. Una PDU indica un tipo de accin de gestin
[por ejemplo, obtener (get) o establecer (set) un objeto gestionado] y una lista de nom
bres de variables relacionados con esa accin.
Los RFC 2570 hasta 2576 describen una arquitectura general y estructuras de men
sajes y caractersticas de seguridad especficas, pero no definen un nuevo formato de
PDU de SNMP. Por lo tanto, en la nueva arquitectura se debe usar el formato existente
de PDU de SNMPvl o de SNMPv2. Una implementacin conocida como SNMPv3 con
siste en las caractersticas de seguridad y de arquitectura definidas en los RFC 2570 has
ta 2576 ms el formato de PDU y la funcionalidad definida en los documentos SNMPv2.
En RFC 2570 se expresa como sigue: SNMPv3 se puede ver como SNMPv2 con ca
pacidades adicionales de seguridad y gestin.
Lo que resta de esta seccin se organiza de la siguiente manera. En primer lugar, se
ofrece una breve introduccin a la arquitectura bsica de SNMP definida en RFC 2571.
Luego, se describen las herramientas de confidencialidad y autentificacin proporciona
das por el USM de SNMPv3. Por ltimo, se trata el control de acceso y el modelo de
control de acceso basado en vistas (VACM, View-basedAccess ControlModel).
Procesamiento PDU
(S N M P v l o SNMPv2)
Procesamiento de mensaje
(USM SNMPv3)
UDP
IP
IP-H = cabecera IP
UDP-H = cabecera UDP
V3-MH = cabecera de mensaje SNMPv3
PDU = unidad de datos del protocolo
PDU SNMP
V3-MH PDU SNMP
1
UDP-H V3-MH PDU SNMP
IP-H UDP-H V3-MH P D US N M P
Figura 8.5 Arquitectura del protocolo SNMP
www.FreeLibros.org
274 Fundamentos de seguridad en redes. Aplicaciones y estndares
ARQUITECTURA SNMP
La arquitectura SNMP, como la presenta el RFC 2571, consiste en un conjunto distri
buido de entidades SNMP que actan entre s. Cada entidad implementa una parte de la
capacidad SNMP y puede actuar como un nodo agente, un nodo administrador o una
combinacin de ellos. Cada entidad SNMP se compone de un conjunto de mdulos que
interactan entre s para suministrar servicios. Estas interacciones se pueden modelar
como un conjunto de primitivas y parmetros abstractos.
La arquitectura del RFC 2571 refleja un requisito de diseo fundamental para
SNMPv3: disear una arquitectura modular que (1) permita la implementacin en una
gran variedad de entornos, de los cuales, algunos necesiten funcionalidad mnima y de
bajo coste, y otros puedan admitir caractersticas adicionales para la gestin de redes
grandes; (2) hacer posible que partes de la arquitectura avancen en el proceso de estan
darizacin incluso aunque no se haya alcanzado consenso en todas las partes; y (3) dar
cabida a modelos alternativos de seguridad.
Entidad SNMP
Cada entidad SNMP incluye un nico motor SNMP. Un motor SNMP implementa
funciones para enviar y recibir mensajes, autentificar y cifrar/descifrar mensajes y con
trolar el acceso a los objetos administrados. Estas funciones se proporcionan como ser
vicios a una o ms aplicaciones que se configuran con el motor SNMP para formar una
entidad SNMP.
Tanto el motor SNMP como las aplicaciones que soporta se definen como una co
leccin de mdulos discretos. Esta arquitectura ofrece varias ventajas. Primero, el papel
de una entidad SNMP se determina en funcin de qu mdulos se implementan en esa
entidad. Se necesita un determinado conjunto de mdulos para un agente SNMP, mien
tras que para un gestor SNMP se necesita un conjunto diferente de mdulos (aunque se
solapen). Segundo, la estructura modular de la especificacin se presta a definir dife
rentes versiones de cada mdulo. Esto, a su vez, hace posible (1) definir capacidades al
ternativas o mejoradas para ciertos aspectos de SNMP sin necesidad de remitirse a una
nueva versin del estndar completo (por ejemplo, SNMPv4), y (2) especificar con cla
ridad las estrategias de coexistencia y transicin (RFC 2576).
Para comprender mejor el papel de cada mdulo y su relacin con otros mdulos, es
conveniente observar su uso en gestores y agentes SNMP tradicionales. El trmino tra
dicional\ equivalente a puro, se usa para resaltar el hecho de que una implementacin
dada no necesita ser un gestor o agente puro, sino que puede tener mdulos que permi
tan a la entidad realizar tareas de gestin y de agente.
La Figura 8.6, basada en una figura del RFC 2571, es un diagrama de bloque de un
gestar SNMP tradnonal Un gestor SNMP tradicional interacta con agentes SNMP
emitiendo comandos (Get, Set) y recibiendo mensajes trap o de interceptacin; el gestor
tambin puede interactuar con otros gestores emitiendo PDU de solicitud de informacin
(Inform Requesi), que proporciona alertas, y recibiendo PDU de respuesta de informacin
(Inform Response), que reconocen solicitudes de informacin. En la terminologa de
SNMPv3, un gestor SNMP tradicional incluye tres categoras de aplicaciones. Las Apli
caciones de Generacin de Comandos (Command Generator Applications) supervisan y
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 275
Entidad SNMP
Aplicacin de Aplicacin de Aplicacin de
generacin iniciacin de recepcin de
Aplicaciones
de comando notificacin notificacin
SNMP
/
Subsistema
d e procesamiento
de mensaje
Subsistema
d e seguridad
Modelo
de seguridad
basado
en el usuario
UDP IPX

Otro
t
Red
Figura 8.6 Gestor SNMP tradicional
manipulan los datos de gestin en agentes remotos; usan PDU de SNMPvl y/o SNMPv2,
que incluyen Get, GetNext, GetBulk y Set. Una Aplicacin de Iniciacin de Notificacin
(Notication Originator Application) inicia mensajes asincronos; en el caso de un gestor
tradicional, se usa la PDU de solicitud de informacin (InformRequest) para esta aplica
cin. Una Aplicacin de Recepcin de Notificacin (Notication Receiver Application}
procesa los mensajes asincronos entrantes; stos incluyen PDU InformRequest, SNMPv2-
Trap y SNMPvl Trap. En el caso de una PDU entrante de solicitud de informacin, la
Aplicacin de Recepcin de Notificacin responder con una PDU de respuesta.
Todas la aplicaciones descritas hacen uso de los servicios proporcionados por el mo
tor SNMP para esta entidad. El motor SNMP realiza dos funciones generales:
Acepta PDU salientes de aplicaciones SNMP; realiza el procesamiento necesario,
incluyendo la insercin de cdigos de autentificacin y el cifrado; y luego encap-
sula las PDU en mensajes para su transmisin.
Acepta mensajes SNMP entrantes de la capa de transporte; realiza el procesa
miento necesario, incluyendo la autentificacin y el cifrado; y luego extrae las
PDU de los mensajes y los pasa a la aplicacin SNMP correspondiente.
www.FreeLibros.org
276 Fundamentos de seguridad en redes. Aplicaciones y estndares
En un gestor tradicional, el motor SNMP contiene un dispatcher, un subsistema de pro
cesamiento de mensajes y un subsistema de seguridad. El dispatcher es un gestor sim
ple de trfico. Para las PDU salientes, el dispatcher acepta las PDU de las aplicaciones
y realiza las siguientes fiinciones: para cada PDU, determina el tipo de procesamiento
de mensaje requerido (por ejemplo, para SNMPvl, SNMPv2 oSNMPv3) y pasa la PDU
al mdulo correspondiente de procesamiento de mensajes del subsistema de procesa
miento. Posteriormente, el subsistema de procesamiento de mensajes devuelve un men
saje que contiene esa PDU y que incluye las cabeceras de mensaje adecuadas. Luego, el
dispatcher correlaciona este mensaje con una capa de transporte para la transmisin.
Para los mensajes entrantes, el dispatcher acepta mensajes de la capa de transporte y
lleva a cabo las siguientes funciones: encamina cada mensaje al mdulo adecuado de
procesamiento de mensajes. A continuacin, el subsistema de procesamiento de mensa
jes devuelve la PDU contenida en el mensaje. Luego el dispatcher pasa esta PDU a la
aplicacin correspondiente.
El subsistema de procesamiento de mensajes acepta las PDU salientes del dispatcher
y las prepara para la transmisin encapsulndolas en la cabecera de mensaje adecuada y
devolvindolas al dispatcher El subsistema de procesamiento de mensajes tambin
acepta mensajes entrantes del dispatcher, procesa cada cabecera de mensaje y devuelve
al dispatcherh PDU adjunta. Una implementacin del subsistema de procesamiento de
mensajes puede admitir un solo formato de mensaje correspondiente a una sola versin
de SNMP (SNMPvl, SNMPv2c, SNMPv3), o puede contener una serie de mdulos,
cada uno de los cuales admite una versin diferente de SNMP.
El subsistema de seguridad desempea funciones de autentificacin y cifrado. Cada
mensaje saliente se pasa al subsistema de seguridad desde el subsistema de procesa
miento de mensajes. Dependiendo de los servicios requeridos, el subsistema de seguri
dad puede cifrar la PDU adjunta y posiblemente algunos campos de la cabecera del men
saje, y puede generar un cdigo de autentificacin e insertarlo en la cabecera del
mensaje. El mensaje procesado luego se devuelve al subsistema de procesamiento de
mensajes. De la misma forma, cada mensaje entrante se pasa al subsistema de seguridad
desde el subsistema de procesamiento de mensajes. Si es necesario, el subsistema de se
guridad comprueba el cdigo de autentificacin y lleva a cabo el descifrado. A conti
nuacin devuelve el mensaje procesado al subsistema de procesamiento de mensajes.
Una implementacin del subsistema de seguridad puede permitir uno o ms modelos de
seguridad diferenciados. Hasta ahora, el nico modelo ce seguridad definido es el mo
delo de seguridad basado en el usuario (USM, User-Based Security Model) para
SNMPv3, especificado en el RFC 2574.
La Figura 8.7, basada en una figura del RFC 2571, es un diagrama de bloques de un
agmteSNMP tradicknaL El agente tradicional puede contener tres tipos de aplicacio
nes. Las Aplicaciones de Respuesta a Comandos (Command Responder Application^)
proporcionan acceso a datos de gestia Estas aplicaciones responden a las solicitudes
entrantes obteniendo y/o estableciendo objetos gestionados y emitiendo despus una
PDU de respuesta. Una aplicacin de iniciacin de notificacin inicia mensajes asincro
nos; en el caso de un agente tradicional se usa la PDU Trap de SNMPvl o SNMPv2-
Trap para esta aplicacin. Una aplicacin de reenvo mediante proxy (Proxy Forwarder
Applications) reenva mensajes entre entidades.
El motor SNMP para un agente tradicional tiene todos los componentes encontrados
en el motor SNMP para un gestor tradicional, ms un subsistema de control de acceso.
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 7 7
UDP IPX . . Otro
Entida d SNMP
Aplicaciones
Aplicaciones Aplicaciones
de reenvo
de respuesta de iniciacin
mediante proxy
a comandos de notificacin
A p l i c a c i o n e s SNMP
Instrumentacin MIB
/
Figura 8 . 7 A g e n t e S N M P t r a d i c i o n a l
Este subsistema proporciona servicios de autorizacin para controlar el acceso a las MIB
para los objetos de gestin de lectura {reading) y de seleccin Csetting). Estos servicios
se realizan en funcin de los contenidos de las PDU. Una implementacin del subsiste
ma de seguridad puede admitir uno o ms modelos de control de acceso diferenciados.
Hasta el momento, el nico modelo de seguridad definido es el modelo de control de ac
ceso basado en vistas (VACM), especificado en el RFC 2575.
Obsrvese que las funciones relacionadas con la seguridad se organizan en dos sub
sistemas separados: seguridad y control de acceso. Este es un ejemplo excelente de un
buen diseo modular, porque los dos subsistemas realizan funciones muy distintas y, por
lo tanto, tiene sentido permitir la estandarizacin de estas dos reas para proceder de ma
nera independiente. El subsistema de seguridad tiene que ver con la privacidad y la au
tentificacin y opera en mensajes SNMP. El subsistema de control de acceso se ocupa
del acceso autorizado a informacin de gestin y opera en las PDU SNMP.
Terminologa
La Tabla 8.2 define brevemente algunos de los trminos introducidos en el RFC 2571.
Asociado con cada entidad SNMP hay un snmpEngineID nico. Para los propsitos del
www.FreeLibros.org
2 7 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
control de acceso, se considera que cada entidad SNMP gestiona una serie de contextos
de informacin gestionada, cada uno de los cuales tiene un nombre de contexto (context-
Name) que es nico en esa entidad. Para resaltar que hay un solo gestor de contextos en
una entidad, cada una de ellas tiene asociado un contextEngineID unvoco; debido a que
hay una correspondencia de uno a uno entre el motor de contextos y el de SNMP en esta
entidad, el contextEngineID tiene un valor idntico al snmpEnginelD. El control de ac
ceso est regido por el contexto especfico para el cual se intenta el acceso y la identidad
del usuario que solicita acceso; esta ltima identidad se expresa como entidad principal,
que puede ser un individuo, una aplicacin o un grupo de individuos o de aplicaciones.
T a b l a 8.2 T e r m i n o l o g a d e S N M P v 3
snmpEnginelD
I d e n t i f i c a d o r n i c o y c a r e n t e d e a m b i g e d a d d e u n m o t o r S N M P , as c o m o l a e n t i
d a d S N M P q u e c o r r e s p o n d e a e s e m o t o r . S e d e f i n e p o r c o n v e n c i n t e x t u a l , co n un a
s i n t a x i s d e r i s t r a d e oc te t o s .
contextEngineID
I d e n t i f i c a u n v o c a m e n t e u n a e n t i d a d S N M P q u e p u e d e r e a l i z a r u n a i n s t a n c i a d e un
c o n t e x t o co n u n c o n t e x t N a m e p a r t i c u l a r .
contextName
I d e n t i f i c a u n c o n t e x t o p a r t i c u l a r e n u n m o t o r S N M P S e p a s a c o m o u n p a r m e t r o
d e d i s p a t c h e r y al s u b s i s t e m a d e c o ntr ol d e acceso.
scopedPDU
U n b l o q u e d e da t o s f o r m a d o p o r u n c o n t e x t E n g i n e I D , u n c o n t e x t N a m e y u n a P DU
S NMP. S e p a s a c o m o u n p a r m e t r o a l / d e s d e el s i s t e m a d e s e g u r i d a d .
s n m p M e s s a g e P r o c e s s i n g M o d e l
I d e n t i f i c a d o r u n v o c o d e u n m o d e l o d e p r o c e s a m i e n t o d e m e n s a j e s de l s u b s i s t e m a
d e p r o c e s a m i e n t o d e m e n s a j e s . A l g u n o s v a l o r e s p o s i b l e s i n c l u y e n S N M P v l ,
S N M P v 2 c y S N M P v 3 . S e d e f i n e p o r c o n v e n c i n t e x t u a l , co n u n a s i n t a x i s d e e n t e r o .
snmpSecurityModel
I d e n t i f i c a d o r u n v o c o d e u n m o d e l o d e s e g u r i d a d d e l s u b s i s t e m a d e s e g u r i d a d . A l
g u no s v a l o r e s i n c l u y e n S N M P v l , S N M P v 2 c y U S M . S e d e f i n e p o r c o n v e n c i n t e x
t u a l , co n u n a s i n t a x i s d e e n t e r o .
snmpSecurityLevel
U n n i v e l d e s e g u r i d a d e n el q u e se p u e d e n e n v i a r m e n s a j e s S N M P o co n el cual se
e s t n p r o c e s a n d o o p e r a c i o n e s , e x p r e s a d o e n f u n c i n d e si se p r o p o r c i o n a a u t e n t i -
f i c a c i n y / o p r i v a c i d a d o no . Los v a l o r e s a l t e r n a t i v o s so n n o A u t h n o P r i v , a u t h N o P r i v
y a u t h P r i v . S e d e f i n e p o r c o n v e n c i n t e x t u a l , co n u n a s i n t a x i s d e e n t e r o .
principal
La e n t i d a d e n c u y o n o m b r e s e p r o p o r c i o n a n s e r v i c i o s o t i e n e l u g a r el p r o c e s a
m i e n t o . P u e d e s e r u n i n d i v i d u o a c t u a n d o con u n p a p e l p a r t i c u l a r ; u n c o n j u n t o de
i n d i v i d u o s , q u e a c t a n co n u n a f u n c i n p a r t i c u l a r , u n a a p l i c a c i n o c o n j u n t o de
a p l i c a c i o n e s , y l a c o m b i n a c i n d e e l l o s .
securityName
U n a r i str a l e g i b l e p o r h u m a n o s r e p r e s e n t a n d o al p r i n c i p a l . S e p a s a c o m o u n p a r
m e t r o e n t o d a s las p r i m i t i v a s S N M P ( d i s p a t c h e r , p r o c e s a m i e n t o d e m e n s a j e s , s e
g u r i d a d , c o n t r o l d e a c ceso ).
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 279
Otros trminos importantes estn relacionados con el procesamiento de mensajes. El
snmpMessageProcessingModel determina el formato de mensaje y la versin SNMP
para el procesamiento de mensajes. El snmpSecurityModel determina qu modelo de se
guridad se va a usar. El snmpSecurityLevel determina qu servicios de seguridad se so
licitan para esta operacin especfica. El usuario puede solicitar slo autentificacin, o
autentificacin ms privacidad (cifrado) o ninguno de ellos.
Aplicaciones SNMPv3
Los servicios entre mdulos en una entidad SNMP se definen en los RFC en trminos
de primitivas y parmetros. Una primitiva especifica la funcin aue se ha de realizar, y
los parmetros se usan para pasar datos e informacin de control. Podemos considerar
estas primitivas y parmetros como una manera formalizada de definir servicios SNMP.
La forma real de una primitiva es dependiente de la implementacin; un ejemplo de ello
es una llamada a procedimiento. En lo que se expone a continuacin, puede ser til re
mitirse a la Figura 8.8, basada en una figura del RFC 2571, para ver cmo encajan to
das estas primitivas. La Figura 8.8a muestra la secuencia de hechos en que una aplica
cin de generacin de comandos o de iniciacin de notificacin solicita que se enve una
PDU y, posteriormente, cmo se devuelve a esa aplicacin la respuesta correspondien
te; estas acciones se producen en un gestor. La Figura 8.8b muestra los hechos corres
pondientes en un agente. La figura muestra cmo un mensaje entrante da como resulta
do el envo de la PDU adjunta a una aplicacin, y cmo la respuesta de esa aplicacin
da como resultado un mensaje saliente. Obsrvese que algunas de las flechas del dia
grama estn etiquetadas con un nombre de primitiva, que representa una llamada. Las
flechas sin etiqueta representan la respuesta de una llamada, y las partes sombreadas in
dican la correspondencia entre la llamada y la respuesta.
El RFC 2573 define, en trminos generales, los procedimientos seguidos por cada
tipo de aplicacin al generar las PDU para la transmisin o al procesar las PDU entran
tes. En todos los casos, los procedimientos se definen en trminos de la interaccin con
el dispatcher por medio de primitivas del dispatcher
Una aplicacin d e generacin d e comandos emplea las primitivas del dispatcher
sendPdu y processResponsePdu. La sendPdu proporciona al dispatcher informacin
sobre el destino elegido, parmetros de seguridad y la PDU que se ha de enviar. El dis
patcher invoca, luego, al modelo de procesamiento de mensajes, que a su vez llama al
modelo de seguridad, para preparar el mensaje. El dispatcher pasa el mensaje prepara
do a la capa de transporte (por ejemplo, UDP) para la transmisin. Si la preparacin del
mensaje falla, el valor devuelto de sendPdu, fijado por el dispatcher, es una indicacin
de error. S la preparacin del mensaje es satisfactoria, el dispatcher asigna un identifi
cador sendPduHandle a esta PDU y devuelve ese valor al generador de comandos. El ge
nerador de comandos almacena el sendPduHandle para poder relacionar la PDU de res
puesta posterior con la solicitud original.
El dispatcher entrega cada PDU de respuesta entrante a la aplicacin correcta de ge
neracin de comandos, usando la primitiva processResponsePdu.
Una aplicacin derespuesta a comandos utiliza cuatro primitivas de dispatcher (re-
gisterContextEnginelD, unregisterContextEngineID, processPdu, retumResponsePdu) y
una primitiva del subsistema de control de acceso (isAccessAllowed).
www.FreeLibros.org
M
o
d
e
l
o
G
e
n
e
r
a
d
o
r

d
e

M
o
d
e
l
o

R
e
s
p
o
n
d
e
d
o
r

M
o
d
e
l
o

M
o
d
e
l
o

d
e

p
r
o
c
e
s
a
m
i
e
n
t
o

d
e

d
e

d
e

p
r
o
c
e
s
a
m
i
e
n
t
o

d
e

c
o
m
a
n
d
o
s

D
i
s
p
a
t
c
h
e
r

d
e

m
e
n
s
a
j
e
s

s
e
g
u
r
i
d
a
d

c
o
m
a
n
d
o
s

D
i
s
p
a
t
c
h
e
r

d
e

m
e
n
s
a
j
e
s

s
e
g
u
r
i
d
a
d
2 8 0 Fundamentos de seguridad en redes. Aplicaciones y estndares
<1) O
TJ-D
OO.
n i
(
a
)

G
e
n
e
r
a
d
o
r

d
e

c
o
m
a
n
d
o
s

o
i
n
i
c
i
a
d
o
r

d
e

n
o
t
i
f
i
c
a
c
i

n

(
b
)

R
e
s
p
o
n
d
e
d
o
r

d
e

c
o
m
a
n
d
o
s
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 8 1
La primitiva registerContextEngineID permite que una aplicacin de respuesta a co
mando se asocie con un motor SNMP con el fin de procesar ciertos tipos de PDU para
un motor de contexto. Una vez que el respondedor de comandos se ha registrado, todos
los mensajes recibidos de manera asincrona que contienen la combinacin registrada de
contextEngineID y pduType admitida son enviados al respondedor de comandos que se
registr para admitir esa combinacin. Un respondedor de comandos puede desasociar
se de un motor SNMP usando la primitiva unregisterContextEngineDD.
El dispatcher entrega cada PDU de solicitud entrante a la aplicacin correcta de res
puesta a comando, usando la primitiva processPdu. Luego, el respondedor de comandos
realiza los siguientes pasos:
Examina los contenidos de la PDU de solicitud. El tipo de operacin debe corres
ponderse con uno de los tipos registrados previamente por esta aplicacin.
Determina si se permite el acceso para realizar la operacin de gestin solicitada
en esta PDU. Con este fin, se llama a la primitiva isAccessAllowed.
El parmetro securtyModel indica qu modelo de seguridad va a usar el subsiste
ma de control de acceso en respuesta a esta llamada. El subsistema de control de
acceso determina si la entidad principal (securityName) que hace la peticin en
este nivel de seguridad (securityLevel) tiene permiso para solicitar la operacin de
gestin (viewType) en el objeto de gestin (variableName) en este contexto (con-
textName).
Si se permite el acceso, el respondedor de comandos realiza la operacin de ges
tin y prepara una PDU de respuesta. Si el acceso falla, prepara la PDU de res
puesta adecuada para indicar dicho error.
El respondedor de comandos llama al dispatcher con una primitiva returnRespon-
sePdu para enviar la PDU de respuesta.
Una aplicacin d e gmcracin de notificacin sigue los mismos procedimientos gene
rales usados para una aplicacin de generacin de comandos. Si se va a enviar una PDU
de solicitud de informacin, se usan las primitivas sendPdu y processResponsePdu, de
la misma forma que para las aplicaciones de generacin de comandos. Si se va a enviar
una PDU de interceptacin (Trap), slo se usa la primitiva sendPdu.
Una aplicacin de recepcin d e notificacin sigue un subgrupo de los procedi
mientos generales que se usan para la aplicacin de respuesta a comandos. El receptor
de notificacin debe primero registrarse para recibir las PDU de informacin y/o de in
terceptacin. Los dos tipos de PDU se reciben por medio de una primitiva processPdu.
Para una PDU de informacin, se usa una primitiva retumResponsePdu para responder.
Una aplicacin de remvio mediante / r a r y u s a primitivas de dispteher para reen
viar mensajes SNMP. Dicha aplicacin trata cuatro tipos bsicos de mensajes:
Mensajes que contienen tipos de PDU de una aplicacin de generacin de coman
dos. La aplicacin de reenvo mediante proxy determina el motor SNMP objetivo
o un motor SNMP que est ms prximo al objetivo, o por debajo de l, y enva la
PDU de respuesta adecuada.
Mensajes que contienen tipos de PDU de una aplicacin de generacin de notifica
cin. La aplicacin de reenvo mediante proxy determina qu motores SNMP debe
ran recibir la notificacin y enva la PDU o las PDU de notificacin adecuadas.
www.FreeLibros.org
2 8 2 Fundamentos de seguridad en redes. Aplicaciones y estndares
Mensajes que contienen un tipo de PDU de respuesta. La aplicacin de reenvo
mediante proxy determina qu solicitud o notificacin reenviada anteriormente, de
haberla, se corresponde con esta respuesta, y enva la PDU de respuesta adecuada.
Mensajes que contienen una indicacin de informe. Las PDU de informe son co
municaciones entre motores SNMPv3. La aplicacin de reenvo mediante proxy
determina qu solicitud o notificacin reenviada previamente, de haberla, se co
rresponde con esta indicacin de informe y reenva de vuelta la indicacin de in
forme al iniciador de la solicitud o notificacin.
PROCESAMIENTO DE MENSAJES Y MODELO DE SEGURIDAD DE USUARIO
El procesamiento de mensajes implica un modelo de procesamiento de mensajes de pro
psito general y un modelo de seguridad especfico; esta relacin se muestra en la Fi
gura 8.8.
Modelo de procesamiento de mensajes
El RFC 2572 define un modelo de procesamiento de mensajes de propsito general. Este
modelo es responsable de aceptar las PDU del dispatcher, encapsularlas en mensajes e
invocar al USM para insertar parmetros relacionados con la seguridad en la cabecera
del mensaje. El modelo de procesamiento de mensajes tambin acepta mensajes entran
tes, llama al USM para procesar los parmetros relativos a la seguridad en la cabecera
del mensaje y entrega la PDU encapsulada al dispatcher.
La Figura 8.9 ilustra la estructura del mensaje. Los primeros cinco campos son ge
nerados por el modelo de procesamiento de mensajes en los mensajes salientes y proce
sados por el mismo en los mensajes entrantes. Los siguientes seis campos muestran los
parmetros de seguridad usados por USM. Por ltimo, la PDU, junto con el contextEn-
ginelD y contextName, constituye una PDU extendida (scoped), que se usa para el pro
cesamiento de la PDU.
Los primeros cinco campos son los siguientes:
msgVcraon: fijado a snmpv3(3).
msfD: identificador exclusivo usado entre entidades SNMP para coordinar men
sajes de solicitud y de respuesta, y usado por el procesador de mensajes para
coordinar el procesamiento del mensaje por medio de diferentes modelos de sub
sistema en la arquitectura El rango de este ID es de 0 a 231 -1.
msgVfaxSize: expresa en octetos el tamao mximo de un mensaje permitido por
el emisor del mensaje, con un rango de 484 hasta 231 -1. Este es el tamao mxi
mo de segmento que el emisor puede aceptar de otro motor SNMP (ya sea una res
puesta u otro tipo de mensaje).
msgFlags ristra de octetos que contiene tres indicadores en los tres bits menos
significativos: reportableFlag, privFlag, authFlag. Si reportableFlag = 1, entonces
se debe devolver una PDU de informe al emisor bajo esas condiciones que pue
den ocasionar la generacin de una PDU de informe; cuando el indicador es cero,
puede no enviarse una PDU de informe (Report PDU). El reportableFlag se fija a
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 8 3
msg V ersin
msg lD
msg MaxS i ze >
msgFlags
m s g S e c u r i t y M o d e l J
m s g A u t h o r it a ti v e E n g in e ID
m s g A u t h o r it a t i v e E n g in e B o o t s
m s g A u t h o r it a t i v e E n g in e T i m e
ms g Us e rN a m e
m s g A u t h e n t i c a t i o n P a ra m e te rs
msgPriva cyPa rameter s
1i
con textEngin eID
con te x t Na m e
o
"O

T3
t PDU
F
<
1 ' 1
Generado/procesado por
modelo de procesamiento
de mensajes
Generado/procesado
por modelo de seguridad
de usuario (USM)
PDU extendida
(texto claro o cifrado)
Figura 8 . 9 F o r m a t o d e m e n s a j e S N M P c o n U S M
uno por el emisor en todos los mensaje que contienen una solicitud (Get, Set) o un
Inform, y se fija a cero para los mensajes que contienen una respuesta, un Trap o
una PDU de informe. El reportableFlag es una ayuda secundaria para determinar
cundo enviar un informe. Este slo se usa en casos en los que la parte de PDU del
mensaje no puede ser decodificada (por ejemplo, cuando falla el descifrado debi
do a una clave incorrecta). El privFlag y el authFlag son establecidos por el emi
sor para indicar el nivel de seguridad que se aplic al mensaje. Para privFlag = 1,
se aplic cifrado y para privFlag = 0, se aplic autentificacin. Se permiten todas
las combinaciones excepto (privFlag = 1Y authFlag = 0); es decir, no se permite
cifrado sin autentificacin.
msgecurtyModel: un identificador en el rango de 0 a 231 -1 que indica qu mo
delo de seguridad us el emisor para preparar este mensaje y, por lo tanto, qu mo
delo de seguridad debe usar el receptor para procesarlo. Los valores reservados in
cluyen uno para SNMPvl, dos para SNMPv2c (SNMPv2 con la herramienta de
comunidad SNMPvl) y tres para SNMPv3.
Modelo de seguridad de usuario
El RFC 2574 define el modelo de seguridad de usuario (USM). USM proporciona ser
vicios de autentificacin y privacidad para SNMP. Concretamente, USM est diseado
para proteger de las siguientes amenazas:
www.FreeLibros.org
2 8 4 Fundamentos de seguridad en redes. Aplicaciones y estndares
Modificacin de informacin: una entidad podra alterar un mensaje en trnsito
generado por una entidad autorizada de tal forma que cause operaciones de gestin
no autorizadas, incluyendo fijar valores de objetos. La base de esta amenaza es que
una entidad no autorizada podra cambiar cualquier parmetro de gestin, inclu
yendo los relacionados con la configuracin, las operaciones y el registro de acti
vidades (accounting) .
Suplantacin: una entidad puede emprender operaciones de gestin para las que
no tiene autorizacin, asumiendo la identidad de una entidad autorizada.
Modificacin d d flujo d e mensajes: SNMP est diseado para operar sobre un
protocolo de transporte no orientado a conexin. Hay una amenaza por la que los
mensajes SNMP podran ser reordenados, retrasados o repetidos (duplicados) para
producir operaciones de gestin no autorizadas. Por ejemplo, se podra copiar un
mensaje para reiniciar un dispositivo y repetirlo ms tarde.
Revelacin: una entidad podra observar los intercambios entre un gestor y un
agente y, por lo tanto, descubrir los valores de objetos gestionados y los eventos
notificados. Por ejemplo, la observacin de un comando Set que cambia las con
traseas podra permitir a un atacante descubrir las nuevas contraseas.
USM no est diseado contra las siguientes amenazas:
Denegacin deservido: un atacante puede imposibilitar los intercambios entre un
gestor y un agente.
Anlisis d d trfico: un atacante puede observar el patrn general del trfico entre
gestores y agentes.
La falta de medidas contra la amenaza de denegacin de servicio se puede justificar de
dos formas: en primer lugar, estos ataques se distinguen en muchos casos del tipo de
fallos en la red con los que de hecho se las tiene que arreglar cualquier aplicacin via
ble de gestin de red; y segundo, es probable que un ataque de denegacin de servicio
interrumpa todos los tipos de intercambio, que es una cuestin de una herramienta ge
neral de seguridad y no de una insertada en un protocolo de gestin de red. En lo que
respecta al anlisis del trfico, muchos patrones de trfico de gestin de redes son pre
decibles (por ejemplo, las entidades pueden gestionarse mediante comandos SNMP
emitidos de forma regular por una o varias estaciones de gestin) y, por lo tanto, la pro
teccin contra la observacin de estos patrones de trfico no implica ventajas signifi
cativas.
Funciones criptogrficas
Dos funciones criptogrficas se definen para USM: autentificacin y cifrado. Para per
mitir estas funciones, un motor SNMP requiere dos valores: una clave privada (privKey)
y una clave de autentificacin (authKey). Los valores separados de estas dos claves se
mantienen para los siguientes usuarios:
Usuarios locales: cualquier agente principal en este motor SNMP para el cual se
autorizan operaciones de gestin.
Usuarios ranotos: cualquier agente principal en un motor SNMP remoto para el
cual se desea la comunicacin.
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 285
Estos valores son atributos de usuario almacenados para cada usuario relevante. Los
valores de privKey y authKey no son accesibles mediante SNMP.
USM permite el uso de uno de los dos protocolos de autentificacin alternativos:
HMAC-MD5-96 y HMAC-SHA-96. HMAC, descrito en el Captulo 3, usa una funcin
hash segura y una clave secreta para producir un cdigo de autentificacin de mensajes.
Para HMAC-MD5-96, HMAC se usa con MD5 como funcin hash subyacente. Como
entrada al algoritmo HMAC se usa una clave de autentificacin de 16 octetos (128 bits).
El algoritmo produce una salida de 128 bits, que se trunca en 12 octetos (96 bits). Para
HMAC-SHA-96, la funcin hash subyacente es SHA-1. La clave de autentificacin tie
ne una longitud de 20 octetos. El algoritmo produce una salida de 20 octetos, que nue
vamente se trunca en 12 octetos.
USM usa el modo CBC del DES para el cifrado. Como entrada al protocolo de ci
frado, se proporciona una clave privada de 16 octetos. Los primeros ocho octetos (64
bits) de esta clave privada se usan como una clave DES. Como DES slo requiere una
clave de 56 bits, se ignora el bit menos significativo de cada octeto. Para el modo CBC,
se necesita un vector de inicializacin de 64 bits. Los ltimos ocho octetos de la clave
privada contienen un valor que se usa para generar dicho vector de inicializacin.
Motores autoritativos y no autoritativos
En cualquier transmisin de mensajes, una de las dos entidades, emisor o receptor, est
designada como el motor SNMP autoritativo, segn las siguientes reglas:
Cuando un mensaje SNMP contiene una carga til que espera una respuesta (por
ejemplo, una Get, GetNext, GetBulk, Set o Inform PDU), entonces el receptor de
dichos mensajes es autoritativo.
Cuando un mensaje SNMP contiene una carga til que no espera una respuesta
(por ejemplo, una SNMPv2-Trap, Response o Report PDU), entonces el emisor de
dicho mensaje es autoritativo.
As, para los mensajes enviados en nombre de un generador de comandos y para men
sajes Inform de un iniciador de notificacin, el receptor es autoritativo. Para mensajes
enviados en nombre de un respondedor de comandos o para mensajes Trap de un ini
ciador de notificacin, el emisor es autoritativo. Esta designacin sirve con dos finali
dades:
La validez temporal de un mensaje se determina con respecto a un reloj que man
tiene el motor autoritativo. Cuando un motor autoritativo enva un mensaje (Trap,
Response, Report), contiene el valor actual de su reloj, de forma que el receptor no
autoritativo puede sincronizarse con ese reloj. Cuando un motor no autoritativo en
va un mensaje (Get, GetNext, GetBulk, Set, Inform), incluye su estimacin actual
del valor temporal en el destino, permitiendo que el destino acceda a la validez
temporal del mensaje.
Un proceso de localizacin de clave, que se describe ms tarde, permite que una
sola entidad principal tenga claves almacenadas en mltiples motores; estas claves
estn localizadas para el motor autoritativo de tal forma que la entidad principal
sea responsable de una sola clave y se evite, as, el riesgo que corre la seguridad si
se almacenan copias mltiples de la misma clave en una red distribuida.
www.FreeLibros.org
286 Fundamentos de seguridad en redes. Aplicaciones y estndares
Tiene sentido designar al receptor del generador de comandos y las PDU Inform
como el motor autoritatvo y, por lo tanto, responsable de comprobar la validez tempo
ral del mensaje. Si una respuesta o trap se retrasa o se repite, no se produciran muchos
daos. Sin embargo, el generador de comandos y, hasta cierto punto, las PDU Inform
dan como resultado operaciones de gestin como, por ejemplo, la lectura o el estableci
miento de objetos MIB. As, es importante garantizar que dichas PDU no se retrasan ni
se repiten, lo cual podra ocasionar efectos no deseados.
Parmetros de mensajes USM
Cuando el procesador de mensajes pasa un mensaje saliente al USM, ste rellena los pa
rmetros relacionados con la seguridad en la cabecera del mensaje. Cuando el procesador
de mensajes pasa un mensaje entrante al USM, el USM procesa los valores contenidos en
esos campos. Los parmetros relacionados con la seguridad son los siguientes:
msg\ufaortatvdEji^iielD: el snmpEngineID del motor SNMP autoritatvo impli
cado en el intercambio de este mensaje. As, este valor se refiere a la fuente para un
Trap, Response o Report, y al destino para un Get, GetNext, GetBulk, Set o Inform.
m ^ u t h o r i t a t i v e E n ^ e B o o t s : el valor snmpEngineBoots del motor SNMP au
toritatvo implicado en el intercambio de este mensaje. El objeto snmpEngineBo
ots es un entero del rango entre 0 y 231- i que representa el nmero de veces que
este motor SNMP se ha inicializado o reinicial izado desde su configuracin inicial.
ms^\uthoritativeii^nTme el valor snmpEngineTime del motor SNMP auto-
ritativo implicado en el intercambio de este mensaje. El objeto snmpEngineTime
es un entero de entre 0 y 231-1 que representa el nmero de segundos desde que
este motor SNMP autoritatvo increment por ltima vez el objeto snmpEngine
Boots. Cada motor SNMP autoritatvo es responsable de incrementar su propio va
lor snmpEngineTime una vez por segundo. Un motor no autoritatvo es responsa
ble de incrementar su nocin de snmpEngineTime para cada motor autoritatvo
remoto con el que se comunique.
nsgUserNames el agente principal en cuyo nombre se est intercambiando el
mensaje.
msg\utfaoitkatonParanietm: es nulo si no se est usando autentificacin para
este intercambio. De lo contrario, es un parmetro de autentificacin. Para la defi
nicin actual de USM, el parmetro de autentificacin es un cdigo de autentifica
cin de mensajes HMAC.
m ^ r v a r y P a r a m e t e r s : es nulo si no se usa privacidad para este intercambio. De
lo contrario, es un parmetro de privacidad. Para la definicin actual de USM, el
parmetro de privacidad es un valor que se usa para formar el valor inicial en el al
goritmo CBC del DES.
La Figura 8.10 resume la operacin del USM. Para la transmisin de mensajes, se rea
liza el cifrado en primer lugar, si fuera necesario. La PDU extendida se cifra y se sita
en la carga til del mensaje, y el valor msgPrivacyParameters se fija al valor necesario
para generar el valor inicial. Luego, se realiza la autentificacin, si es necesario. El men
saje completo, incluyendo la PDU extendida se introduce en el HMAC, y el cdigo de
autentificacin resultante se coloca en msgAuthenticacionParameters. Para los mensajes
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 8 7
F
i
g
u
r
a

8
.
1
0

P
r
o
c
e
s
a
m
i
e
n
t
o

d
e

m
e
n
s
a
j
e
s

U
S
M
www.FreeLibros.org
288 Fundamentos de seguridad en redes. Aplicaciones y estndares
entrantes, la autentificacin se realiza en primer lugar, si es necesario. El USM, prime
ro, contrasta el MAC entrante con un MAC que calcul; si los dos valores coinciden, en
tonces el mensaje se considera autntico (proviene de la fuente supuesta y no ha sido al
terado durante l a transmisin). Luego el USM comprueba si el mensaje se encuentra en
una ventana de tiempo vlida, como se explica ms tarde. Si el mensaje no es vlido en
tiempo, se descarta como no autntico. Por ltimo, si se ha cifrado la PDU extendida, el
USM lleva a cabo un descifrado y devuelve el texto claro.
Mecanismos de validez temporal de USM
USM incluye un conjunto de mecanismos de validez temporal para evitar retrasos o re
peticiones en los mensajes. Cada motor SNMP que pueda actuar en capacidad de un mo
tor autoritatvo debe mantener dos objetos, snmpEngineBoots y snmpEngineTime, que
se refieren a su valor de tiempo local. Cuando se instala un motor SNMP por primera
vez, estos dos valores se fijan a cero. A partir de ah, snmpEngineTime se incrementa
una vez por segundo. S alguna vez snmpEngineTime alcanza su valor mximo (231-1),
snmpEngineBoots se incrementa como si se hubiese reiniciado el sistema, y snmpEngi
neTime se fija a cero y empieza a incrementarse otra vez. Usando un mecanismo de sin
cronizacin, un motor no autoritatvo mantiene una estimacin de los valores tempora
les de cada motor autoritatvo con el que se comunica. Estos valores estimados se ponen
en cada mensaje saliente y permiten al motor autoritatvo receptor determinar si el valor
temporal del mensaje entrante es vlido o no.
El mecanismo de sincronizacin funciona de la siguiente forma. Un motor no auto
ritatvo guarda una copia local de tres variables para cada motor SNMP autoritatvo co
nocido por ese motor:
ampEn^fncBoots: el valor ms reciente de snmpEngineBoots para el motor au-
tortativo remoto.
sMnpEn^neTme: esta nocin del motor de snmpEngineTime para el motor au
toritatvo remoto. Este valor se sincroniza con el motor autoritatvo remoto me
diante el proceso de sincronizacin que se describe ms tarde. Entre los sucesos
de sincronizacin, este valor se incrementa una vez por segundo para mantener una
sincronizacin aproximada con el motor autoritatvo remoto.
laletRecdvedEn^neTime: el valor ms alto de msgAuthoritatveEngineTime
que este motor ha recibido del motor autoritatvo remoto; este valor se actualiza
cada vez que se recibe un valor mayor de msgAuthoritatveEngineTime. La finali
dad de esta variable es proteger contra ataques de repeticin que podran hacer que
la nocin de snmpEngineTime del motor SNMP no autoritatvo no avanzara.
Para cada motor autoritatvo remoto conocido por este motor se mantiene un conjunto
formado por estas tres variables. Lgicamente, los valores se mantienen en algn tipo de
cach, indexado por el snmpEngineID exclusivo de cada motor autoritatvo remoto.
Para hacer posible que los motores no autoritatvos mantengan la sincronizacin de
tiempo, cada motor autoritatvo inserta sus valores de inicio y de tiempo, as como su
valor de snmpEngineID, en cada mensaje saliente de respuesta, de informe y de inter
ceptacin en los campos msgAuthoritatveEngineBoots, msgAuthoritatveEngineTime y
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 8 9
msgAuthoritativeEnginelD. Si el mensaje es autntico y est dentro de la ventana de
tiempo, entonces el motor no autoritativo receptor actualiza sus variables locales
(snmpEngineBoots, snmpEngineTime y latestReceivedEngineTime) para ese motor re
moto de acuerdo con las siguientes reglas:
1. Se produce una actualizacin si al menos es cierta una de las dos condiciones si
guientes:
(msgAuthoritativeEngineBoots > snmpEngineBoots) O
[(msgAuthoritativeEngineBoots = snmpEngineBoots) Y
(msgAuthoritativeEngineTime > latestReceivedEngineTime)]
La primera condicin dice que debera producirse una actualizacin si el valor de inicio
del motor autoritativo ha aumentado desde la ltima actualizacin. La segunda condi
cin dice que s el valor de inicio no ha aumentado, entonces debera producirse una ac
tualizacin si el valor temporal del motor entrante es mayor que la ltima recibida. El
valor de tiempo del motor entrante ser menor que el ltimo recibido si dos mensajes
entrantes llegan desordenados, lo que puede ocurrir, o si se est produciendo un ataque
de repeticin; en cualquier caso, el motor receptor no realizar una actualizacin.
2. Si se hace una llamada de actualizacin, se llevan a cabo los siguientes cambios:
fijar snmpEngineBoots al valor de msgAuthoritativeEngineBoots
fijar snmpEngineTime al valor de msgAuthoritativeEngineTime
fijar latestReceivedEngineTime al valor de msgAuthoritativeEngineTime
Si damos la vuelta a la lgica se observa que si msgAuthoritativeEngineBoots
< snmpEngineBoots, no se produce actualizacin. Un mensaje como este no se con
sidera autntico y debe ser ignorado. Si msgAuthoritativeEngineBoots = snmpEngine
Boots, pero msgAuthoritativeEngineTime < latestReceivedEngineTime, tampoco se
produce actualizacin. En este caso, el mensaje puede ser autntico, pero puede estar
desordenado, en cuyo caso no se garantiza una actualizacin de snmpEngineTime.
Obsrvese que la sincronizacin slo se utiliza si el servicio de autentificacin est en
uso para este mensaje y se ha determinado que el mensaje es autntico mediante HMAC.
Esta restriccin es esencial porque el mbito de autentificacin incluye msgAuthoritative
EnginelD, msgAuthoritativeEngineBoots y msgAuthoritativeEngine-Time, asegurando
as que estos valores son vlidos.
SNMPv3 dicta que un mensaje debe recibirse dentro de una ventana de tiempo
razonable, para evitar ataques de retraso y de repeticin. La ventana de tiempo debera
elegirse de forma que fuera lo ms pequea posible dada la exactitud de los relojes im
plicados, los retrasos de las comunicaciones y la frecuencia con que se sincronizan es
tos relojes. Si la ventana de tiempo se fija demasiado pequea, los mensajes autnticos
sern rechazados como no autnticos. Por otra parte, una ventana de tiempo grande au
menta la vulnerabilidad a retrasos dainos de mensajes.
Consideramos el caso ms importante de un receptor autoritativo; la comprobacin
de la validez temporal por parte de un receptor no autoritativo difiere ligeramente. Con
cada mensaje entrante que se ha autentificado y cuyo msgAuthoritativeEnginelD es el
mismo que el valor de snmpEngineID para este motor, el motor compara los valores de
msgAuthoritativeEngineBoots y msgAuthoritativeEngineTime del mensaje entrante con
www.FreeLibros.org
2 9 0 Fundamentos de seguridad en redes. Aplicaciones y estndares
los valores de snmpEngineBoots y snmpEngineTime que mantiene este motor para s
mismo. El mensaje entrante se considera fuera de la ventana de tiempo si alguna de es
tas condiciones es verdadera:
snmpEngineBoots = 231 - 1 O
msgAuthoritativeEngineBoots * snmpEngineBoots O
el valor de msgAuthoritativeEngineTime difiere del valor de snmpEngineTime en
ms de 150 segundos.
La primera condicin dice que si snmpEngineBoots se queda fijo en su valor mximo,
ningn mensaje entrante se puede considerar autntico. La segunda condicin dice que
un mensaje debe tener un tiempo de inicio igual al del motor local; por ejemplo, s el
motor local se ha reiniciado y el motor remoto no se ha sincronizado con el motor local
desde el reinicio, los mensajes de ese motor remoto no se consideran autnticos. La con
dicin final dice que el valor de tiempo del mensaje entrante debe ser mayor que el va
lor de tiempo local menos 150 segundos y menor que el valor de tiempo local ms 150
segundos.
Si un mensaje se considera fuera de la ventana de tiempo, el mensaje no se conside
ra autntico y se devuelve una indicacin de error (notlnTimeWindow) al mdulo que
hizo la llamada.
Nuevamente, como con la sincronizacin, la comprobacin de la validez de tiempo
slo se lleva a cabo si el servicio de autentificacin est en uso y el mensaje es autnti
co, asegurando la validez de los campos de cabecera del mensaje.
Localizacin de claves
Un requisito para el uso de los servicios de autentificacin y de privacidad de SNMPv3
es que, para cualquier comunicacin entre una entidad principal en un motor no autori-
tativo y un motor autoritativo remoto, se deben compartir una clave de autentificacin
secreta y una de privacidad secreta. Estas claves permiten a un usuario en un motor no
autoritativo (generalmente, un sistema de gestin) emplear autentificacin y privacidad
con sistemas autortativos remotos que gestiona el usuario (normalmente, sistemas agen
tes). El RFC 2574 proporciona directrices para la creacin, actualizacin y gestin de
estas claves.
Para simplificar la carga de la gestin de claves a las entidades principales, cada una
slo tiene que mantener una nica clave de autentificacin y una nica clave de cifrado.
Estas claves no se almacenan en una MIB y no se puede acceder a ellas a travs de
SNMP. En este subapartado, se observan primero las tcnicas para la generacin de es
tas claves a partir de una contrasea. A continuacin, nos fijaremos en el concepto de
localizacin de claves, que permite a una entidad principal compartir una sola clave
de autentificacin y cifrado con cada motor remoto, mientras mantiene localmente una
sola clave de autentificacin y cifrado. Estas dos tcnicas fueron propuestas por prime
ra vez en [BLUM97a].
Un usuario necesita una clave de privacidad de 16 octetos y una clave de autentifi
cacin de 16 o 20 octetos. Para las claves pertenecientes a usuarios humanos, es con
veniente que el usuario pueda emplear una contrasea legible para ellos, en vez de una
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 9 1
clave de ristras de bits. Por lo tanto, el RFC 2574 define un algoritmo para establecer
la correspondencia entre la contrasea del usuario y una clave de 16 o de 20 octetos.
USM no impone restricciones a la contrasea en s misma, pero las polticas locales de
gestin obligan a los usuarios a emplear contraseas que no sean fciles de adivinar.
La generacin de claves a partir de contraseas se realiza de la siguiente manera:
Usar la contrasea del usuario como entrada y producir una ristra de 220 octetos
(1.048.576 octetos) repitiendo el valor de la contrasea tantas veces como sea ne
cesario, truncando el ltimo valor si fuese necesario, para formar la ristra digestO.
Por ejemplo, una contrasea de ocho caracteres (23 octetos) se concatenara consi
go misma 217 veces para formar digestO.
Si se desea una clave de 16 octetos, se toma el hash MD5 de digestO para formar
digest. Si se quiere una clave de 20 octetos, se toma el hash SHA-1 de digestO
para formar digest. La salida es la clave del usuario.
Una ventaja de esta tcnica es que reduce en gran medida el ataque de diccionario por
fuerza bruta, en el que un adversario prueba con muchas posibles contraseas, generan
do la clave a partir de cada una, y luego comprueba si la clave resultante funciona con
los datos de autentifcacin o cifrado de que dispone. Por ejemplo, si un atacante inter
cepta un mensaje autentificado, podra intentar generar el valor HMAC con distintas
claves de usuario posibles. S se produce una coincidencia, el atacante puede asumir que
la contrasea ha sido descubierta. Este proceso de dos pasos aumenta de forma signifi
cativa la cantidad de tiempo que necesitar un ataque de este tipo.
Otra ventaja de esta tcnica es que desasocia las claves de usuario de cualquier sis
tema particular de gestin de red (NMS, Network Management Systerr). Ningn NMS
necesita almacenar valores de claves de usuario. En vez de eso, cuando sea necesario,
una clave de usuario se genera a partir de la contrasea de ese usuario. [BLUM97b] pre
senta las siguientes consideraciones que promueven el uso de un enfoque de contrasea
independiente de NMS:
Si hay que almacenar una clave, en vez de generarla a partir de una contrasea, una
alternativa es mantener un depsito centralizado de claves secretas. Pero, por otra
parte, esto afecta la fiabilidad general y puede hacer que la resolucin de proble
mas sea imposible si no se puede acceder a dicho depsito cuando sea necesario.
Por otra parte, s se mantienen depsitos duplicados, esto pone en peligro la segu
ridad general proporcionando a los posibles atacantes ms objetivos que atacar.
Si se usan depsitos centralizados o depsitos mltiples duplicados, deben guar
darse en ubicaciones seguras. Esto puede reducir la oportunidad de establecer un
campamento de reenvo durante la extincin del peligro (por ejemplo, resolu
cin de problemas cuando segmentos impredecibles de la red estn inoperativos
y/o inaccesibles durante un perodo no previsible de tiempo).
Se podra usar una sola contrasea para generar una nica clave tanto para autentifica-
cin como para cifrado. Un esquema ms seguro consiste en usar dos contraseas, una
para generar una clave de autentifcacin y otra para generar una clave de cifrado dife
renciada.
www.FreeLibros.org
2 9 2 Fundamentos de seguridad en redes. Aplicaciones y estndares
Una clave localizada se define en el RFC 2574 como una clave secreta compartida
entre un usuario y un motor SNMP autoritativo. El objetivo es que el usuario slo tenga
que mantener una clave (o dos claves s se requiere autentificacin y privacidad) y, por
lo tanto, slo necesite recordar una contrasea (o dos). Los secretos reales compartidos
entre un usuario particular y cada motor SNMP autoritativo son diferentes. El proceso
mediante el cual una clave nica de usuario se convierte en mltiples claves unvocas,
una para cada motor SNMP remoto, se conoce como localizacin de claves.
[BLUM97a] presenta las razones para el uso de esta estrategia, que se resume a conti
nuacin.
Se pueden definir los siguientes objetivos para la gestin de claves:
Cada sistema agente SNMP en una red distribuida tiene su propia clave nica para
que cada usuario autorizado la gestione. Si hay mltiples usuarios autorizados
como administradores, el agente tiene una clave nica de autentificacin y de ci
frado para cada usuario. As, si la clave para un usuario est comprometida, no se
ven afectadas las claves de otros usuarios.
Las claves para un usuario en diferentes agentes son distintas. As, si un agente est
comprometido, slo las claves de usuario para ese agente estn comprometidas y
no las claves del usuario en vigor en otros agentes.
La gestin de red se puede llevar a cabo desde cualquier punto de la red, indepen
dientemente de la disponibilidad de un sistema de gestin de red preconfigurado
(NMS). Esto permite que un usuario realice funciones de gestin desde cualquier
estacin de gestin. Esta capacidad la proporciona el algoritmo de contrasea a
clave descrito anteriormente.
Tambin se pueden definir los siguientes aspectos que deben ser evitados:
Un usuario tiene que recordar (o de otra forma gestionar) un gran nmero de cla
ves, nmero que aumenta con la incorporacin de nuevos agentes gestionados.
Un adversario que descubra una clave para un agente es capaz de suplantar a cual
quier otro agente ante cualquier usuario, o a cualquier usuario ante otro agente.
Para alcanzar los objetivos y las consideraciones que se han mencionado, se correlacio
na una sola clave de usuario, por medio de una funcin unidireccional no reversible (por
ejemplo, una funcin hash segura) con distintas claves localizadas para diferentes mo
tores autentificados (diferentes agentes). El procedimiento es el siguiente:
Formar la ristra digest2 concatenando digest (que se describi anteriormente), el
valor snmpEnginelD del motor autoritativo y digest.
Si se desea una clave de 16 octetos, se toma el hash MD5 de digest2. Si se desea
una clave de 20 octetos, se toma el hash SHA-1 de digest2. La salida es la clave
localizada del usuario.
La clave localizada resultante se puede, luego, configurar en el sistema del agente de al
guna forma segura. Debido a la naturaleza unidireccional de MD5 y SHA-1, es imposi
ble que un adversario descubra una clave de usuario, incluso si consigue descubrir una
clave localizada.
La Figura 8.11 resume el proceso de localizacin de claves.
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 9 3
f Usa el hash de
clave de usuario
\ EngineID remoto
io y e l )
l o to / R
rio,.
Clave
localizada
f Usa el hash de
clave de usuario
\ EngineID remoto
j el M O
io y e | ) ' " r ;
l o to / R
rio,.
Clave
localizada
/ Usa el hash de
clave de usuario y
\ EngineID remoto J R
rio*.
Clave
localizada
Figura 8.11 Localizacin de clave
CONTROL DE ACCESO BASADO ENVISTAS
El control de acceso es una funcin que se realiza en el nivel de PDU. Un documento
sobre el control de acceso define los mecanismos para determinar si debera permitirse
el acceso a un objeto gestionado en una MIB local por una entidad principal remota. Se
podran definir muchos mecanismos de control de acceso imaginables. Los documentos
SNMPv3 definen el modelo de control de acceso basado en vistas (VACM, View-Based
Access Control Model). Dicho modelo hace uso de una MIB que define la poltica de
control de acceso para este agente y hace posible usar configuracin remota.
El modelo tiene dos caractersticas fundamentales:
VACM determina si debera permitirse el acceso a un objeto gestionado en una
MIB local por un usuario remoto.
VACM hace uso de una MIB que
define la poltica de control para este agente
hace posible usar configuracin remota
Elementos del modelo VACM
El RFC 2575 define cinco elementos que conforman el VACM: grupos, nivel de seguri
dad, contextos, vistas MIB y poltica de acceso.
Un f^upose define como un conjunto de cero o ms secuencias <securityModel, se-
curityName> en cuyo nombre se puede acceder a objetos de gestin SNMP. Un secu-
rityName se refiere a una entidad principal, y los derechos de acceso para todas las en
tidades principales de un grupo determinado son idnticos. Un groupName nico se
asocia con cada grupo. El concepto de grupo es una herramienta til para la categoriza-
www.FreeLibros.org
2 9 4 Fundamentos de seguridad en redes. Aplicaciones y estndares
cin de los gestores con respecto a los derechos de acceso. Por ejemplo, todos los ad
ministradores del nivel superior pueden tener una serie de derechos de acceso, mientras
que los administradores de niveles intermedios pueden tener una serie de derechos de
acceso diferente.
Cualquier combinacin dada de securityModel y securityName puede pertenecer al
menos a un grupo. Es decir, para este agente, una entidad principal dada cuyas comuni
caciones estn protegidas por un modelo de seguridad determinado slo puede incluirse
en un grupo.
Los derechos de acceso para un grupo pueden diferir dependiendo del n v d d e s e
n i l i d a d del mensaje que contiene la solicitud. Por ejemplo, un agente puede permitir
acceso de slo lectura (.read-onl}) para una solicitud transmitida en un mensaje autenti
ficado, pero puede requerir autentificacin para el acceso de escritura (wrte). Adems,
para determinados objetos sensibles, el agente puede requerir que la solicitud y su res
puesta se transmitan usando el servicio de privacidad.
Un contacto MIB es un subconjunto, al que se asigna un nombre, de las instancias
de objeto en la MIB local. Los contextos proporcionan una forma til de agregar obje
tos a colecciones con diferentes polticas de acceso.
El contexto es un concepto que se relaciona con el control de acceso. Cuando una es
tacin de gestin interacta con un agente para acceder a la informacin de gestin en
el agente, entonces la interaccin se produce entre una entidad principal de gestin y el
motor SNMP del agente, y los privilegios de control de acceso se expresan en una vista
MIB que se aplica a esta entidad principal y a este contexto. Los contextos tienen las si
guientes caractersticas fundamentales:
Una entidad SNMP, identificada unvocamente por un contextEngineID, puede te
ner ms de un contexto.
Un objeto o una instancia de objeto puede aparecer en ms de un contexto.
Cuando existen mltiples contextos, para identificar una instancia de un objeto in
dividual, se deben identificar su contextName y contextEngineID, adems de su
tipo de objeto e instancia.
Con frecuencia se desea restringir el acceso de un grupo particular a una parte de los ob
jetos gestionados en un agente. Para lograr este objetivo, el acceso a un contexto se rea
liza por medio de una vista MIB, que define un conjunto especfico de objetos gestio
nados (y, opcionalmente, instancias especficas de objetos). VACM hace uso de una
tcnica potente y flexible para definir las vistas MIB, basada en los conceptos de subr-
boles de vistas y familias de vistas. La vista MIB se define como una coleccin, o fa
milia, de subrboles, cada uno de los cuales se incluye en la vista o se excluye de ella.
Los objetos gestionados en una base de datos local se organizan de forma jerr
quica o de rbol, basndose en sus identificadores de objeto. Esta base de datos local
contiene un subconjunto de todos los tipos de objeto definidos segn el estndar de
Internet Estructura de la Informacin de Gestin (SMI, Structure o f Management In
formation) e incluye instancias de objeto cuyos identificadores se ajustan a las con
venciones de SMI.
SNMPv3 incluye el concepto de subrbol. Un subrbol es simplemente un nodo de
la jerarqua de denominacin de la MIB ms todos sus elementos subordinados. Ms
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 295
formalmente, un subrbol puede definirse como un conjunto de todos los objetos e ins
tancias de objetos que aaden a sus nombres un prefijo comn ASN. 1 OBJECTIDEN-
TIFIER (identificador de objeto). El prefijo comn ms largo de todas las instancias del
subrbol es el identificador de objeto del nodo padre de ese subrbol.
Hay tres vistas MIB asociadas con cada entrada en vacmAccessTable, una para leer,
otra para escribir y otra para notificar acceso. Cada vista MIB se compone de una serie
de subrboles de vistas. Cada subrbol de vistas en la vista MIB se especifica como in
cluido o excluido. Es decir, la vista MIB incluye o excluye todas las instancias de obje
tos contenidas en ese subrbol. Adems, se define una mscara de vista para reducir la
cantidad de informacin de configuracin necesaria cuando se requiere control de acce
so exhaustivo (por ejemplo, control de acceso en el nivel de instancia de objeto).
VACM permite que un motor SNMP se configure para imponer una serie concreta de
derechos de acceso, lo cual constituye una poltica d e acceso. La determinacin de ac
ceso depende de los siguientes factores:
La entidad principal que realiza la solicitud de acceso. El VACM hace posible que
un agente permita diferentes privilegios de acceso a distintos usuarios. Por ejem
plo, un sistema gestor responsable de la configuracin de una red amplia puede te
ner absoluta autoridad para alterar elementos en la MIB local, mientras que un ad
ministrador de nivel intermedio con responsabilidad de supervisin puede tener
acceso slo de lectura y puede, adems, estar limitado a acceder slo a un subcon-
junto de la MIB local. Como se ha explicado, las entidades principales estn asig
nadas a grupos y la poltica de acceso se especifica con respecto a grupos.
El nivel d e s c u i d a d por el cual se transmiti una solicitud en un mensaje SNMP.
Normalmente, un agente requerir el uso de autentificacin para los mensajes que
contengan una solicitud de establecimiento (operacin de escritura).
El modelo de seguridad usado para procesar el mensaje de solicitud. Si se imple-
mentan en un agente mltiples modelos de seguridad, el agente puede configurar
se para proporcionar diferentes niveles de acceso a las solicitudes comunicadas por
mensajes procesados mediante diferentes modelos de seguridad. Por ejemplo, de
terminados elementos pueden estar accesibles si el mensaje de solicitud viene a
travs de USM, y no lo estn si el modelo de seguridad es SNMPvl.
El contrato MIB para la solicitud.
La instancia d e objeto especfica para la cual se requiere el acceso. Algunos ob
jetos guardan informacin ms crtica o confidencial que otros y, por lo tanto, la
poltica de acceso debe depender de l a instancia especfica de objeto que se ha so
licitado.
El tipo de acceso solicitado (de lectura, escritura o notificacin). Leer, escribir y
notificar son operaciones de gestin bien diferenciadas, y las distintas polticas de
control de acceso pueden aplicarse para cada una de estas operaciones.
Procesamiento de control de acceso
Una aplicacin SNMP invoca al VACM mediante la primitiva isAccessAllowed, con los
parmetros de entrada securityModel, securityName, securityLevel, viewType, context-
www.FreeLibros.org
296 Fundamentos de seguridad en redes. Aplicaciones y estndares
ame y varableName. Todos estos parmetros son necesarios para tomar la decisin de
control de acceso. En otras palabras, el subsistema de control de acceso se define de tal
forma que proporcione una herramienta muy flexible para configurar el control de ac
ceso en el agente, dividiendo los componentes de la decisin de control de acceso en seis
variables separadas.
La Figura 8.12, adaptada de una figura de RFC 2575, proporciona una forma til de
observar las variables de entrada y muestra cmo entran enjuego las distintas tablas en
la MIB de VACM tomando la decisin de control de acceso.
Quite: la combinacin de securtyModel y securityName definen el quin de esta
operacin; identifica una entidad principal dada cuyas comunicaciones estn
protegidas por un securityModel dado. Esta combinacin pertenece al menos a un
grupo en este motor SNMP. El vacmSecurityToGroupTable proporciona el group-
Name, dados el securityModel y el securityName.
Dnde el contextName especifica dnde se va a encontrar el objeto gestionado
deseado. El vacmContextTable contiene una lista de los contextNames reconoci
dos.
Cma la combinacin de securityModel y securityLevel define cmo se protegi
la solicitud entrante o la PDU Inform. La combinacin de quin, dnde y cmo
identifica cero o una entrada en vacmAccessTable.
Por q u el viewType especifica por qu se solicita el acceso: para una operacin
de lectura, escritura o notificacin. La entrada seleccionada en vacmAccessTable
contiene un viewName de la MIB para cada uno de estos tres tipos de operacin,
y viewType se usa para seleccionar un viewName especfico. Este viewName se
lecciona la vista MIB adecuada de vacmViewTreeFamilyTable.
Qu el varableName es un identificador de objeto cuyo prefijo identifica un tipo
de objeto especfico y cuyo sufijo identifica una instancia especfica de objeto. El
tipo de objeto indica qu tipo de informacin de gestin se solicita.
Cul: la instancia de objeto indica cul de los elementos de informacin se solici
ta especficamente.
Por ltimo, el varableName se compara con la vista MIB obtenida. S coincide con un
elemento de la vista MIB, entonces se concede el acceso.
Motivacin
Los conceptos que conforman el VACM parecen dar como resultado una definicin
compleja del control de acceso. Las razones para la introduccin de estos conceptos son
clarificar las relaciones implicadas en el acceso a la informacin de gestin y minimizar
los requisitos de almacenamiento y procesamiento en el agente. Para entender estos mo
tivos, considrese lo siguiente. En SNMPvl, el concepto de comunidad se usa para re
presentar la siguiente informacin relacionada con la seguridad:
La identidad de la entidad solicitante (estacin de gestin)
La identidad de la entidad que acta (agente actuando para s mismo o para una en
tidad representada mediante proxfl
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 9 7
F
i
g
u
r
a

8
.
1
2

L

g
i
c
a

d
e

V
A
C
M
www.FreeLibros.org
2 9 8 Fundamentos de seguridad en redes. Aplicaciones y estndares
La identidad de la ubicacin de la informacin de gestin a la que se va a acceder
(agente o entidad representada mediante proxy)
Informacin de autentifcacin
Informacin de control de acceso (autorizacin para realizar la operacin requerida)
Informacin de la vista MIB
Agrupando todos estos conceptos en una nica variable, se pierden la flexibilidad y la
funcionalidad. VACM proporciona el mismo conjunto de informacin relativa a la segu
ridad usando variables diferenciadas para cada elemento. sta es una mejora sustancial
con respecto a SNMPvl. Desasocia distintos conceptos para que los valores se puedan
asignar a cada uno de forma separada.
8 . 4 BIBLIOGRAFA Y SITIOS WEB RECOMENDADOS
[STAL99] ofrece un anlisis exhaustivo y detallado de SNMP, SNMPv2 y SNMPv3;
tambin proporciona una introduccin general a la tecnologa de gestin de red.
STAL99 Stallings, W. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Reading,
MA: Addison-Wesley, 1999.
Sitios web recomendados:
Grupo d e trabajo deSNMPv3delaIETF: contiene las copias ms recientes de
los RFC y los borradores de Internet relacionados con SNMPv3, adems de una
planificacin del trabajo pasado y futuro.
Sitio web SNMPv3fc mantenido por la Universidad Tcnica de Braunschweig.
Proporciona enlaces a los RFC y los borradores de Internet, copias de aclaraciones
y cambios propuestos enviados por el grupo de trabajo, y enlaces a vendedores con
implementaciones SNMPv3.
The Simple Web S it e mantenido por la Universidad de Twente. Constituye una
buena fuente de informacin sobre SNMP e incluye enlaces a muchas implemen
taciones de dominio pblico as como a listas de libros y artculos.
8 . 5 TRMINOS CLAVE, PREGUNTAS DE REPASO Y PROBLEMAS
TRMINOS CLAVE
agente
base de informacin de
gestin (MIB)
comunidad
estacin de gestin
gestin de red
localizacin de claves
nombre de comunidad
modelo de control de acceso
basado en vistas (VACM)
modelo de procesamiento
de mensajes
Modelo de seguridad de
usuario (USM)
poltica de acceso
proxy
SNMP
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 2 9 9
PREGUNTAS DE REPASO
& L En qu sentido se considera integrada una arquitectura de gestin de red?
&& Cules son los elementos fundamentales del modelo SNMP?
&& Qu es una MIB?
& 4 Qu capacidades o comandos bsicos se proporcionan en SNMPvl?
&5l Cul es la funcin de un /?ra*y SNMP?
& a Explica brevemente el concepto de comunidad de SNMPvl.
&7. Cul es la relacin entre SNMPvl, SNMPv2 y SNMPv3?
&& Qu amenazas contrarresta USM?
& a Cul es la diferencia entre un motor autoritatvo y uno no autoritatvo?
&10L Qu es la localizacin de claves?
&1L Enumera y define brevemente los elementos que componen el VACM.
PROBLEMAS
6 1 . SNMPvl define un tipo de datos conocidos como calibrador {gauge) e in
cluye la siguiente explicacin de la semntica de este tipo:
Este tipo representa un entero no negativo, que puede aumentar o disminuir,
pero que se queda fijo al alcanzar un valor mximo. Este estndar especifica
un valor mximo de 232 - 1 (4294967295 decimal) para calibradores.
Desgraciadamente, la expresin quedarse fjo no se define, y esto ha dado
como resultado dos interpretaciones. El estndar SNMPv2 aclaraba la ambi
gedad con la siguiente definicin:
El valor de un calibrador llega al mximo cuando la informacin que se est
modelando sea mayor o igual que ese valor mximo; si la informacin que se
est modelando posteriormente disminuye por debajo de dicho valor mximo,
tambin disminuye el calibrador.
a ) Cul es la interpretacin alternativa?
b) Comenta los pros y los contra de las dos interpretaciones.
6 2 . En SNMPvl, cualquier objeto en una MIB tiene una categora de acceso MIB,
que puede asignarse a uno de los siguientes valores: slo lectura, slo escritu
ra y no accesible. Con una operacin Get o Trap se lleva a cabo una lectura, y
con una operacin Set se lleva a cabo escritura. Para slo escritura, el objeto
puede estar disponible para las operaciones Get y Trap, pero es dependiente de
la implementacin. La categora de acceso MIB especifica el acceso mximo
permitido para un objeto, pero en la herramienta de comunidad de SNMPvl,
el modo de acceso puede restringir ms este acceso para un perfil de comuni
dad dado. En la siguiente tabla, rellena cada entrada para mostrar el acceso
permitido.
www.FreeLibros.org
300 Fundamentos de seguridad en redes. Aplicaciones y estndares
Categora
d e Acceso MIB
Modo d e Acceso SNMP
SLO LECTURA SLO ESCRITURA
Slo lectura
Lectura/escritura
Slo escritura
No accesible
s a a) El RFC 2574 afirma que para un motor no autoritatvo, los valores de
msgAuthoritatveEngineBoots y msgAuthoritatveEngineTime en la cabe
cera de un mensaje saliente se establecen slo si el mensaje ha de ser au
tentificado por el receptor autoritatvo. A qu se debe esta restriccin?
b) Sin embargo, para un mensaje de respuesta de un motor autoritatvo, los
valores de msgAuthoritatveEngineBoots y msgAuthoritatveEngineTime
en la cabecera de un mensaje saliente siempre se establecen. Por qu?
&4 El RFC 2574 especfica que la sincronizacin del reloj (actualizacin del reloj
local basada en valores entrantes) se produce antes de la verificacin de la ven
tana de tiempo (comprueba la validez temporal del mensaje entrante). Esto
significa que un motor no autoritatvo puede actualizar su nocin del reloj del
motor autoritatvo si el mensaje recibido es autntico, incluso si el mensaje no
est dentro de la ventana de tiempo. Desde la publicacin del RFC, ha habido
una discusin continua al respecto en la lista de correo SNMPv3, pero por el
momento parece que lo estipulado en el estndar no va a cambiar. Es til ob
servar las implicaciones de este hecho. Dadas las siguientes definiciones:
MAEB = msgAuthoritatveEngineBoots
MAET = msgAuthoritatveEngineTime
SEB = nocin local de snmpEngineBoots para el motor autoritatvo remoto
SET = nocin local de snmpEngineTime para el motor autoritatvo remoto
LRET = latestReceivedEngineTime
Ahora, imagina que un motor autoritatvo recibe un mensaje
(MAEB = SEB) Y [LRET < MAET < (SET -150)]
Luego las condiciones son correctas para una actualizacin de reloj, por lo que
se lleva a cabo:
SET := MAET; LRET := MAET
Ahora, en la comprobacin de la ventana de tiempo, tenemos
(MAEB = SEB) Y (MAET = SET)
por lo que afirmamos que el mensaje es vlido en trminos de tiempo. Supn,
sin embargo, que hemos hecho primero la comprobacin de la ventana de
tiempo. En trminos de tiempo, habramos considerado el mensaje vlido o
no vlido?
www.FreeLibros.org
Captulo 8 / Seguridad en la gestin de redes 301
8L5. En la versin original publicada de la especificacin USM (RFC 2274), que
trata los procedimientos de sincronizacin de reloj y de verificacin de la ven
tana de tiempo, se hace el siguiente comentario: Obsrvese que este procedi
miento no permite la sincronizacin automtica de tiempo si el motor SNMP
no autoritativo tiene una situacin real de fuera de sincronizacin, donde el
motor SNMP autoritativo va a ms de 150 segundos por detrs del motor
SNMP no autoritativo. Esta afirmacin se retir de la versin revisada (RFC
2574) despus de que su autor indicara al grupo de trabajo que la afirmacin
no es siempre cierta. Usando el ejemplo del Problema 8.4, demuestra que di
cha afirmacin no es siempre verdadera.
&& SNMPv3 asume que hay algn medio seguro de distribuir claves localizadas a
sistemas autentificados (agentes). Esta distribucin segura va ms all del m
bito de SNMPv3; puede ser manual o mediante otro protocolo seguro. Una vez
que se ha entregado a un agente una clave inicial (o pareja de claves para au
tentificacin y privacidad), SNMPv3 proporciona un mecanismo para actuali
zar de forma segura las claves. Es conveniente que las claves se camben de
vez en cuando para aumentar la seguridad. Un usuario, por s mismo, podra
iniciar el proceso de cambio de clave solicitando y proporcionando una nueva
contrasea. De otro modo, el sistema de gestin de red o NMS podra iniciar
el proceso solicitando una nueva contrasea. En cualquier caso, la clave de
usuario en el NMS se actualiza. El NMS puede, despus, calcular una clave
localizada para cada agente de la comunicacin. Luego, el NMS debe comu
nicarse de forma segura con cada agente para hacer que actualicen sus claves
localizadas. Es obvio que el NMS no puede simplemente enviar la clave en
texto claro por la red. Se presentan dos opciones:
Cifrar la nueva clave usando la clave antigua como clave de cifrado.
Usar algn tipo de funcin unidireccional para producir un valor a partir de
la clave antigua. Aplicar un OR exclusivo a este valor y la nueva clave y en
viar el resultado al agente. El agente puede luego aplicar un XOR al resul
tado entrante con la misma funcin aplicada a la clave antigua para produ
cir la clave nueva.
SNMPv3 utiliza una variante del segundo mtodo. Cul es la ventaja de este
enfoque con respecto al primero?
&7. El enfoque de SNMPv3 implica el uso de un objeto KeyChange en la MIB del
sistema meta. Una entidad principal remota o NMS fija este objeto, que luego
usa automticamente el agente para actualizar la clave correspondiente. El al
goritmo ahora tiene dos fases, una tiene lugar en el motor solicitante y otra en
el motor agente remoto.
El proceso empieza cuando un solicitante desea actualizar una clave existente
keyOld a un nuevo valor keyNew. El solicitante realiza los siguientes pasos:
L Generar un valor aleatorio (randorr) a partir de un generador de nmeros
pseudoaleatorios o un generador de nmeros aleatorios.
Z Calcular
digest = Hash(key01d || random)
www.FreeLibros.org
302 Fundamentos de seguridad en redes. Aplicaciones y estndares
donde Hash es MD5 o SHA-1, dependiendo de si se desea una clave de
16 octetos o de 20, y el smbolo || representa concatenacin.
3. Calcular
delta = dgest 0 keyNew
protocolKeyChange = (random || delta)
donde 0 es la operacin OR exclusivo.
4 El valor protocolKeyChange luego se enva al agente en un comando Set
para actualizar una instancia de objeto KeyChange en la MIB del agente.
Qu debe hacer el agente con el valor entrante para actualizar la clave?
&& Un procedimiento ms sencillo que el explicado en el problema anterior sera
aplicar un OR exclusivo a keyOld y keyNew y transmitir ese valor. El recep
tor entonces toma el XOR del valor recibido y keyOld para producir keyNew.
Como el atacante no conoce keyOld, no puede deducir el valor de keyNew.
Cules son las ventajas de usar el nmero aleatorio y la funcin hash unidi
reccional segura del Problema 8.7 en comparacin con este enfoque?
www.FreeLibros.org
P A R T E III
SEGURI DAD
DE LOS SI STEMAS
CONTENIDO DE LA TERCERA PARTE
L
a tercera parte de este libro trata aspectos sobre la seguridad de los sistemas, que inclu
yen las amenazas de intrusos y virus y sus correspondientes contramedidas, as como el
uso de cortafuegos y sistemas confiables.
G U A PARA LA TERCERA PARTE
CAPTULO 9. INTRUSOS
El Captulo 9 abarca una variedad de amenazas de acceso a la informacin y a los ser
vicios por parte de los hackers, que se benefician de las vulnerabilidades que presentan
los sistemas de computadores conectados en red. El captulo empieza con una descrip
cin de los tipos de ataques que los usuarios no autorizados, o intrusos, pueden llevar a
cabo, y analiza distintos enfoques para la prevencin y la deteccin. Tambin cubre el
aspecto relacionado con la gestin de claves.
CAPTULO 10. SOFTWARE DAINO
En el Captulo 10 se observan las amenazas de software a los sistemas, haciendo espe
cial hincapi en los virus y los gusanos. El captulo empieza con un estudio de distintos
tipos de software daino, tratando con ms detalle la naturaleza de los virus y los gusa
nos. El resto del captulo se dedica a las contramedidas correspondientes.
CAPTULO 11. CORTAFUEGOS
Un enfoque estndar para la proteccin de equipos locales frente a amenazas externas lo
constituye el uso de cortafuegos. En el Captulo 11 se presentan los principios del dise
o de los cortafuegos y se observan las tcnicas especficas. Este captulo tambin cu
bre el aspecto relacionado de los sistemas confiables.
www.FreeLibros.org
www.FreeLibros.org
C A P T U L O 9
Intrusos
9.1. Intrusos
Tcnicas de intrusin
9.2. La deteccin de intrusos
Registros de auditora
Deteccin estadstica de anomalas
Deteccin de la int ru si n basada en reglas
La falacia de la tasa base
Deteccin dist ribuida de la intrusin
H o n e y p o t s
Formato de intercambio de deteccin de intrusos
9.3. Gestin de contraseas
Proteccin de contraseas
Estrategias de seleccin de contraseas
9.4. Bibliografa y sitios web recomendados
9.5. Trminos clave, preguntas de repaso y problemas
Trminos clave
Preguntas de repaso
Problemas
Apndice 9A La falacia de la tasa base
Probabilidad condicional e independencia
El teorema de Bayes
La falacia de la tasa base demostrada
www.FreeLibros.org
306 Fundamentos de seguridad en redes. Aplicaciones y estndares
Estaban de acuerdo en que Graham debera hacer la prueba para Charles Mabledene.
Consista ni ms ni menos en que Dragn debera conseguir el cdigo de Stem. Esto se
ra porsible s l tena el enchufe en Utting que deca tener. Slo la lealtad al Centro
de Mosc lo evitara. S l consegua la clave del cdigo demostrara su lealtad a la
Central londinense ms all de cualquier duda.
Hablar cea extraas, R u t h R e n d e l l
U
n problema de seguridad significativo para los sistemas en red es el acceso hos
til, o al menos no autorizado, por parte de usuarios o soware. La entrada ilegal
de usuarios puede adoptar la forma de identificacin no aut