Modulo de Criptografia PDF

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD
Escuela de Ciencias Bsicas, Tecnologa e ingeniera

Esp. Seguridad InformticaCriptografa:233011
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BSICAS E INGENIERA
CRIPTOGRAFA
JORGE IVN MORALES SALAZAR
Acreditador
ING, HAROLD EMILIO CABRERA MEZA
Medelln
Julio de 2013

ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO

El presente mdulo fue diseado y apoyado con material pblicado en Internet en el
ao 2013 por el Ing. Jorge Ivn Morales, el Ing. Morales es Ingeniero de Sistemas, y
especialista en Seguridad Informtica, se ha desempeado como programador y
asesor en seguridad informticaen diversas empresas de tecnologa en Colombia,
actualmente trabaja como desarrollador y asesor de ciberseguridad en la ciudad de
Medelln.

INTRODUCCIN
Los numerosos riesgos inmersos no solo en la gran red de redes, Internet, sino en las
mismas redes domsticas y/o empresariales, hacen necesario adoptar mecanismo de
proteccin para garantizar en la medida de lo posible, la confidencialidad de la
informacin, uno de los tres grandes pilares de la seguridad de la informacin.
Una de las medidas que se pueden adoptar es el empleo la criptografa, herramienta
esta quepermite evitar que cuando un intruso intercepte de alguna forma los datos de
una vctima, este no pueda leer la informacin para poderla manipular posteriormente
de acuerdo con su conveniencia.
En la primera parte del curso se har una introduccin en losconceptos de criptografa
necesarios para entender cmo se aplica a la proteccinde las comunicaciones.
El objetivo principal de la criptografa es el envo/intercambio de informacin mediante
un modelo de seguridad tal, que solo permita ser ledo por aquellos usuarios a los que
solo se autoriza esta accin (proceso este que es conocido como confidencialidad de
la informacin).
En virtud de lo anteriormente expuesto, se hace evidente el uso de tcnicas
criptogrficas para prevenir algunas faltas de seguridad en un sistema de informacin.
Por lo tanto, la seguridad en general debe ser considerada como un aspecto de gran
importancia en cualquier organizacin que trabaje con TICs. Es por esto que se dice
que el hecho que gran parte de actividades humanas sea cada vez ms
dependiente de los sistemas computarizados hace que la seguridad juegue un papel
importante.

INDICE DE CONTENIDO
PRIMERA UNIDAD: INTRODUCCIN A LA CRIPTOGRAFA1
Captulo 1: Conceptos bsicos de criptografa
Leccin 1: Criptografa de clave simtrica
Leccin 2: Criptografa de clave pblica
Leccin 3: Infraestructura de clave pblica (PKI)
Leccin 4: Sistemas de autenticacin
11
Leccin 5: Proteccin del nivel de red: IPsec
14
Captulo 2: Mtodos de Autenticacin
18
Leccin 6: Firmas Digitales. Funciones Resumen
19
Leccin 7: Autenticacin de Dispositivos
23
Leccin 8: Autenticacin de Usuario Mediante Contrasea
30
Leccin 9: Ataques Mediante Diccionario
33
Leccin 10: Estenografa
35
Captulo 3: Comunicacin segura
38
Leccin 11: Autenticidad
39
Leccin 12: Confidencialidad
41
Leccin 13: Integridad
44
Leccin 14: No repudio
54

Leccin 15: Protocolos Seguros
56
SEGUNDA UNIDAD: APLICACIONES SEGURAS
58
Captulo 4: El protocolo SSH
61
Leccin 16: Caractersticas del protocolo SSH
62
Leccin 17:Tneles a nivel de transporte
64
Leccin 18:La capa de transporte SSH
66
Leccin 19:Ataques contra el protocolo SSH
67
Leccin 20: Aplicaciones que utilizan el protocolo SSH
69
Captulo 5: Correo electrnico seguro
71
Leccin 21: Seguridad en el correo electrnico
72
Leccin 22: Autenticacin de mensaje
74
Leccin 23: Compatibilidad con los sistemas de correo no seguro
76
Leccin 24: S/MIME
78
Leccin 25: PGP y OpenPGP
91
Captulo 6: Proteccin del nivel de transporte y Redes privadas virtuales
103
Leccin 26: Caractersticas del protocolo SSL/TLS
104
Leccin 27: El transporte seguro SSL/TLS
107
Leccin 28: Ataques contra el protocolo SSL/TLS
108
Leccin 29: Aplicaciones que utilizan SSL/TLS
110
Leccin 30: Definicin, tipos y configuraciones de VPN
111

LISTADO DE TABLAS
Tabla 1. Comparacin de mtodos biomtricos.
24

LISTADO DE GRFICOS Y FIGURAS
Figura 1: Proceso de cifrado y descifrado simtrico.

Figura 2: Proceso de cifrado y descifrado asimtrico.
4
6
Figura 3: Infraestructura de clave pblica PKI.
Figura 4: Esquema muestra una implementacin tpica donde la autenticacin de los

usuarios que ingresan al sistema se realiza contemplando dos factores de seguridad. 11
Figura 5: Flujo del protocolo de autenticacin.
14
Figura 6: Proceso de firma digital.
20
Figura 7: Ejemplo de proceso para garantizar la confidencialidad.
42
Figura 8: Esquema de firma de un mensaje o documento.
54
Figura 9: Modelo de comunicacin con tnles SSH.
65
Figura 10: Estructura de la capa de transporte SSH.
66
Figura 11: Escenario tpico S/MIME.
89
Figura 12: Modelo de confianza PGP.
96
Figura 13: Esquema de sesin con certificados SSL.
104
Figura 14: Modelo TCP/IP Protocolo SSL/TLS.
107
Figura 15: Esquema de conectividad con VPN.
113

UNIDAD 1
Nombre de la Unidad
Introduccin
Introduccin a la criptografa
La criptografa es la herramienta que permite al usuario
proteger las comunicaciones (intercambio de datos) de tal
suerte que aunque los intrusos puedan interceptar las
comunicaciones, no les ser posible manipular o falsificar
los datos transmitidos.
Su objetivo principal es el intercambio de informacin bajo
unos criterios de seguridad aplicando una transformacin,
conocida como cifrado, a la informacin quequeremos
mantener en secreto.
Aunque un atacante consiga ver los datos que se estn
enviando,no le ser posible leerlos. Slo el
destinatariolegtimo
ser
capaz
de
realizar
la
transformacin inversa y recuperar los datosoriginales.
Es imprescindible que durante el proceso no se permita
que un impostor pueda suplantar al destinatario de la
informacin para que pueda leer la informacin.
Justificacin
Los numerosos ataques que hoy en da se ciernen contra

las redes de datos y concretamente sobre el intercambio
de comunicaciones, hace necesario el poder garantizar la
autenticidad en las comunicaciones a travs de tcnicas
criptogrficas.
Esta proteccin se puedeobtener en las distintas capas de
las comunicaciones. A nivelred por ejemplo, el mecanismo
principal en un entorno de interconexin basado en IP
esel conjunto de protocolos conocido como IPsec.
As mismo, en la capa de transporte por ejemplo, se
puede llevar a cabo una proteccin mediante familia de
protocolos SSL/TLS/WTLS.
Intencionalidades
Formativas
Los conceptos presentados en la presente unidad

didctica deben permitir alestudiante tener claros los
conceptos bsicos de la criptografa para poder abordar
con criterios suficientes, los conceptos abordados con
posterioridad en las unidades siguientes.

As mismo, ser factor clave de xito, el lograr que el

estudiante identifique, diferencie y defina con claridad los
tres pilares de la seguridad de la informacin (integridad,
disponibilidad y confidencialidad).
De acuerdo con lo anterior, tambin se busca mediante el
proceso de enseanza, el lograr que el estudiante que
aborda estas temticas, conozca mtodos de
autenticacin y posibles ataques a los mismos, lo anterior,
con el objeto de reconocer la necesidad de los sistemas
de autentificacin, qu tcnicasconcretas utilizan y cmo
estas tcnicas permiten contrarrestar los intentosde
suplantacin.
Captulo 1
Leccin 1
Leccin 2
Leccin 3
Leccin 4
Leccin 5
Captulo 2
Leccin 6
Leccin 7
Leccin 8
Leccin 9
Leccin 10
Captulo 3
Leccin 11
Leccin 12
Leccin 13
Leccin 14
Leccin 15
Conceptos bsicos de criptografa

Criptografa de clave simtrica
Criptografa de clave pblica
Infraestructura de clave pblica (PKI)
Sistemas de autenticacin
Proteccin del nivel de red: IPsec
Mtodos de Autenticacin
Firmas Digitales. Funciones Resumen
Autenticacin de Dispositivos
Autenticacin de Usuario Mediante Contrasea
Ataques Mediante Diccionario
Estenografa
Comunicacin segura
Autenticidad
Confidencialidad
Integridad
No repudio
Protocolos Seguros

CAPITULO 1: CONCEPTOS BSICOS DE CRIPTOGRAFA

Introduccin
El empleo de la criptografa no es un asunto de la poca moderna, sta ya era
utilizada en el antiguo Egipto y a travs de los siglos se ha seguido utilizando y ha
sufrido una evolucin importante hasta el punto de ser una herramienta de
seguridad imprescindible en el intercambio de datos entre dos o ms actores.
Esta misma herramienta es uno de los principales obstculos que los atacantes
deberan sortear durante el proceso de intrusin en un sistema.
Desafortunadamente, aunque es una herramienta que se encuentra a disposicin
ya sea de manera comercial o free, los usuarios pocas veces hacen uso o buen
uso de ella.
El presente captulo le permitir al estudiante abordar los conceptos bsicos
esctucturales de criptografa para abordar posteriormente este tema de una
manera que permita al estudiante adquirir conocimientos slidos a la hora de
implemntar una solucin criptogrfica en una organizacin o en su vida diaria.

Leccin 1:Criptografa de clave simtrica

Inventada por los matemticos Whit Diffie y Martin Hellman en 1976 se ha
convertido en la base de la criptografamoderna.
Se caracteriza por utilizar dos claves complementarias llamadas clave privada y
clave pblica. Lo cifrado con la clave privada necesita de su correspondiente clave
pblica para ser descifrado. As mismo, lo cifrado con la clave pblica slo puede
ser descifrado con su correspondiente clave privada.
Figura 1: Proceso de
http://2.bp.blogspot.com
cifrado
descifrado
simtrico.
Fuente:
Las claves privadas deben ser conocidas solo por su propietario, mientras que las
correspondientes claves pblicas pueden ser dadas a conocer sin restriccin
alguna. Si Andrea quiere enviar a Bruno un mensaje de forma que slo l pueda
entenderlo, lo codificar con la clave pblica de Bruno. Bruno utilizar su clave
privada, para poderlo leer. Otroprobableempleo del sistema es garantizar la
identidad del remitente. Si Andrea enva a Bruno un mensaje codificado con la
clave privada de ella, Bruno necesitar la clave pblica de Andrea para descifrarlo.
Es posible combinar ambos: Andrea puede enviar a Bruno un mensaje cifrado dos
veces, con la clave privada de ella y con la clave pblica de Bruno. As se
consigue garantizar la identidad del emisor y del receptor.
El xito de la seguridad del sistema se encuentra en mantener en secreto la clave
privada. Cuando los participantes en una comunicacin quieren intercambiarse
mensajes confidenciales, tienen que escoger un clave secreta y usarla para cifrar
4

los mensajes. Entonces, pueden enviar estos mensajes por cualquier canal de
comunicacin, con la confianza que, aun que el canal sea inseguro y susceptible
de ser monitoreado por terceros, ningn espa ser capaz de interpretarlos.
Profundizacin Leccin 1: El estudiante debe profundizar en cada leccin

que sea vista para adquirir conocimientos a fondo y lograr un aprendizaje
ptimo.
Reingeniera y seguridad en el ciberespacio - J. A. Calle Guglieri Hall
Link:
http://books.google.com.co/books?id=qB3P2GuD3EsC&pg=PA48&dq=cifrad
o+simetrico&hl=es&sa=X&ei=KEDUsuDHaamygHC2IHoDA&ved=0CFUQ6AEwBQ#v=onepage&q=cifrado
%20simetrico&f=false

Leccin 2: Criptografa de clave pblica

Si bien es cierto que uno de los problemas de la criptografa de clave simtrica es
el de la distribucin de las claves. Este problema se ve solventado con los
algoritmos de clave pblica, tambin llamados de clave asimtrica.
La criptografa asimtrica es la ms moderna y es el futuro del comerio
electrnico, como ejemplos ms reconocidos se pueden citar RSA y ECC.
A diferencia de las claves simtricas donde el emisor y el receptor usan la misma
clave; en las claves pblicas asimtricas el emisor y el receptor crean un par de
claves que consisten en una clave privada y una pblica.
Para lo cual es necesario realizar un requerimiento de certificado digital por cada
elemento que interviene en la trasmisin.
Tanto el emisor como el receptor deben custodiar con sumo cuidado su
correspondiente clave para evitar que sea legible a personas no autorizadas.
En ese orden de ideas, tanto el emisor como el receptor tienen su correspondiente
clave pblica, la cual puede puede y debe tener cualquier persona que desee
enviar documentos seguros a sus dueos.
Figura 2: Proceso de cifrado y descifrado asimtrico (clave pblica).

Fuente: http:// galeon.com

Una autoridad certificadora (CA, certification authority) es una organizacin que

emite certificados de llave pblica, conceptualmente, parecen tarjetas
bibliogrficas con firmacriptogrfica. Los certificados, firmados con las llaves
pblicas de la autoridad certificadora contienen el nombre de una persona, su llave
pblica, nmero de serie y otra informacin. El certificado comprueba que una
llave pblica especfica es propiedad de un individuo u organizacin en particular.
Existen muchas formas en que las autoridades certificadoras pueden ofrecer su
servicio:
CA interna
Una organizacin puede operar una CA para certificar a sus propios empleados,
sus puestos y sus niveles de autoridad. Tal jerarqua de certificacin podra
emplearse para controlar el acceso a los recursos o al flujo de informacin
internos. Por ejemplo,cada empleado de una organizacin podra crear una llave y
recibir un certificado para ella.
Adems, dicho certificado sera enviado a los sistemas a los que deba tener
acceso. Los computadores en toda la organizacin podran entonces decidir si
otorgan o no acceso a un empleado basados en la certificacin de su llave. De
esta forma, la empresa evita la necesidad de distribuir una lista de control de
acceso y archivos de claves de acceso a todos sus computadores.
CA externa de empleados
Una empresa podra contratar a una compaa externa para que le d servicios de
certificacin para sus empleados, de la misma forma en que podra contratar a un
laboratorio fotogrfico para crear tarjetas de identificacin.
CA externa de clientes
Una empresa podra contratar a una compaa externa para operar una autoridad
certificadora para sus clientes actuales o potenciales. Al confiar en las prcticas de
certificacin de una compaa externa, la empresa se ahorrara el costo de crear
sus propios procedimientos.
CA confiable de terceros
Una compaa o un gobierno pueden operar una CA que relacione llaves pblicas
con los nombres legales de individuos y empresas. Esa CA puede utilizarse para
permitir a personas sin relacin anterior establecer su identidad y participar en
transacciones legales.
Para utilizar los certificados emitidos por una CA es necesario tener una copia de
su llave pblica. Hoy en da, estas llaves se incluyen en programas como
navegadores y sistemas operativos. El usuario puede agregar otras llaves pblicas
de autoridades certificadoras manualmente.
7

Es evidente que las CA que no distribuyen sus llaves pblicas estn en

desventaja.
Revocacin
Adems de emitir certificados, las CA necesitan alguna forma de revocarlos, por lo
siguiente:
La llave privada del tenedor puede haber sido interceptada o violada.

La CA puede descubrir que ha emitido el certificado a la persona o entidad
incorrecta .
El certificado puede haber sido emitido para dar acceso a un servicio
especfico y el individuo puede haber perdido su autorizacin para utilizarlo.
Los sistemas de la CA pueden haber sido violados de forma tal que alguien
tenga lacapacidad de emitir certificados falsos.
Se ha propuesto una forma de manejar las revocaciones con las llamadas listas de
revocacin de certificados (CRL, certificate revocation list). Una CRL es una lista
de todos los certificados revocados por la CA y que an no expiran por otras
razones. Idealmente, una CA emite una CRL a intervalos regulares. Adems de
listar los certificados revocados, la CRL especfica durante cunto tiempo es vlida
y dnde obtener la siguiente CRL.
En teora, las CRL son interesantes por que permiten a los computadores que no
estn conectados a una red determinar si un certificado es vlido o si se ha
revocado. No obstante, en la prctica tienen varios problemas:
Tienden a crecer con rapidez.

Existe un periodo en que un certificado aparenta ser vlido, sin serlo, entre
el momento en que se revoca y en el que se distribuye la nueva CRL.
La informacin contenida en las CRL puede emplearse para analizar el
trfico. En vez de CRL, la mayora de las CA tal vez utilizar verificacin
en tiempo real mediante bases de datos en lnea conectadas a una red;
digamos Internet. Tales sistemas eliminan limpiamente los problemas de las
CRL, aunque necesitan una red confiable y que este disponible.

Leccin 3: Infraestructura de clave pblica (PKI)

De acuerdo con lo tratado hasta el momento, la criptografa de clave pblica
soluciona el problema del intercambio de claves, utilizando las claves pblicas de
los participantes en la comunicacin (intercambio de datos). Sin embargo, existe
otro inconveniente; si alguien afirma ser A y su clave pblica es kpub, cmo
podemos saber que realmente kpub es la clave pblica de A?
Este aspecto se logra evidenciar dado que un atacante Z puede generar su
pardeclaves(k, k)y afirmar que es A y que su clave pblicaesk.
En virtud del escenario anteriormente planteado, una probable solucin a este
problema es la existencia de una entidad de confianza que certifique que,
indudablemente, las claves pblicas pertenecen a sus aparentes propietarios.
Dicha entidad puede dar fe mediante un documento que testifique que la clave
pblica de A es kpubA, y publicarlo para que todos los usuarios lo sepan. Este tipo
de documento se llama certificado de clave pblica o certificado digital, y es la
base de lo que se conoce como infraestructura de clave pblica.
Figura 3: Infraestructura
http://www.chipychip.com
de
clave
pblica
PKI.
Fuente:


ptimo.
Importancia de contar con un servicio de sellado digital de tiempo en una
PKI Javier Daz, Nicols Macia, La Molinari, Paula Venosa, Alejandro
Sabolansky
Link:http://sedici.unlp.edu.ar/bitstream/handle/10915/19430/Documento_co
mpleto.pdf?sequence=1
Firma digital. Certificacin digital. Entidades de Certificacin Antonio

Villaln Huerta
Link:http://shutdown.es/alfa56.pdf
10

Leccin 4: Sistemas de autenticacin

Este es talvez uno de los servicios de seguridad ms importantes dado que
permite dar un grado de fiabilidad an mayor al no permitir que se haya
falsificado la comunicacin.
Son varios los tipos de autenticacin, en este sentido, podramos mencionar dos
tipos de autenticacin:
El primer tipo, es la autenticacin de mensaje o autenticacin de origen de datos
que permite confirmar que el originador de un mensaje es autntico, es decir, que
el mensaje no ha sido generado por un tercero que quiere suplantar al verdadero
originador del mensaje. Cabe resaltar que adicionalmente, la autenticacin de
mensaje proporciona implcitamente el servicio de integridad de datos, que permite
confirmar que nadie ha modificado un mensaje enviado por el verdadero
originador.
El segundo tipo, es la autenticacin de entidad permite confirmar la identificacin
de un participante en una comunicacin, es decir, que no se trata de un tercero
que dice ser el originador.
Figura 4: Esquema muestra una implementacin tpica donde la

autenticacin de los usuarios que ingresan al sistema se realiza
contemplando dos factores de seguridad. Fuente: http://www.hardkey.net
11

Dentro de la autenticacin de mensaje existen dos grupos de tcnicas:
Los cdigos de autenticacin de mensaje o MAC, basados en claves

simtricas.
Las firmas digitales, que se basan en la criptografa de clave pblica.
En el prximo captulo nos adentraremos ms en detalle en el tema de las firmas

digitales y enotros aspectos relevantes a este tema como lo son por ejemplo, la
autenticacin de dispositivos, autenticacin de usuario mediante contrasea, etc.
Por otra parte y no menos importante, es el tema de las contraseas como uno de
los sistemas ms bsicos de autenticacin en una organizacin, este aspecto
merece tener un apartado dentro de nuestro objeto de estudio dado que es
importante que como usuarios o administradores de sistemas tengamos algunas o
todas de las siguientes consideraciones en cuenta:
Las polticas de contraseas son una de las polticas ms importantes, ya que
comunmente, las contraseas constituyen la primera y en algunos casos, tal vezla
nica manera de autenticacin y, por lo tanto hay que decirlo, la nica lnea de
defensa contra ataques (desafortunadamente el tema de presupuesto y/o
desconocimiento por parte de los admisnitradores de plataforma o de seguridad en
la organizaciones hace que este caso se de muy frecuentemente). stas
establecen quin asignar la contrasea inicial (una buena prctica es la de
obligaral usuario a cambiarla en su primer login), qu longitud de caracteres
debe tener (aunque sea molesto o incomodo para los usuarios, es recomendable
emplear un mnimo de 12 caracateres), a qu formato deber apegarse
(importante hacer la configuracin para que sea necesario emplear un formato
alfanumerico), cmo ser comunicada, etc.
Ejemplos:
Los usuarios no deben construir contraseas idnticas o muy parecidas a

contraseas anteriores.
Todas las contraseas elegidas por los usuarios deben ser difciles de
identificar. No deben ser utilizadas palabras que aparezcan en el
diccionario, secuencias conocidas de caracteres, datos personales ni
acrnimos.
Debera ser prohibido que los usuarios construyan contraseas compuestas
de algunos caracteres constantes y otros que cambien de manera
predecible y sean fciles de identificar.
La longitud de una contrasea deber siempre ser verificada de manera
automtica al ser construida por el usuario. Todas las contraseas debern
contar con al menos 12 caracteres.
12


ptimo.
Avances en criptologa y seguridad de la informacin - Benjamn Ramos
Alvarez
Link:http://books.google.com.co/books?id=ibSu6896I_YC&pg=PA475&dq=
Sistemas+de+autenticacin&hl=es&sa=X&ei=6hkFUuOrGa7iyAHxrYG4BQ&
ved=0CFoQ6AEwCTge#v=onepage&q=Sistemas%20de%20autenticacin&f
=false
13

Leccin 5: Proteccin del nivel de red: IPsec

IPSec es uno de los protocolos ms poderosos que existen, ya que no tan solo
encripta datos, si no que tambin habilita autenticacin de cada usuario y cada
paquete de manera individual.
IPSec trata de remediar algunas falencias de IP, tales como proteccin de los
datos transferidos y garanta de que el emisor del paquete sea el que dice el
paquete IP. Si bien estos servicios son distintos, IPSec da soporte a ambos de una
manera uniforme.
IPSec provee confidencialidad, integridad, autenticidad y proteccin a repeticiones
mediante dos protocolos, que son Authentication Protocol (AH) y Encapsulated
Security Payload (ESP).
Figura
5:
Flujo
http://pic.dhe.ibm.com
del
protocolo
de
autenticacin.
Fuente:
14

Por confidencialidad se entiende que los datos transferidos sean slo entendidos
por los participantes de la sesin.
Por integridad se entiende que los datos no sean modificados en el trayecto de la
comunicacin.
Por autenticidad se entiende por la validacin de remitente de los datos.
Por proteccin a repeticiones se entiende que una sesin no pueda ser grabada y
repetida a no ser que se tenga autorizacin para hacerlo.
AH provee autenticacin, integridad y proteccin a repeticiones pero no
confidencialidad. La diferencia ms importante con ESP es que AH protege partes
del header IP, como las direcciones de origen y destino.
ESP provee autenticacin, integridad, proteccin a repeticiones y confidencialidad
de los datos, protegiendo el paquete entero que sigue al header.
AH sigue al header IP y contiene diseminaciones criptogrficas tanto en los datos
como en la informacin de identificacin. Las diseminaciones pueden tambin
cubrir las partes invariantes del header IP.
El header de ESP permite rescribir la carga en una forma encriptada. Como no
considera los campos del header IP, no garantiza nada sobre el mismo, slo la
carga.
Una divisin de la funcionalidad de IPSec es aplicada dependiendo de dnde se
realiza la encapsulacin de los datos, si es la fuente original o un gateway:
El modo de transporte es utilizado por el host que genera los paquetes. En

este modo, los headers de seguridad son antepuestos a los de la capa de
transporte, antes de que el header IP sea incorporado al paquete. En otras
palabras, AH cubre el header TCP y algunos campos IP, mientras que ESP
cubre la encriptacin del header TCP y los datos, pero no incluye ningn
campo del header IP.
El modo de tnel es usado cuando el header IP entre extremos est ya
incluido en el paquete, y uno de los extremos de la conexin segura es un
gateway. En este modo, tanto AH como ESP cubren el paquete entero,
incluyendo el header IP entre los extremos, agregando al paquete un header
IP que cubre solamente el salto al otro extremo de la conexin segura, que,
por supuesto, puede estar a varios saltos del gateway.
Los enlaces seguros de IPSec son definidos en funcin de Security Associations

(SA). Cada SA est definido para un flujo unidireccional de datos y
generalmentede un punto nico a otro, cubriendo trfico distinguible por un
selector nico. Todo el trfico que fluye a travs de un SA es tratado de la misma
manera. Partes del trfico puede estar sujeto a varios SA, cada uno de los cuales
15

aplica cierta transformacin. Grupos de SA son denominados SA Bundles.

Paquetes entrantes pueden ser asignados a un SA especfico por los tres campos
definitorios: la direccin IP de destino, el ndice del parmetro de seguridad y el
protocolo de seguridad. El SPI puede ser considerado una cookie que es repartido
por el receptor del SA cuando los parmetros de la conexin son negociados. El
protocolo de seguridad debe ser AH o ESP. Como la direccin IP de destino es
parte de la tripleta antes mencionada, se garantiza que este valor sea nico.
Sin embargo, no es mencionado en las RFC (Request for Comments - "Peticin
De Comentarios" en espaol) que definen estos protocolos. Como en Transport
Adjacency, esto autenticara el paquete completo salvo algunos pocos campos del
header IP y tambin encriptara la carga. Cuando un header AH y ESP son
directamente aplicados como en esta manera, el orden de los header debe ser el
indicado. Es posible, en el modo de tnel, hacer una encapsulacin
arbitrariamente recursiva para que el orden no sea el especificado.
Un ejemplo de una herramienta de software libre que permite la implementacin
de IPSEC sobre Linux, que provee encriptacin y autenticacin en IP es
FreeSWAN. La Encriptacin Oportuna, permite la habilidad para configurar
FreeS/Wan gateways de tal manera que entre ellos negocie el establecimiento de
encriptacin, de forma dinmica sin coordinacin.
Es importante mencionar para finalizar este captulo, que en la arquitectura IPsec
(RFC 2401) se aaden servicios para proporcionar seguridad nteroperable, dealta
calidad, basada en criptografa tanto para IPv4 como para IPv6, que pueden ser
usados por los protocolos de niveles superiores (TCP, UDP, ICMP, etc.).
El conjunto de servicios de seguridad ofrecidos incluye:
Control de acceso
Integridad sin conexin
Autenticacin del origen de los datos
Proteccin antireplay (una forma de integrabilidad parcial de la secuencia)
Confidencialidad por encriptacin
Confidencialidad limitada del flujo de trfico
Estos servicios se implementan en lacapa IP, y ofrecen proteccin para este nivel
y/o los nivelessuperiores.
ptimo.
Request for Comments: 2401 S. Kent
Link: http://www.rfc-es.org/rfc/rfc2401-es.txt
16

CAPITULO 2: MTODOS DE AUTENTICACIN

Introduccin
La autenticacin puede ser entendida como cualquier mtodo que nos permita
comprobar de manera segura alguna caracterstica sobre un objeto. Dicha
caracterstica puede ser su origen, su integridad, su identidad, etc.
Dentro de los mtodos de autenticacin pueden ser tenidos en cuenta tres
grandes tipos:
Autentificacin de dispositivo: en este mtodo se trata de garantizar la
presencia de un dispositivo vlido. Este dispositivo puede estar solo o tratarse de
una llave electrnica que sustituye a la contrasea para identificar a un usuario.
Autentificacin de mensaje:el mecanismo ms representativo es la firma digital y
se presenta cuando queremos garantizar la procedencia de un mensaje conocido,
de forma que podamos asegurarnos de que no es una falsificacin.
17

Autentificacin de usuario mediante contrasea: en este ltimo mtodo se

trata de garantizar la presencia de un usuario legal en el sistema. El usuario
deber poseer una contrasea secreta que le permita identificarse.
Cabe menconar que la autenticacin de usuario por medio de alguna
caracterstica biomtrica, como pueden ser las huellas digitales, la retina, el iris, la
voz, etc., puede reducirse a un problema de autenticacin de dispositivo, solo que
el dispositivo en este caso es el propio usuario.
Leccin 6: Firmas Digitales. Funciones Resumen

La firma digital de un documento es el resultado de aplicar cierto algoritmo
matemtico, denominado funcin hash, a su contenido.
Tambin puede ser definida la firma digital comoel mtodo criptogrfico que
asegura la integridad de los mismos as como la identidad del remitente.
Recapitulando lo visto en apartados anteriores de este material, podemos definir
tres tipos bsicos de algoritmos criptogrficos:
Criptografa simtrica.
Criptografa asimtrica.
Funciones de Hash.
Combinando estos algoritmos, podemos obtener sistemas criptogrficos

complejos, que consigan ms o menos objetivos de los enunciados anteriormente.
As, podremos obtener sistemas de cifrado, de firmas digitales y de certificados
18

digitales.
La particularidad de la criptografa de clave pblica es que a partir de la clave
pblica es prcticamente imposible deducir la clave privada. Esto permite que
cualquiera que conozca la clave pblica de un usuario pueda usarla para cifrar
datos confidenciales, con la seguridad que solamente quien tenga la clave privada
correspondiente podr descifrarlos, y sin necesidad de acordar ninguna clave
secreta a travs de un canal seguro. El uso de las claves al revs (la privada para
cifrar y la pblica para descifrar) es la base de las firmas digitales.
Las firmas digitales proporcionan el servicio de autenticacin de mensaje. Los
llamados cdigos MAC tambin proporcionan este servicio, pero utilizando claves
secretas compartidas en lugar de claves pblicas.
En lo referente a su seguridad, un posible ataque contra las firmas digitales
consiste en hacer creer que el firmante ha calculado el hash con otro algoritmo (p.
ex. MD4 en lugar de MD5), y si este algoritmo es menos seguro que el original,
puede ser que el atacante sea capaz de obtener un mensaje diferente que de el
mismo hash con este otro algoritmo, de modo que la firma continuara siendo
vlida.
Para realizar esta funcin de identificacin del origen, se combina una funcin
hash con la criptografa de clave pblica. De esta manera se consigue lo que
llamamos una firma digital, que identifica inequvocamente al emisor.
En el siguiente grfico podremos observar de una manera ms sencilla el proceso
de firma difital descrito en los apartados inmediatamente anteriores.
19

Figura 6: Proceso de firma digital. Fuente: http://www.edukanda.es

Aparte de cifrar datos, existen algoritmos basados en tcnicas criptogrficas que
se usan para garantizar la autenticidad de los mensajes. Un tipo de algoritmos de
estas caractersticas son las llamadas funciones hash seguras, tambin conocidas
como funciones de resumen de mensaje (message digest, en ingls).
En general, podemos decir que una funcin hash nos permite obtener una cadena
de bits de longitud fija, relativamente corta, a partir de un mensaje de longitud
arbitraria:
H = h(M)
Para mensajes M iguales, la funcin h debe dar resmenes H iguales. Pero si dos
mensajes dan el mismo resumen H no deben ser necesariamente iguales.
Esto es as porque slo existe un conjunto limitado de posibles valores H, ya que
20

su longitud es fija, y en cambio puede haber muchos ms mensajes M (si la

longitud puede ser cualquiera, habr infinitos).
Para poderla aplicar en un sistema de autenticacin, la funcin h debe ser una
funcin hash segura.
Se entiende que una funcin hash o de resumen es segura si cumple las
siguientes condiciones:
Es unidireccional, es decir, si tenemos
H = h(M)
Es computacionalmente inviable encontrar M a partir del resumen H.
Es resistente a colisiones, es decir, dado un mensaje M cualquiera es
computacionalmente inviable encontrar un mensaje
M M tal que h (M) = h (M).
Para dificultar los ataques contra las funciones de resumen, por un lado los
algoritmos tienen que definir una relacin compleja entre los bits de entrada y cada
bit de salida. Por otro lado, los ataques por fuerza bruta se contrarrestan
alargando lo suficiente la longitud del resumen.
Por ejemplo, los algoritmos usados actualmente generan resmenes de 128 160
bits. Esto quiere decir que un atacante podra tener que probar del orden de 2 128 o
2160 mensajes de entrada para encontrar una colisin (es decir, un mensaje
distinto que diera el mismo resumen).
Dada la importancia y el inters que pudiese presentar por parte del estudiante
para el posible empleo de firmas digitales en sus documentos de la vida diaria, a
continuacin se muestra una lista de algunospaquetes de software que se
sujetan a consideracin para que si se quiere por parte del alumno, sean
revisados evaluados como prctica en su forma demo, gratuita o trial:
XolidoSign
Clicksign
Adobe Acrobat X Pro
DigiSigner
Secrefirmas
U-Sign PDF
Aloaha PDF Suite
eFactura Seteco
21


ptimo.
DISI 2009: Hashing Aleatorio: Firmas Digitales Seguras sin Resistencia a
Colisiones D. Hugo Krawczyk, IBM Research
Link: https://www.youtube.com/watch?v=xbCltk1Bzlo
22

Leccin 7: Autenticacin de Dispositivos

Autenticacin es el mtodo por el que demuestras de forma fiable que eres quien
dices ser. En un ejemplo en la vida cotidiana seria el equivalente a presentar tu
documento de identidad para demostrar que eres t.
En seguridad se considera que hay tres formas de autenticar un usuario o un
equipo, lgicamente si utilizas ms de una, la fiabilidad de esa autenticacin es
mucho mayor, por lo que se recomienda al menos utilizar dos de esas tres.
La primera idea que nos llega a la cabeza es el de la pareja usuario/contrasea
porque es el ms cmodo y el ms econmico. Sin embargo, veamos estos tres
tipos:
Algo que sabes
Es el mtodo mas conocido este realiza una pregunta y solo el usuario o equipo
que se quiere autenticar debe ser el nico capaz de responderla.
Algo que tienes
Este mtodo valda al usuario a travs de algn elemento al que solo ese usuario
debera tener acceso, algunos ejemplos son: una tarjeta inteligente, una usb, o un
certificado (normalmente es lo que hay en los anteriores). Estos medios conceden
la identidad al que lo posea.
Algo que eres
Debe ser una caracterstica intrnseca al usuario o equipo que quieres identificar, y
distintiva, es decir nica para cada usuario. Una huella dactilar en el caso de un
ser humano o una direccin MAC en el caso de una mquina. A continuacin
analizaremos este ltimo tipo que es el ms controversial en los ltimos aos.
A pesar de la importancia de la criptologa en cualquiera de los sistemas de
identificacin de usuarios, existen otra clase de sistemas en los que no se aplica
esta ciencia, o al menos su aplicacin es secundaria. Es ms, parece que en un
futuro no muy lejano estos sern los sistemas que se van a imponer en la mayora
de situaciones en las que se haga necesario autenticar un usuario: son ms
amigables para el usuario (no va a necesitar recordar passwords o nmeros de
identificacin complejos, y, como se suele decir, el usuario puede olvidar una
tarjeta de identificacin en casa, pero nunca se olvidar de su mano o su ojo) y
son mucho ms difciles de falsificar que una simple contrasea o una tarjeta
magntica; las principales razones por la que no se han impuesto ya en nuestros
dias es su elevado precio, fuera del alcance de muchas organizaciones, y su
dificultad de mantenimiento.
Estos sistemas son los denominados biomtricos, basados en caractersticas
fsicas del usuario a identificar. El reconocimiento de formas, la inteligencia
artificial y el aprendizaje son las ramas de la informtica que desempean el papel
23

ms importante en los sistemas de identificacin biomtricos; la criptologa se

limita aqu a un uso secundario, como el cifrado de una base de datos de patrones
retinales, o la transmisin de una huella dactilar entre un dispositivo analizador y
una base de datos. La autenticacin basada en caractersticas fsicas existe desde
que existe el hombre y, sin darnos cuenta, es la que ms utiliza cualquiera de
nosotros en su vida cotidiana: a diario identificamos a personas por los rasgos de
su cara o por su voz. Obviamente aqu el agente reconocedor lo tiene fcil porque
es una persona, pero en el modelo aplicable a redes o sistemas, el agente ha de
ser un dispositivo que, basndose en caractersticas del sujeto a identificar, le
permita o deniegue acceso a un determinado recurso.
Aunque la autenticacin de usuarios mediante mtodos biomtricos es posible
utilizando cualquier caracterstica nica y mesurable del individuo (esto incluye
desde la forma de teclear ante un computador hasta los patrones de ciertas venas,
pasando por el olor corporal), tradicionalmente ha estado basada en cinco grandes
grupos. En la siguente tabla se muestra una comparativa de sus rasgos ms
generales, que vamos a ver con ms detalle en los puntos siguientes:
Ojo - Iris
Ojo - Retina
Fiabilidad
Facilidad de
uso
Prevencin de
ataques
Aceptacin
Estabilidad
Identificacin y
autenticacin
Estndars
Muy alta
Media
Muy alta
Baja
Huellas
dactilares
Alta
Alta
Muy Alta
Muy alta
Alta
Alta
Media
Media
Media
Alta
Ambas
Media
Alta
Ambas
Media
Alta
Ambas
Alta
Media
Autenticacin
Muy alta
Media
Ambas
Alta
Media
Autenticacin
SVAPI
Interferencias
Gafas
Irritaciones
Artritis,
reumatismo ...
Instalaciones
nucleares,
servicios
mdicos,
centros
penitenciarios
Instalaciones
nucleares,
servicios
mdicos,
centros
penitenciarios
Firmas
fciles o
cambiantes
Industrial
Ruido,
resfriados ...
Utilizacin
ANSI/NIST,
FBI
Suciedad,
heridas,
asperezas ...
Polica,
industrial
Tabla
1.Comparacin
http://mmc.geofisica.unam.mx.
de
Geometra de
la mano
Alta
Alta
Escritura Firma
Alta
Alta
Alta
Alta
General
mtodos
Voz
Accesos
remotos en
bancos o bas
biomtricos.Fuente.
Los dispositivos biomtricos tienen tres partes principales; por un lado, disponen
de un mecanismo automtico que lee y captura una imagen digital o analgica de
la caracterstica a analizar. Adems disponen de una entidad para manejar
aspectos como la compresin, almacenamiento o comparacin de los datos
capturados con los guardados en una base de datos (que son considerados
vlidos), y tambin ofrecen una interfaz para las aplicaciones que los utilizan. El
proceso general de autenticacin sigue unos pasos comunes a todos los modelos
24

de autenticacin biomtrica: captura o lectura de los datos que el usuario a validar

presenta, extraccin de ciertas caractersticas de la muestra (por ejemplo, las
minucias de una huella dactilar), comparacin de tales caractersticas con las
guardadas en una base de datos, y decisin de si el usuario es vlido o no. Es en
esta decisin donde principalmente entran en juego las dos caractersticas bsicas
de la fiabilidad de todo sistema biomtrico (en general, de todo sistema de
autenticacin): las tasas de falso rechazo y de falsa aceptacin. Por tasa de falso
rechazo (False Rejection Rate, FRR) se entiende la probabilidad de que el sistema
de autenticacin rechaze a un usuario legtimo porque no es capaz de identificarlo
correctamente, y por tasa de falsa aceptacin (False Acceptance Rate, FAR) la
probabilidad de que el sistema autentique correctamente a un usuario ilegtimo;
evidentemente, una FRR alta provoca descontento entre los usuarios del sistema,
pero una FAR elevada genera un grave problema de seguridad: estamos
proporcionando acceso a un recurso a personal no autorizado a acceder a l.
Por ltimo, y antes de entrar ms a fondo con los esquemas de autenticacin
biomtrica clsicos, quizs es conveniente desmentir uno de los grandes mitos de
estos modelos: la vulnerabilidad a ataques de simulacin. En cualquier pelcula o
libro de espas que se precie, siempre se consigue engaara autenticadores
biomtricos para conseguir acceso a determinadas instalaciones mediante estos
ataques: se simula la parte del cuerpo a analizar mediante un modelo o incluso
utilizando rganos amputados a un cadver o al propio usuario vivo (crudamente,
se le corta una mano o un dedo, se le saca un ojo para conseguir que el sistema
permita la entrada).
Evidentemente, esto slo sucede en la ficcin: hoy en da cualquier sistema
biomtrico - con excepcin, quizs, de algunos modelos basados en voz de los
que hablaremos luego - son altamente inmunes a estos ataques. Los analizadores
de retina, de iris, de huellas o de la geometra de la mano son capaces, aparte de
decidir si el miembro pertenece al usuario legtimo, de determinar si ste est vivo
o se trata de un cadver.
Verificacin de voz
En los sistemas de reconocimiento de voz no se intenta, como mucha gente
piensa, reconocer lo que el usuario dice, sino identificar una serie de sonidos y sus
caractersticas para decidir si el usuario es quien dice ser. Para autenticar a un
usuario utilizando un reconocedor de voz se debe disponer de ciertas condiciones
para el correcto registro de los datos, como ausencia de ruidos, reverberaciones o
ecos; idealmente, estas condiciones han de ser las mismas siempre que se
necesite la autenticacin.
Cuando un usuario desea acceder al sistema pronunciar unas frases en las
cuales reside gran parte de la seguridad del protocolo; en algunos modelos, los
25

denominados de texto dependiente, el sistema tiene almacenadas un conjunto

muy limitado de frases que es capaz de reconocer: por ejemplo, imaginemos que
el usuario se limita a pronunciar su nombre, de forma que el reconocedor lo
entienda y lo autentique. Como veremos a continuacin, estos modelos
proporcionan poca seguridad en comparacin con los de texto independiente,
donde el sistema va proponiendo a la persona la pronunciacin de ciertas
palabras extradas de un conjunto bastante grande.
De cualquier forma, sea cual sea el modelo, lo habitual es que las frases o
palabras sean caractersticas para maximizar la cantidad de datos que se pueden
analizar (por ejemplo, frases con una cierta entonacin, pronunciacin de los
diptongos, palabras con muchas vocales, etc.). Conforme va hablando el usuario,
el sistema registra toda la informacin que le es til; cuando termina la frase, ya ha
de estar en disposicin de facilitar o denegar el acceso, en funcin de la
informacin analizada y contrastada con la de la base de datos.
El principal problema del reconocimiento de voz es la inmunidad frente a replay
attacks, un modelo de ataques de simulacin en los que un atacante reproduce
(por ejemplo, por medio de un magnetfono) las frases o palabras que el usuario
legtimo pronuncia para acceder al sistema.
Este problema es especialmente grave en los sistemas que se basan en textos
preestablecidos: volviendo al ejemplo anterior, el del nombre de cada usuario, un
atacante no tendra ms que grabar a una persona que pronuncia su nombre ante
el autenticador y luego reproducir ese sonido para conseguir el acceso; casi la
nica solucin consiste en utilizar otro sistema de autenticacin junto al
reconocimiento de voz. Desde otro punto de vista, en modelos de texto
independiente, ms interactivos, este ataque no es tan sencillo porque la
autenticacin se produce realmente por una especie de desafo/respuesta entre el
usuario y la mquina, de forma que la cantidad de texto grabado habra de ser
mucho mayor y la velocidad para localizar la parte del texto que el sistema
propone habra de ser elevada.
Otro grave problema de los sistemas basados en reconocimiento de voz es el
tiempo que el usuario emplea hablando delante del analizador, al que se aade el
que ste necesita para extraer la informacin y contrastarla con la de su base de
datos; aunque actualmente en la mayora de sistemas basta con una sola frase, es
habitual que el usuario se vea obligado a repetirla porque el sistema le deniega el
acceso (una simple congestin hace variar el tono de voz, aunque sea levemente,
y el sistema no es capaz de decidir si el acceso ha de ser autorizado o no; incluso
el estado anmico de una persona vara su timbre).
A su favor, el reconocimiento de voz posee la cualidad de una excelente acogida
entre los usuarios, siempre y cuando su funcionamiento sea correcto y stos no se
vean obligados a repetir lo mismo varias veces, o se les niegue un acceso porque
no se les reconoce correctamente.
26

Verificacin de escritura
Aunque la escritura (generalmente la firma) no es una caracterstica estrictamente
biomtrica, se suele agrupar dentro de esta categora; de la misma forma que
suceda en la verificacin de la voz, el objetivo aqu no es interpretar o entender lo
que el usuario escribe en el lector, sino autenticarlo basndose en ciertos rasgos
tanto de la firma como de su rbrica.
La verificacin en base a firmas es algo que todos utilizamos y aceptamos da a
da en documentos o cheques; no obstante, existe una diferencia fundamental
entre el uso de las firmas que hacemos en nuestra vida cotidiana y los sistemas
biomtricos; mientras que habitualmente la verificacin de la firma consiste en un
simple anlisis visual sobre una impresin en papel, esttica, en los sistemas
automticos no es posible autenticar usuarios en base a la representacin de los
trazos de su firma.
En los modelos biomtricos se utiliza adems la forma de firmar, las
caractersticas dinmicas (por eso se les suele denominar Dynamic Signature
Verification, DSV): el tiempo utilizado para rubricar, las veces que se separa el
bolgrafo del papel, el ngulo con que se realiza cada trazo, etc.
Para utilizar un sistema de autenticacin basado en firmas se solicita en primer
lugar a los futuros usuarios un nmero determinado de firmas ejemplo, de las
cuales el sistema extrae y almacena ciertas caractersticas; esta etapa se
denomina de aprendizaje, y el principal obstculo a su correcta ejecucin son los
usuarios que no suelen firmar uniformemente.
Contra este problema la nica solucin (aparte de una concienciacin de tales
usuarios) es relajar las restricciones del sistema a la hora de aprender firmas, con
lo que se decrementa su seguridad.
Una vez que el sistema conoce las firmas de sus usuarios, cuando estos desean
acceder a l, se les solicita tal firma, con un nmero limitado de intentos
(generalmente ms que los sistemas que autentican mediante contraseas, ya
que la firma puede variar en un individuo por mltiples factores).
La firma introducida es capturada por un lpiz ptico o por una lectora sensible (o
por ambos), y el acceso al sistema se produce una vez que el usuario ha
introducido una firma que el verificador es capaz de distinguir como autntica.
Verificacin de huellas
Tpicamente la huella dactilar de un individuo ha sido un patrn bastante bueno
para determinar su identidad de forma inequvoca, ya que est aceptado que dos
dedos nunca poseen huellas similares, ni siquiera entre gemelos o entre dedos de
27

la misma persona. Por tanto, parece obvio que las huellas se convertiran antes o
despus en un modelo de autenticacin biomtrico: desde el siglo pasado hasta
nuestros das se vienen realizando con xito clasificaciones sistemticas de
huellas dactilares en entornos policiales, y el uso de estos patrones fu uno de los
primeros en establecerse como modelo de autenticacin biomtrica.
Cuando un usuario desea autenticarse ante el sistema ubica su dedo en un rea
determinada (rea de lectura, no se necesita en ningn momento una impresin
en tinta). Aqu se toma una imagen que posteriormente se normaliza mediante un
sistema de finos espejospara corregir ngulos, y es de esta imagen normalizada
de la que el sistema extrae las minucias (ciertos arcos, bucles o remolinos de la
huella) que va a comparar contra las que tiene en su base de datos; es importante
resaltar que lo que el sistema es capaz de analizar no es la huella en s sino que
son estas minucias, concretamente la posicin relativa de cada una de ellas.
Est demostrado que dos dedos nunca pueden poseer ms de ocho minucias
comunes, y cada uno tiene al menos 30 o 40 de stas.
Si la comparacin de las posiciones relativas de las minucias ledas con las
almacenadas en la base de datos es correcta, se permite el acceso al usuario,
denegndosele obviamente en caso contrario.
Los sistemas basados en reconocimiento de huellas son relativamente baratos (en
comparacin con otros biomtricos, como los basados en patrones retinales); sin
embargo, tienen en su contra la incapacidad temporal de autenticar usuarios que
se hayan podido herir en el dedo a reconocer (un pequeo corte o una quemadura
que afecte a varias minucias pueden hacer intil al sistema).
Tambin elementos como la suciedad del dedo, la presin ejercida sobre el lector
o el estado de la piel pueden ocasionar lecturas errneas. Otro factor a tener muy
en cuenta contra estos sistemas es psicolgico, no tcnico.
Verificacin de patrones oculares
Los modelos de autenticacin biomtrica basados en patrones oculares se dividen
en dos tecnologas diferentes: o bien analizan patrones retinales, o bien analizan
el iris.
Estos mtodos se suelen considerar los ms efectivos: para una poblacin de 200
millones de potenciales usuarios la probabilidad de coincidencia es casi 0, y
adems una vez muerto el individuo los tejidos oculares degeneran rpidamente,
lo que dificulta la falsa aceptacin de atacantes que puedan robar este rgano de
un cadver.
La principal desventaja de los mtodos basados en el anlisis de patrones
oculares es su escasa aceptacin; el hecho de mirar a travs de un binocular (o
28

monocular), necesario en ambos modelos, no es cmodo para los usuarios, ni

aceptable para muchos de ellos: por un lado, los usuarios no se fan de un haz de
rayos analizando su ojo y por otro, un examen de este rgano puede revelar
enfermedades o caractersticas mdicas que a muchas personas les puede
interesar mantener en secreto, como el consumo de alcohol o de ciertas drogas.
Aunque los fabricantes de dispositivos lectores aseguran que slo se analiza el ojo
para obtener patrones relacionados con la autenticacin, y en ningn caso se viola
la privacidad de los usuarios, mucha gente no cree esta postura oficial (aparte del
hecho de que la informacin es procesada va software, lo que facilita introducir
modificaciones sobre lo que nos han vendido para que un lector realice otras
tareas de forma enmascarada).
Por si esto fuera poco, se trata de sistemas demasiado caros para la mayora de
organizaciones, y el proceso de autenticacin no es todo lo rpido que debiera en
poblaciones de usuarios elevadas. De esta forma, su uso se ve reducido casi slo
a la identificacin en sistemas de alta seguridad, como el control de acceso a
instalaciones militares.
29

Leccin 8: Autenticacin de Usuario Mediante Contrasea

Como hemos visto hata el momento, la autenticacin establece una prueba de
identidad de un usuario ante un sistema informtico o electrnico, es decir, se trata
de un proceso mediante el cual se puede probar la identidad de dicho usuario. Las
tcnicas de autenticacin sirven para que el verificador est seguro que la
identidad del solicitante es la declarada y no ha sido suplantada.
Igualmente hemos visto durante esta materia de la especializacin, que existen
tres tcnicas de autenticacin de usuarios, que se basan en algo que el usuario
sabe, algo que el usuario tiene y algo que el usuario es.
La autenticacin de usuario mediante contrasea pertenece al grupo de algo que
el usuario sabe.
La autenticacin algo que el usuario sabe asume que solo una persona conoce
una determinada clase o contrasea de acceso. Este tipo de autenticacin se usa
ampliamente en redes, Internet y en las intranets. Una gran amenaza que trae
esta tcnica es que un impostor descubra la contrasea de alguien y se haga
pasar por esta persona, suplantando su identidad y violando la seguridad. Existen
formas de disminuir la posibilidad de que alguien descubra la contrasea, por
ejemplo, aumentando la longitud de la misma o modificndola cada cierto tiempo.
No obstante dichas soluciones nos plantean una serie de problemas: los seres
humanos no tenemos una buena memoria, por ello nos es difcil recordar cdigos
largos, lo que hace que, aunque el sistema admita contraseas largas, pocos las
utilicen.
En la prctica muchos usuarios, para poder recordar sus mltiples contraseas,
utilizan siempre el mismo tipo de claves, e incluso la misma clave para distintas
cuestiones. Esto permite a hackers experimentados violar su seguridad
adivinando sus contraseas.
Como el sistema de autentificacin basa su funcionamiento en una informacin
secreta conocida nicamente por el usuario, que le permite identificarse
positivamente frente al sistema. Supondremosque el usuario se encuentra en un
terminal seguro, es decir, libre de posibles ataquesdel exterior. Distinguiremos
entonces dos casos claramente diferenciados:
El sistema se comunica con el usuario, pero ste no puede entrar en l.

Pinsese en un cajero automtico. El usuario carece de acceso a los
archivos del sistema y no tiene posibilidad de ejecutar aplicaciones en l,
30

nicamente puede llevar a cabo una serie de operaciones muy restringidas.

b) El sistema permite al usuario entrar. Este es el caso de los sistemas
operativos como UNIX,que ofrecen la posibilidad a los usuarios operar con el
sistema desde terminales remotos.
Normalmente el usuario tiene acceso ms o menos restringido a los archivos del
sistema ypuede ejecutar programas.
El primer caso es el ms simple y sencillo de resolver. Basta con que el sistema
mantengala lista de usuarios y sus contraseas asociadas en un archivo. Como
este archivo no puede serconsultado desde el exterior, es imposible averiguar la
clave de un usuario.
Para protegersede los ataques por la fuerza bruta, ser suficiente con limitar el
nmero de intentos desde unterminal concreto e introducir retardos cuando la
contrasea introducida sea errnea.
El caso b)es considerablemente ms complejo. Por un lado deberemos tomar las
mismasmedidas que en el caso anterior para protegernos de los ataques por la
fuerza bruta, y por otrohemos de tener en cuenta que cualquier usuario puede
acceder a algunos archivos.
En versionesantiguas de sistemas operativos UNIX el archivo con las contraseas
poda ser descargado por cualquier usuario annimoque tiene un nombre concreto
y una contrasea genrica, porlo que las palabras clave no pueden ser
almacenadas como texto claro en dicho archivo.
Elmecanismo que surge entonces de manera inmediata consiste en almacenar en
el archivo declaves la firma de cada contrasea. De esta forma ser difcil adivinar
una contrasea quese ajuste a una firma concreta. Los sistemas operativos
modernos impiden adems leer el archivo de claves de forma directa, pero eso no
evita que en algunos casos ste pueda quedarcomprometido.

ptimo.
Mecanismos de autenticacin por contrasea Alberto Molina Coballes
Link:http://informatica.gonzalonazareno.org/plataforma/pluginfile.php/4222/
mod_resource/content/2/autenticacin.pdf
31

Leccin 9: Ataques Mediante Diccionario

El principal problema de las palabras clave son las elecciones poco afortunadas
por partede los usuarios. Desgraciadamente todava hay personas que emplean
su fecha de nacimiento, el nombre de algn familiar o la matrcula del carro como
contrasea.
Un atacante con experiencia podra tratar de generar millones de claves y
construir un diccionario. El siguiente paso seraprecalcular las firmas de todas las
claves que hay en su diccionario.
Si de alguna maneraha obtenido el archivo con las firmas de las claves, bastara
con compararlas con las desu diccionario para obtener en pocos segundos una
contrasea que le permita entrar en elsistema.
Tengamos en cuenta que un diccionario con ms de 150.000 claves de ocho
caracteres caba (sin comprimir) en un diskette de 3 pulgadas y media, y que ha
habido casos en los quecon diccionarios de este tamao se ha conseguido
averiguar un sorprendente nmero de claves.
Para protegerse frente a este tipo de ataques se introduce en el clculo de la firma
de la contrasea denominada sal que no es ni ms ni menos que un conjunto de
bitsaleatorios que se aaden a la palabra clave antes de calcular su firma.
En el archivo de claves se almacenara, junto con la firma, la salnecesaria para
32

su obtencin. Esto obligara alatacante a recalcular todas las firmas de su

diccionario antes de poder compararlas concada una de las entradas del archivo
de claves del sistema.
De todas formas, si la contrasea buscada aparece en el diccionario, el nico
inconveniente para el atacante sera que en lugar deobtenerla de forma casi
instantnea, se tardara algn tiempo en conseguirla.
Deberemos pues, evitar a toda costa emplear contraseas que puedan aparecer
en un diccionario.
Adems de estar bien salvaguardadas, las palabras clave han de cumplir una
serie decondiciones para que puedan considerarse seguras:
Deben ser memorizadas. Una contrasea jams debe ser escrita en un papel,
por razones obvias.
Suficientemente complejas. Una buena contrasea debe constar de al menos 12
letras.
Pensemos que si empleamos nicamente seis caracteres alfanumricos (nmeros
y letras), tenemos nicamente unos dos mil millones de posibilidades. Teniendo en
cuenta que hay programas para PC capaces de probar ms de cuarenta mil claves
en un segundo, una clave de estas caractersticas podra ser descubierta en
menos de quince horas.
Carecer de significado. Una contrasea jams debe significar nada, puesto que
entonces aumentar la probabilidad de que aparezca en algn diccionario.
Evitemos los nombres propios, en especial aquellos que pertenezcan a lugares o
personajes de ficcin.
Todo lo comentado nos lleva a una conclusin: aunque existen infinidad de
variantes de sistemas basados en algo que el usuario sabe, todos ellos
dependen de la memoria del usuario y del cambio continuo de claves. Por ello,
mediante esta tcnica, es difcil incrementar la seguridad mientras se mantiene la
comodidad del usuario.
ptimo.
Ataque por diccionario (John the Ripper) Harrison Marin Charry
Link: https://www.youtube.com/watch?v=P_AT1Odk8vE
Parar ataque de diccionario al servidor (MONITOREO GRABADO EN
VIVO) - Hugo Lesta
Link:https://www.youtube.com/watch?v=So4VbHSBgcw
33

Leccin 10: Estenografa

El desarrollo de la informtica e Internet ha supuesto el marco perfecto para que la
esteganografa alcancesu mayora de edad. Los avances en computacin nos
proporcionan medios para calcular rpidamente loscambios necesarios en la
ocultacin de un mensaje, e Internet proporciona los medios necesarios
paratransportar grandes cantidades de informacin a cualquier punto del planeta.
La esteganografa actual se basa en esconder datos binarios en la maraa de bits
que supone un archivo.
Los bits que componen el mensaje a ocultar se introducen (bien sea aadindolos,
o realizandooperaciones aritmticas con los originales) en el archivo ya existente,
procurando que el archivo resultantedespus de realizar los cambios parezca el
original.
Cmo logramos que el archivo resultante no parezca haber sido modificado?,
depende de qu tipo defichero estemos modificando. Prcticamente cualquier tipo
de archivo es bueno para ocultar datos en suinterior, pero hay algunos (imgenes
y sonido principalmente) que resultan ideales para este cometido. As mismo
existen ciertos programas especializados enocultacin de informacin en sectores
de disco no usados.
Sea cual sea el tipo de informacin que queramos esteganografiar, y sea cual sea
el medio en el quequeremos hacerlo, hay ciertas reglas bsicas:
34

Toda informacin (texto ASCII, hexadecimal, cdigo morse,

etc.) que queramos introducir, debe ser primero convertida a
binario. Si bien cualquier base numrica es vlida, la
comodidad trabajando con binario es mucho mayor.
Nunca hay que permitir que un supuesto atacante obtenga el
archivo original (anterior a la modificacin), pues permitira,
mediante comparacin, establecer pautas de cambios en la
informacin. Esto podra llevar en ltima instancia a
desentraar el mensaje oculto.
Las cabeceras de los archivos -salvo excepciones- NO deben
ser modificadas.
No transmitir la clave oalgoritmo esteganogrfico por un medio
inseguro.
Aunque la esteganografa computacional clsica consiste en la modificacin

binaria del fichero que sirve decanal, existen ciertas tcnicas para casos
particulares de ficheros que tambin son vlidas (aunquecomplicadas de hacer a
mano, con lo cual dependemos de algn tipo de software).
Un ejemplo de estas tcnicas es la adicin de mensajes ocultos a los archivos de
sonidomediante superposicin de capas de sonidos que no resultan audibles para
el odo humano, pero que scontienen informacin.
As mismo, hay tcnicas basadas en ocultacin de mensajes en archivos de
imgen creados con potentes programas de tratamiento grfico (como Gimp o
Photoshop)mediante el uso de capas transparentes donde se alojaba la
informacin.
Supongamos que queremos enviar un mensaje secreto a un interlocutor que se
encuentra en un lugar donde la Criptografa est prohibida. Podramos, por
ejemplo, enviarle una imagende mapa de bits y utilizar el bit menos significativo
del color de cada pxel para guardar cadabit del mensaje secreto.
La imagen ser vlida y un observador externo nunca sospechar queen realidad
esconde un mensaje secreto.
Existen infinidad de mtodos de esteganografa, slo limitados por la imaginacin,
pero, por qu incluir esta tcnica dentro del captulo dedicado a autentificacin?
La respuesta essencilla: en general la esteganografa consiste en mezclar
informacin til con informacin de alguna otra naturaleza, que slo sirve para
despistar.
Podramos definirla entonces como elmecanismo que nos permite entresacar la
informacin til, reduciendo este problema a unasimple autentificacin.
Volvamos al ejemplo de la imagen de mapa de bits. Si el observador externo
35

conocierael algoritmo que hemos empleado para camuflar nuestro mensaje dentro
de la imagen, el sistema quedara automticamente comprometido. Alguien podra
proponer entonces emplear la Criptografa y almacenar en los bits menos
significativos de cada pxel la versin codificadadel mensaje.
Existe sin embargo, una forma ms elegantede proteger la informacin sin
emplear ningn algoritmo criptogrfico.
Podramos generar una gran cantidad de informacin irrelevante y subdividirla
junto con el mensaje original en pequeos paquetes, a los que aadiramos un
cdigo de identificacin(firma o signatura), de forma que slo los paquetes que
corresponden al mensaje contengan una signaturacorrecta.
Si enviamos una secuencia de paquetes en la que aparece el mensaje
originalentremezclado con la basura, slo quien disponga del mecanismo de
autentificacin correcto que podra depender de una clave, estara en condiciones
de recuperar el mensaje original.
Sin embargo, el mensaje ha sido enviado como texto claro, sin ser codificado en
ningn momento.
El ejemplo del mapa de bits no sera ms que un caso particular de este esquema,
en elque el algoritmo de autentificacin simplemente considera vlidos los bits
menos significativos de cada pxel y descarta todos los dems.
Profundizacin Leccin 10: El estudiante debe profundizar en cada

leccin que sea vista para adquirir conocimientos a fondo y lograr un
aprendizaje ptimo.
Criptografa vs Esteganografa [GuadalajaraCON 2012] - WEBSECmx UCLM Albacete
Link:https://www.youtube.com/watch?v=CqDkEIemtwY
Esteganografa: para cifrar mensajes en imgenes - matuk
Link:https://www.youtube.com/watch?v=qwIvN0fz5WE
Herramienta Hacking. Esteganografa: Usando S-Tools -Soma Cruz
Link: https://www.youtube.com/watch?v=n3sskVXoKBM
36

CAPITULO 3: COMUNICACIN SEGURA

Introduccin
Hablar de seguridad en las comunicaciones es un tema con muchas reas de
implementacin, ya quemuchas veces optamos por dejarle todo aun hardware o
perifrico, sin tomar en cuenta que hay otras herramientasde apoyo para poder
implementar un nivel de seguridad mayor, adems hoy en da para poder lograr
comunicacin segura es importante analizar todos los factores existentes dentro
de la organizacin y ver con cuales de ellos sepueden contar.
La seguridad en las comunicaciones ha evolucionado de una manera
impresionante y ha creado nuevasposibilidades en ambientes que se dedican a la
educacin e investigacin.
Por ejemplo, gracias a los avances se ha podidocombinar la capacidad de una
LAN con la de una WLAN para soportar tcnicamente todo lo necesario en lo
quese refiere a la educacin a distancia.
Tambin se han podido implementar tecnologas como la telefona sobre IP y la
posibilidad de teneracceso a Internet en prcticamente cualquier punto de un
Campus Universitario. Las universidades de hoy en daenfrentan enormes retos
desarrollando y manteniendo las infraestructuras tecnolgicas que se demandan.
El intercambio seguro de datos ha sido histricamente uno de los problemas ms
estudiados por el hombreen la bsqueda del perfeccionamiento de la
comunicacin entre diversas fuentes. La aparicin ydesarrollo de internet
increment las expectativas y los esfuerzos en el estudio del tema referido.
Internet ha sido concebida como una red de redes que para la interconexin
descentralizada decomputadoras a travs de un conjunto de protocolos,
permitiendo quemillones de personascompartan informacin.
Es por ello se desarrollan numerosas aplicaciones queaprovechan su capacidad
bidireccional de manejar la informacin. Vale destacar que internet seconcibe
como una red completamente abierta, por ello insegura, aspecto reconocido y
destacado porlas autoridades lderes en el manejo de la red como una
caracterstica inherente de la misma. Se hanpuesto de manifiesto tambin
vulnerabilidades y fallas de seguridad importantes en diferentessistemas; por ello,
el reto para los desarrolladores de estas aplicaciones consiste en asegurar
lafidelidad de la informacin a transmitir y evitar la intromisin de terceros en la
comunicacin.
37

Leccin 11: Autenticidad

La autenticidad, se refiere a que se pueda confirmar que el mensaje recibido haya
sidomandado por quien dice lo mando o que el mensaje recibido es el que se
esperaba.
Ejemplo: cuando se quiere cobrar un cheque a nombre de alguien, quien lo cobra
debe desometerse a un proceso de verificacin de identidad para comprobar que
en efecto es la personaquien dice ser, esto en general se lleva a cabo con una
credencial que anteriormente fue certificada yacredita la identidad de la persona
que la porta. La verificacin se lleva a cabo comparando lapersona con una foto o
con la comparacin de una firma convencional.
Por internet es muy fcil engaar a una persona con quien se tiene comunicacin
respecto a laidentidad, resolver este problema es por lo tanto muy importante para
efectuar comunicacinconfiable.
Las tcnicas necesarias para poder verificar la autenticidad tanto de personas
como de mensajesusan quiz la ms conocida aplicacin de la criptografa
asimtrica que es la firma digital, de algnmodo sta reemplaza a la firma
autgrafa que se usa comnmente. Para autenticar mensajes seusa criptografa
simtrica.
Cuando se disea un sistema de seguridad, una gran cantidad de problemas
pueden ser evitadossi se puede comprobar autenticidad, garantizar privacidad,
asegurar integridad y evitar el norechazo.
La criptografa simtrica y asimtrica conjuntamente con otras tcnicas, como el
buen manejo delas claves y la legislacin adecuada resuelven satisfactoriamente
los anteriormente problemasplanteados.
Obviamente la autenticidad es una caracterstica muy importante en el campo de
la seguridad. PGP por ejemplo, permite el uso de firmas digitales las cuales dan al
receptor la capacidad de verificar que el documento no ha sido modificado y que
realmente viene de su destinatario.
Supongamos que queremos enviar el documento llamado deuda.doc a un amigo
llamado Pepito Perez firmado con nuestra firma secreta.
Como parte del identificador de la llave pblica del amigo Pepito es su nombre,
entonces podemos adicionar solamente el nombre para que pgp incruste en el
archivo la llave pblica.
Es importante que primero el seor Carlos nos haya enviado su llave pblica y que
nosotros la hayamos adicionado a nuestro anillo de llaves pblicas.
38


aprendizaje ptimo.
Certificados electrnicos y digitales. Firma electrnica - AvanzaExportador
Link:https://www.youtube.com/watch?v=EU6vgU077xU
Certificados Digitales y Firma Electrnica - ProyectoCECARM
Link: https://www.youtube.com/watch?v=VXNiPLtAtb4
39

Leccin 12: Confidencialidad

La confidencialidad es un concepto que se puede explicar fcilmente, pero solo
tiene alguna utilidad cuando los datos y documentos han sido clasificados en
categoras como pblico, restringido a, embargado hasta y reservado, que
reflejan la necesidad que tiene una empresa de protegerlos.
No es conveniente que los tcnicos que se encargan de la infraestructura y
servicios de TI se ocupen de realizar esta clasificacin, ya que probablemente no
tengan un conocimiento cabal del negocio y, en caso de emplearse la modalidad
de externalizacin (outsourcing) o un sistema de computacin en la nube (cloud
computing), es posible que adems no pertenezcan a la empresa. Por lo tanto, el
control y el proceso de clasificacin de datos debe quedar en manos del personal
del negocio, mientras que los proveedores de servicios y soluciones de TI deben
ocuparse de proporcionar las herramientas y los procesos necesarios, como son
los controles para la gestin de accesos e identidades (Identity Access
Management o IAM) y la encriptacin.
El mtodo ms sencillo para medir la confidencialidad tiene una lgica binaria: el
carcter confidencial de la informacin puede haberse preservado (si la
informacin no se ha divulgado) o no (si se ha divulgado). Lamentablemente, este
mtodo no resulta demasiado til, ya que no refleja los efectos de la divulgacin
de los datos, que abarcan desde situaciones bochornosas hasta atentados contra
la seguridad nacional.
Para que un originador A pueda enviar un mensaje cifrado a un destinatario B,es
preciso que ambos hayan acordado el uso de una determinada clave
deintercambio kAB. Esto se puede realizar con una comunicacin segura fuerade
lnea (por ejemplo, cara a cara), o bien con un mecanismo de distribucinde
claves.
La clave de intercambio kAB puede ser una clave simtrica o una clave pblica.
Si es simtrica, se puede utilizar la misma en ambos sentidos de la
comunicacin,de A a B y de B a A (kAB = kBA). El uso de claves de
intercambiosimtricas estaba contemplado en el estndar PEM, pero hoy no es
muy habitual.
La situacin ms normal es que la clave de intercambio sea una clave pblica,y
entonces las claves correspondientes a un destinatario B son toda la misma:
k1B = k2B = k3B = . . . = kpubB .
El mtodo que se utiliza para enviar un mensaje cifrado es el llamado sobre digital,
que consiste en:
40

a) Generar aleatoriamente una clave de cifrado simtrica kS, distinta

para cada mensaje. Esta clave kS se llama clave de cifrado de
contenido o bien, por analoga con los protocolos de transporte,
clave de sesin.
b) Cifrar el mensaje M con esta clave simtrica y obtener C =
E(kS,M).
c) Para cada destinatario By del mensaje, cifrar la clave de sesin
con la clave pblica de este destinatario y obtener K By = E(kpubBy
,kS).
d) Construir un nuevo mensaje aadiendo al mensaje cifradoC todas
las claves cifradas KBy .
e) Enviar a los destinatarios este mensaje (el mismo para todos).
Por lo tanto, si un mensaje confidencial se tiene que transmitir a N destinatarios,no
es necesario enviar N copias del mensaje cifradas con la clave de cada uno de
ellos. Se puede utilizar la misma copia para todos, con lo cual esposible
aprovechar los mecanismos ya existentes para enviar un mensaje amltiples
destinatarios.
Figura 7: Ejemplo de proceso para garantizar la confidencialidad. Fuente:

http://www.hfernandezdelpech.com.ar
41


aprendizaje ptimo.
Panel A / Gobierno Abierto - AGESIC
Link:https://www.youtube.com/watch?v=wmzKE_qxTVc
La NSA te est leyendo #PRISM Mejorando la Web
Link:https://www.youtube.com/watch?v=986Hox-NIMs
Leccin 13: Integridad
La seguridad de la informacin ha cobrado visibilidad en distintos mbitos: en el

trabajo, en el hogar y durante el traslado de un lugar a otro. Se trata,
principalmente, de prevenir los ataques destinados a restringir la disponibilidad
(por ejemplo, la denegacin del servicio) y a introducir software malintencionado
(malware) que permita a un tercero manipular datos e informacin sin autorizacin
(por ejemplo, para robar, divulgar, modificar o destruir datos).
El gusano informtico Stuxnet, que fue descubierto en el ao 2010, alter el
funcionamiento de un proceso industrial, ya que fue diseado con la finalidad de
daar equipos fsicos y modificar las indicaciones de los operadores a cargo de la
supervisin, para impedir, de este modo, que se identificara cualquier anomala en
los equipos.
Si esta modalidad de ataque a la integridad de los datos (denominado tambin
ataque semntico) se hubiera replicado en otros sistemas, podra haber causado
42

problemas graves en infraestructuras informticas de importancia crtica, como las

de servicios pblicos, servicios de urgencia, control de trfico areo y cualquier
otro sistema que dependa en gran medida de las tecnologias de la informacin y
resulte indispensable para la sociedad. El gobierno de la informacin es un factor
esencial para la consolidacin de la integridad de los datos.
Si analizamos la nocin de integridad, la situacin se torna ms compleja, porque
se trata de un concepto que puede tener distintas interpretaciones. Este es un
terreno frtil para los problemas de comunicacin y los malentendidos, con el
consiguiente riesgo de que una actividad no se lleve a cabo satisfactoriamente por
las confusiones en torno a las responsabilidades pertinentes.
Qu Debemos Entender por "Integridad"?
La importancia de la integridad de los datos se puede ilustrar con un sencillo
ejemplo: Una persona necesita un tratamiento hospitalario que incluye la
administracin diaria de un medicamento en dosis de 10 miligramos (mg).
Accidental o intencionalmente, se produce una modificacin en el registro
electrnico del tratamiento y las dosis quedan establecidas en 100 mg, con
consecuencias mortales. Para tomar otro ejemplo, podramos imaginar una
situacin propia de una obra de ficcin que antecediera al ataque del virus Stuxnet
en 2010 y preguntarnos qu ocurrira si alguien interfiriera los sistemas de control
de una central nuclear para que simularan condiciones de funcionamiento normal
cuando, en realidad, se ha provocado una reaccin en cadena.
Podemos afirmar que los profesionales reconocen las mltiples definiciones de la
integridad de los datos?, veamos:
Para un encargado de seguridad, la integridad de los datos puede

definirse como la imposibilidad de que alguien modifique datos sin ser
descubierto. Desde la perspectiva de la seguridad de datos y redes, la
integridad de los datos es la garanta de que nadie pueda acceder a la
informacin ni modificarla sin contar con la autorizacin necesaria. Si
examinamos el concepto de integridad, podramos concluir que no solo
alude a la integridad de los sistemas (proteccin mediante antivirus, ciclos
de vida del desarrollo de sistemas estructurados - SDLC, revisin de
cdigos fuente por expertos, pruebas exhaustivas, etc.), sino tambin a la
integridad personal (responsabilidad, confianza, fiabilidad, etc.).
Para un administrador de bases de datos, la integridad de los datos puede

depender de que los datos introducidos en una base de datos sean
precisos, vlidos y coherentes. Es muy probable que los administradores de
bases de datos tambin analicen la integridad de las entidades, la
integridad de los dominios y la integridad referencial - conceptos que podra
desconocer un experto en infraestructuras instruido en normas ISO 27000 o
en la serie 800 de publicaciones especiales (SP 800) del Instituto Nacional
de Normas y Tecnologa (NIST, National Institute of Standards and
43

Technology) de los EE. UU.
Para un arquitecto o modelador de datos, la integridad de los datos puede

estar relacionada con el mantenimiento de entidades primarias nicas y no
nulas. La unicidad de las entidades que integran un conjunto de datos se
define por la ausencia de duplicados en el conjunto de datos y por la
presencia de una clave que permite acceder de forma exclusiva a cada una
de las entidades del conjunto.
Para el propietario de los datos (es decir, para el experto en la materia), la

integridad de los datos puede ser un parmetro de la calidad, ya que
demuestra que las relaciones entre las entidades estn regidas por reglas
de negocio adecuadas, que incluyen mecanismos de validacin, como la
realizacin de pruebas para identificar registros hurfanos.
Para un proveedor, la integridad de los datos es: la exactitud y

coherencia de los datos almacenados, evidenciada por la ausencia de
datos alterados entre dos actualizaciones de un mismo registro de datos. La
integridad de los datos se establece en la etapa de diseo de una base de
datos mediante la aplicacin de reglas y procedimientos estndar, y se
mantiene a travs del uso de rutinas de validacin y verificacin de errores.
En un diccionario disponible en lnea, se define la integridad de los datos

de este modo: Cualidad de la informacin que se considera exacta,
completa, homognea, slida y coherente con la intencin de los creadores
de esos datos. Esta cualidad se obtiene cuando se impide eficazmente la
insercin, modificacin o destruccin no autorizada, sea accidental o
intencional del contenido de una base de datos. La integridad de los datos
es uno de los seis componentes fundamentales de la seguridad de la
informacin.
Sin duda, podemos encontrar muchas otras definiciones. Pero todas contienen
aadidos, aluden a temas de distinta ndole y producen cierta confusin
semntica, uno de los principales motivos por los que las bases de datos son los
objetos menos protegidos de la infraestructura de las tecnologas de la
informacin.
El planteamiento del problema no termina aqu. La descentralizacin de los
sistemas de informacin y la disponibilidad de entornos de programacin eficaces
para los usuarios finales, como las hojas de clculo, han creado vulnerabilidades
potencialmente descontroladas en la integridad de los datos, ya que esas hojas de
clculo se utilizan como fundamento de decisiones ejecutivas, sin evaluar, muchas
veces, la calidad e integridad de los datos. Cmo deberamos abordar este
problema?, en primer lugar, podramos considerar que se trata de un problema
que atae:
44

A la seguridad de la informacin, dado que no se puede

garantizar la integridad de los datos.
A la calidad del software, dado que la mayora de las hojas de

clculo no est sujeta a un proceso de gestin del ciclo de
vida.
A la inteligencia de negocios, dado que la introduccin de

datos errneos produce resultados errneos, algo que en
ingls se conoce como GIGO (Garbage In, Garbage Out, lo
que significa que si entra basura, sale basura).
Quizs podramos concluir que abarca los tres aspectos; en tal caso, el siguiente
paso consistira en determinar quin debera abordar el problema (el propietario de
los datos, el usuario final que dise la hoja de clculo, el departamento o
proveedor de servicios de tecnologas de la informacin o todos juntos).
Acabamos de analizar a modo de ejemplo, el uso de hojas de clculo diseadas
por los usuarios sin someterlas a pruebas ni incluir documentacin (hecho que se
ve agravado por la introduccin manual de datos, particularmente cuando no se
validan los valores ingresados), pero existen otros disparadores de problemas que
podran resultar an ms graves:
1. Modificacin de los permisos y privilegios de acceso.
2. Imposibilidad de rastrear el uso de contraseas privilegiadas, en especial
cuando es compartido.
3. Errores del usuario final que afectan los datos de produccin.
4. Aplicaciones vulnerables a la introduccin de cdigos ocultos (como los
backdoors).
5. Procesos de control de cambios y acreditacin deficientes o no desarrollados
plenamente.
6. Fallas en la configuracin de software y dispositivos de seguridad.
7. Aplicacin de parches en forma incorrecta o incompleta.
8. Conexin de dispositivos no autorizados a la red corporativa.
9. Uso de aplicaciones no autorizadas en dispositivos conectados a la red
corporativa.
45

10. Segregacin de funciones (SoD) inadecuada o no aplicada.

Por si esto fuera poco, la funcin de auditora de tecnologas de la informacin
podra carecer de la masa crtica necesaria para efectuar auditoras que
contemplen todos estos aspectos.
Por otra parte y no menos importante son los ataques a la integridad de los
datos,estos consisten en la modificacin intencional de los mismos, sin
autorizacin alguna, en algn momento de su ciclo de vida. Contextualizando, el
ciclo de vida de los datos comprende las siguientes etapas:
1.
Introduccin, creacin y/o adquisicin de datos.
2.
Procesamiento y/o derivacin de datos.
3.
Almacenamiento, replicacin y distribucin de datos.
4.
Archivado y recuperacin de datos.
5.
Realizacin de copias de respaldo y restablecimiento de datos.
6.
Borrado, eliminacin y destruccin de datos.
Hace aos que las organizaciones que operan tanto en el sector pblico como en
el privado sufren alteraciones en sus sitios web, pero, ms all del eventual
perjuicio a la reputacin de una empresa, ninguno de los daos ocasionados
puede considerarse catastrfico.
Las bombas lgicas, el software no autorizado que se introduce en un sistema por
accin de las personas encargadas de programarlo/mantenerlo, los troyanos y
dems virus similares tambin pueden afectar la integridad de los datos a travs
de la introduccin de modificaciones (por ejemplo, al definir una frmula incorrecta
en una hoja de clculo) o la encriptacin de datos y posterior exigencia de un
rescate para revelar la clave de desencriptacin. En los ltimos aos se han
producido numerosos ataques de caractersticas similares a las mencionadas, que
afectan principalmente los discos duros de las computadoras personales. Debera
esperarse que tarde o temprano se produzcan ataques de este tipo destinados a
los servidores.
La modificacin no autorizada de sistemas operativos (servidores y redes) y/o de
software de aplicaciones (como los backdoors o cdigos no documentados),
tablas de bases de datos, datos de produccin y configuracin de infraestructura
tambin se consideran ataques a la integridad de los datos. Es lgico suponer que
los hallazgos de las auditoras de TI incluyen con regularidad las fallas producidas
en procesos clave, particularmente en la gestin del acceso privilegiado, la gestin
46

de cambios, la segregacin de funciones y la supervisin de registros. Estas fallas

posibilitan la introduccin de modificaciones no autorizadas y dificultan su
deteccin (hasta que se produce algn incidente).
Otro mtodo de ataque a la integridad de los datos es la interferencia en los
sistemas de control de supervisin y adquisicin de datos (SCADA, Supervisory
Control and Data Acquisition), como los que se utilizan en infraestructuras crticas
(suministro de agua, electricidad, etc.) y procesos industriales. A menudo, la
funcin de TI no interviene en la instalacin, el funcionamiento ni la gestin de
estos sistemas. El ataque dirigido a plantas de enriquecimiento de uranio en Irn
durante el ao 2010 haba sido planeado con la finalidad de alterar el
comportamiento de los sistemas de centrifugacin sin que los tableros de control
indicaran ninguna anomala.
Cabe destacar que muchos de estos sistemas de control no estn conectados a
Internet y que, en el caso de la inyeccin del software Stuxnet, debi realizarse
una intervencin manual, hecho que confirma la teora de que el hombre sigue
siendo el eslabn ms dbil de la cadena de seguridad de la informacin.
Para las empresas que an no han comenzado a preparar estrategias de defensa,
un buen punto de partida es la adopcin de los procedimientos recomendados,
como el de Security Requirements for Data Management (Requerimientos de
seguridad para la gestin de datos), descrito en la seccin de Entrega y soporte
(DS, Deliver and Support) 11.6 de COBIT (Objetivos de control para la TI y
tecnologas afines), junto con los procedimientos indicados en la correspondiente
seccin de la gua de aseguramiento IT Assurance Guide: Using COBIT. Estas
publicaciones resumen el objetivo de control y los factores determinantes de valor
y de riesgo, e incluyen una lista de pruebas recomendadas para el diseo del
control.
La Asociacin Internacional de Gestin de Datos (Data Management Association
International, DAMA) ofrece un recurso adicional: The DAMA Guide to the Data
Management Body of Knowledge (DMBOK); se recomiendan especialmente los
captulos tres (Data Governance), siete (Data Security Management) y doce
(Data Quality Management).
Desde la perspectiva del cumplimiento normativo, existe un marco legislativo cada
vez ms amplio que asigna a las organizaciones la responsabilidad de garantizar
la integridad de los datos y del aseguramiento de la informacin (information
assurance o IA).
Porotra parte, la adopcin de mejores prcticas debe complementarse con la
formalizacin de las responsabilidades correspondientes a los procesos de
negocio y TI que soportan y mejoran la seguridad de los datos.
En todo programa de aseguramiento de la integridad de los datos deben estar
definidas las responsabilidades de deteccin y detencin (Detect, Deter o 2D);
47

de prevencin y preparacin (Prevent, Prepare o 2P); y de respuesta y

recuperacin (Respond, Recover o 2R). Como propietarias de los datos, las
reas de negocio deben tomar la iniciativa, mientras que el proveedor de servicios
de TI (se trate de personal interno o contratado mediante la modalidad de
externalizacin de servicios) debe ocuparse de la implementacin.
Las buenas prcticas a adoptar son:
1.
Tomar posesin de los datos y asumir la responsabilidad de garantizar su

integridad. Solo el personal de la unidad de negocio correspondiente puede
ocuparse de esta tarea. Cuando se aplica la modalidad de externalizacin
de servicios y operaciones de TI, este requisito resulta obvio, pero cuando
esos servicios y operaciones se suministran a nivel interno, se suele caer
en el error de considerar que los datos pertenecen al rea de TI y que esta
rea es la responsable de preservar la confidencialidad e integridad de la
informacin. Para tomar el control de la informacin, se debe realizar
una evaluacin de valores que permita calcular el costo potencial de la
prdida de la integridad de los datos y contemple las prdidas econmicas
directas (por ejemplo, en caso de fraude o problemas operativos graves),
los gastos judiciales y el perjuicio causado a la reputacin de la empresa.
2.
Controlar los derechos y privilegios de acceso. Los principios de necesidad

de conocer (need to know, NtK) y mnimos privilegios (least privilege, LP)
constituyen prcticas eficaces y no son, en teora, difciles de aplicar. El
crecimiento de las redes sociales y la nocin de que todos somos
productores de informacin exigen mayor amplitud y voluntad de
intercambio. Es necesario formalizar, documentar, revisar y auditar
regularmente los procesos de solicitud, modificacin y eliminacin de
derechos de acceso. La acumulacin de privilegios (cuando una persona
mantiene privilegios histricos al cambiar de responsabilidades) supone un
grave riesgo para la empresa y podra afectar la segregacin correcta de
funciones. Es comn en las organizaciones, no llevar un inventario
completo y actualizado sobre quin accede a qu, ni se posee una lista
completa de los privilegios de usuario. Varios proveedores ofrecen
productos capaces de obtener automticamente toda la informacin
relacionada con esos privilegios.
Cuando un usuario est en condiciones de omitir los procedimientos de
control de cambios, existe el riesgo de que se produzcan daos serios.
Las unidades de negocio que cuenten con administradores y/o
programadores de bases de datos a cargo de la gestin de las aplicaciones
deberan, al menos, mantener un registro que consigne quines tienen
acceso a qu datos, adems de asegurarse de que se mantengan y revisen
los registros de cambios. Cuando el tipo de tecnologa empleada admita el
uso compartido de contraseas privilegiadas, se debera evaluar la
posibilidad de utilizar herramientas que identifiquen claramente a toda
48

persona que acceda a las instalaciones, registren la fecha y hora de

acceso, y sealen los cambios realizados.
3.
Segregacin de funciones (SoD). Este es un concepto de probada eficacia

prctica, en el que seguramente harn hincapi las auditoras internas
cuando se revisen sistemas y transacciones de carcter confidencial. Este
concepto se enfrenta con la presin permanente para reducir costos y
personal en las organizaciones, que puede suponer un riesgo para el
negocio.
Responsabilidades de los equipos de apoyo de TI y usuarios finales: quien se

ocupe de suministrar sistemas informticos y servicios tecnolgicos (una unidad
de negocio, el departamento de TI de la empresa, el proveedor de servicios de
externalizacin, etc.) deber demostrar que se estn tomando las medidas
adecuadas - como las que se definen en los procedimientos de Manage data
(Gestin de datos) de la seccin DS11 de COBIT - para alcanzar un grado de
desarrollo apropiado y que se est realizando una correcta medicin y supervisin
de rendimiento y riesgos, con la consiguiente elaboracin de los informes
pertinentes.
Los equipos de apoyo de usuarios finales (tanto los que integran el rea de TI
como los que operan de forma independiente) suelen ser los responsables de la
creacin de cuentas y credenciales de acceso a los sistemas y datos. Estas
cuentas y credenciales deben estar plenamente documentadas y solo debern ser
utilizadas cuando se hayan concedido formalmente las autorizaciones pertinentes.
Responsabilidades de la Auditora Interna: los auditores se ocupan de realizar
evaluaciones independientes y objetivas para determinar en qu medida se han
definido y respetado las responsabilidades de las unidades de negocioy del equipo
de TI respecto de la preservacin de la integridad de los datos.
Desequilibrios en las Responsabilidades de Aseguramiento y Preservacin de la
Seguridad de la Informacin: el aseguramiento de la informacin (IA) consiste en
la gestin de riesgos relacionados con el uso, el procesamiento, el
almacenamiento y la transmisin de informacin o datos, y con los sistemas y
procesos empleados en la realizacin de esas actividades. El IA se desarroll a
partir de la implementacin de la seguridad de la informacin, que, a su vez, surgi
como resultado de las prcticas y los procedimientos vinculados a la seguridad
informtica.
Los proveedores de servicios (como las organizaciones de TI y las empresas
dedicadas a la externalizacin de servicios) tienen una clara responsabilidad
respecto del control de las tecnologas y su funcionamiento, y deben aplicar las
medidas necesarias para preservar la confidencialidad, integridad y disponibilidad
(confidentiality, integrity, availability o CIA) de la informacin en un entorno
operativo. En cuanto a la proteccin de los datos, los servicios proporcionados
abarcan la realizacin de copias de respaldo y la implementacin de procesos de
49

recuperacin ante desastres con objetivos claramente definidos para la

recuperacin a un momento dado (identificacin de la cantidad de datos perdidos
en un incidente) y documentados en acuerdos de nivel de servicio (service level
agreements, SLA). Por otro lado, los proveedores de servicios no son
responsables del gobierno de datos ni de las diversas actividades relacionadas
con este proceso.
Los SLA definen claramente las responsabilidades de los proveedores de servicios
de TI, pero no se ocupan de las que deben asumir los propietarios de los
sistemas. Esto produce cierta confusin respecto de las distintas
responsabilidades e impide verificar si los datos estn clasificados correctamente,
y si las funciones y responsabilidades de los usuarios de datos y, en particular, de
los usuarios con acceso privilegiado se adecuan a la funcin crtica que cada uno
desempea. Por consiguiente, la integridad de los datos sigue siendo el aspecto
ms relegado de la seguridad y el aseguramiento de la informacin.
Medicin de la Integridad de los Datos
Existen muy pocas publicaciones sobre mediciones clave, rendimiento e
indicadores clave de riesgo aplicados a la integridad de los datos en un contexto
relacionado con la seguridad de la informacin. A continuacin se mencionan
algunos puntos que pueden resultar tiles para comenzar:
1.
Un inventario de los derechos de acceso privilegiado, que indique quin

tiene acceso a qu informacin? , quin tiene autorizacin para hacer
qu?, y en qu fecha se revis y actualiz por ltima vez un documento?
2.
Un inventario de los datos que es posible extraer, transformar y cargar en

otro sistema.
3.
El nmero de usuarios que han mantenido derechos y privilegios de acceso

histricos.
4.
El nmero de cuentas hurfanas o inactivas.
5.
El nmero de sistemas de aplicacin que contienen derechos de acceso

mediante codificacin rgida o cdigos ocultos (backdoors).
6.
El nmero de veces que fue necesario acceder a los datos de produccin

para realizar modificaciones o correcciones.
7.
El nmero o porcentaje de accesos y/o cambios no autorizados a los datos

de produccin, que se hubieren identificado.
8.
El nmero de problemas de seguridad relacionados con los datos (en un

ao/un mes).
50

9.
El nmero de sistemas que la solucin IAM corporativa principal no cubre.
10.
Un ndice de datos incorrectos o incoherentes.
11.
El porcentaje del modelo de datos de la empresa (o aplicacin crtica) que

se ha cubierto con medidas destinadas a preservar la integridad.
12.
El nmero de medidas incluidas en bases de datos y aplicaciones para

detectar discrepancias en los datos.
13.
El nmero de medidas aplicadas para detectar el acceso no autorizado a

los datos de produccin.
14.
El nmero de medidas aplicadas para detectar el acceso no autorizado a

los SO.
15.
El nmero de medidas aplicadas para detectar las modificaciones que no

han estado sujetas a ningn procedimiento de control de cambios.
16.
El valor anual de las prdidas econmicas ocasionadas por operaciones de

fraude a travs de sistemas informticos.
17.
La cantidad de ataques destinados a destruir la integridad de los datos en

los sistemas de SCADA.
18.
La cantidad de comunicados de prensa generados a partir de los problemas

que afectaron la integridad de los datos.
La Importancia del Gobierno de Datos

El gobierno de datos se centra especficamente en los recursos de informacin
que se procesan y difunden. Los elementos clave del gobierno de datos pueden
clasificarse en seis categoras bsicas: accesibilidad, disponibilidad, calidad,
coherencia, seguridad y verificabilidad (mediante auditoras) de los datos.
aprendizaje ptimo.
Generar hashing y verificacin de integridad de archivos. - kalerolinex
Link:https://www.youtube.com/watch?v=wmzKE_qxTVc
George Stromeyer: Entrevista Exclusiva al VP Worldwide Security de
CISCO - cxocommunity
Link:https://www.youtube.com/watch?v=2XE5pCfbFZE
51

Leccin 14: No repudio

El no repudio es el proceso que garantiza que el emisor no pueda negar lo que
hizo. No repudio equivale al trmino de Aceptacin y es una de las
caractersticas ms difciles de garantizar.
Ejemplo: En una firma electrnica de documentos, el emisor no podr negar que
l firm o cifr el documento envado.
Cuando se recibe un mensaje no slo es necesario poder identificar de forma
unvoca al remitente, sino que ste asuma todas las responsabilidades derivadas
de lainformacin que haya podido enviar. En este sentido es fundamental impedir
que el emisor pueda repudiar un mensaje, es decir, negar su autora sobre l.
Entre sus caractersticas est:
Comprobar la creacin y origen de los contenidos.
Poseer documentos que acrediten el envo o recepcin de mensajes.
Comprobar el envo o recepcin de llamadas, etc.
El concepto de no repudio supone una medida de seguridad en las
comunicaciones a travs de la Red, proporcionando plena eficacia jurdica a una
transaccin electrnica. Jurdicamente, aporta valor probatorio a un tercero
respecto a la realizacin y envo de una comunicacin especfica dirigida a una
determinada persona.
52

Figura 8: Esquema de firma de un mensaje o documento. Fuente:

http://www.montejo.biz
aprendizaje ptimo.
Avances en criptologa y seguridad de la informacin - Benjamn Ramos Alvarez
Link:http://books.google.com.co/books?id=ibSu6896I_YC&pg=PA584&dq=
no+repudio&hl=es&sa=X&ei=KLYHUsCPGsa6yQGQ_oGIAQ&ved=0CC4Q
6AEwAA#v=onepage&q=no%20repudio&f=false
Seguridad de la informacin: redes, informtica y sistemas de informacin - Javier

Areitio Bertoln
Link:http://books.google.com.co/books?id=_z2GcBD3deYC&pg=PA384&dq
=no+repudio&hl=es&sa=X&ei=KLYHUsCPGsa6yQGQ_oGIAQ&ved=0CD0
Q6AEwAw#v=onepage&q=no%20repudio&f=false
Leccin 15:Protocolos Seguros

53

Suponiendo un aseguramiento de las redes privadas para evitar que un intruso

ingrese a ellas para robar, modificar o destruir informacin; se presenta otro
inconveniente y es que nuestros datosse transportan por Internet, donde
cualquiera puede interceptarlos y/o modificarlos.
Para evitar esohemos visto cmo cifrar nuestros datos, usando algoritmos de
encriptacin y funciones hash.
Tambin hemos visto cmo podemos garantizar la identidad de las partes y la
integridad de losmensajes, usando las firmas y los certificados digitales.
Los protocolos seguros aprovechan funcionalidades de cifrado, de forma
automtica, sin necesidad de laintervencin del usuario.
El uso de estos protocolos es muy importante, ya que ofrecen unos servicios
decomunicaciones basados en la seguridad, no as como los protocolos habituales
deInternet, que son inseguros en s mismos. El uso de estos protocolos aporta
algo de gran valor, seguridad en el trnsito de la informacin.
El objetivo de los protocolos seguros es aportar seguridad en el trnsito, de forma
transparente al usuario.
Seguridad a distintos niveles.
Como los protocolos de comunicaciones se organizan en distintos niveles
(estndar OSI), sepueden implementar distintos protocolos seguros, a diferentes
niveles. De esta manera, tenemosprotocolos seguros de nivel de red, de nivel de
transporte y de nivel de aplicacin.
En el caso de las redes locales (nivel de enlace de datos y nivel fsico),
normalmente no seusan protocolos seguros, ya que se supone que la red local
est protegida,salvo en el caso de las redes inalmbricas, que como s pueden ser
interceptadas, incorporanprotocolos seguros a nivel de enlace de datos.
Los protocolos de seguridad habituales son los siguientes:
1.
A nivel de red: IPSec (IP Security, o seguridad IP).

o Versin segura del protocolo IP, que protege el trfico entre
extremos.
Permite generar, antes de empezar la comunicacin,
asociaciones seguras entreemisor y receptor, una especie de
tnel entre los extremos por donde la informacinviajar de
forma segura.
o La seguridad se aporta mediante la encriptacin de la informacin.
54

2.
A Nivel de Transporte: SSL (Secure Sockets Layer, o capa de seguridad de

Sockets).
La ltima versin del protocolo se denomina TLS (Transport Layer
Security, o seguridad en capa de transporte). Si bien, por costumbre,
se le suele seguir llamando SSL.
Trabaja en el nivel de transporte, por encima de TCP. Ofrece a los
protocolos de la capa de aplicacin un transporte de mensajes
seguro, que incluye autenticacin y privacidad en el transporte,
gracias al empleo de tcnicas de cifrado y de certificacin
electrnica.
A nivel de aplicacin: Hay diversos protocolos seguros, segn a qu
aplicacin sedediquen. Los ms conocidos son HTTPS y SSH.
HTTPS (HyperText Transfer Protocol Secure o http seguro):
Es la versin segura del protocolo http, que es el que se utiliza

en las transacciones web. Utiliza el protocolo de transporte
SSL, en vez de directamente TCP.
Aporta identificacin, confidencialidad e integridad. Es decir,
nos garantiza dos cuestiones de vital importancia:
o Que la pgina web con que estamos conectados es
autntica, es quien dice ser, no es un usurpador o
falsificador de la identidad de otro.
o Que la informacin intercambiada durante la conexin a
dicha pgina viajar encriptada entre el cliente y el
servidor, de forma que se garantice la integridad y la
confidencialidad de la informacin transmitida.
Es el protocolo utilizado en transacciones comerciales o
legales (comercioelectrnico, banca online, administracin
online...).
SSH (Secure Shell, o intrprete de comandos seguro):
Es la versin segura del protocolo TELNET. Sirve para realizar

conexiones de terminal remotas en una mquina, pero de
forma segura.
Aporta la misma seguridad que el protocolo https, ya que
tambin utiliza el protocolo SSL, en vez de TCP.
SFTP (Secure FTP, o FTP seguro):

Es una versin del protocolo FTP5 (File Transport Protocol, o
protocolo detransporte de ficheros), basada en SSL, en lugar de en
TCP. Aporta cifrado dedatos, por lo que la validacin de usuarios
(username y clave) y los mensajestransferidos, circulan cifrados por
55

la red.
Protocolos de correo seguro:
No existe un protocolo concreto que implemente seguridad en el correo,
peropuede usarse lo siguiente:
Webmail basado en https.
Los protocolos IMAP4 y POP36 tienen posibilidad de funcionar sobre SSL,
lo que les aporta seguridad en el transporte.

aprendizaje ptimo.
Informatica Redes 006 Cisco Ccna Modelos Osi y TCP IP - Arumadigital
Link:https://www.youtube.com/watch?v=JmF2FMsMYMA
56

UNIDAD 2
Nombre de la Unidad
Introduccin
Aplicaciones seguras
Es necesario la proteccin de las aplicaciones que nos
permiten el intercambio de datos con servidores en
nuestro trabajo cotidiano. SSH es un ejemplo de una
aplicacin de proteccin que permite que los datos se
transmitan cifrados. A su vez, SSH tambin permite
encapsulamiento de conexiones TCP a cualquier puerto.
Otra aplicacin que hoy en da amerita su proteccin en
cualquier organizacin debido a lo crtica que se ha vuelto,
es el correo electrnico. Con los mecanismos de
proteccin adecuados se puede propender por la
confidencialidad
(nadie
diferenteal
destinatario
legtimopodr ver el contenido de los mensajes) y por la
autenticidad (los destinatarios podrn comprobar que
nadie ha falsificado el mensaje). Las diferentes versiones
de correo electrnico normalmente utilizan las firmas
digitales para brindar el servicio de autenticacin de
mensaje.
Una particularidad del correo electrnico seguro respecto
a otras aplicaciones como SSH es que la proteccin se
realiza preferentemente sobre los mensajes enviados,
ms que sobre los protocolos de comunicacin utilizados.
Justificacin
Hoy en da, la evolucin de las tecnologas se han

extendido a la gran red de redes, Internet. Esta evolucin
ha hecho que se amplie la productividad de los usuarios
pero tambin que se ample el campo de accin para los
ataques cibernticos contra la informacin.
Lo anterior genera una gran cantidad de problemas de
seguridad y es por eso que a diario uno de los aspectos
ms importantes es la disponibilidad, confidencialidad e
integridad de la informacin.
Esta unidad le brinda la posibilidad al estudiante de
adquirir los conocimientos indispensables para permitirle
implementar seguridad en sus actividades cotidianas en
Internet.
Intencionalidades
Con el estudio de esta unidad se busca alcanzar entre

57

Formativas
otros, los siguientes objetivos:
Conocer el mecanismo general de funcionamiento

del protocolo SSH y las principales aplicaciones que
lo utilizan.
Comprender las funciones de seguridad que pueden

proporcionar los sistemas de correo electrnico
seguro y los mecanismos para alcanzarlas.
Identificar el estndar S/MIME como aplicacin de la

especificacin MIME al correo seguro.
Captulo 4
Leccin 16
Leccin 17
Leccin 18
Leccin 19
Leccin 20
Captulo 5
Leccin 21
Leccin 22
Leccin 23
Leccin 24
Leccin 25
Captulo 6
Leccin 26
Leccin 27
Leccin 28
Leccin 29
Leccin 30
Conocer el mtodo de representacin de

informacin segura en PGP y el modelo de
confianza mutua del sistema PGP.
El protocolo SSH
Caractersticas del protocolo SSH
Tneles a nivel de transporte
La capa de transporte SSH
Ataques contra el protocolo SSH
Aplicaciones que utilizan el protocolo SSH
Correo electrnico seguro
Seguridad en el correo electrnico
Autenticacin de mensaje
Compatibilidad con los sistemas de correo no seguro
S/MIME
PGP y OpenPGP
Proteccin del nivel de transporte y Redes privadas
virtuales
Caractersticas del protocolo SSL/TLS
El transporte seguro SSL/TLS
Ataques contra el protocolo SSL/TLS
Aplicaciones que utilizan SSL/TLS
Definicin, tipos y configuraciones de VPN
58

CAPITULO 4: EL PROTOCOLO SSH

Introduccin
SSH es una de las aplicaciones que utilizan tcnicas de seguridaden las
comunicaciones para proteger los datos intercambiados.
Un ejemplo de aplicaciones que hay que proteger son las que permiten
establecersesiones de trabajo interactivas con un servidor remoto. SSH es una
aplicacin de este tipo, que definesu propio protocolo para que los datos de la
aplicacin se transmitan cifrados.
El mismo protocolo proporciona tambin mecanismos de autenticacindel servidor
frente al usuario, y del usuario frente al servidor. Como veremos,el protocolo SSH
se puede utilizar para otras aplicaciones aparte de lassesiones interactivas, ya que
permite el encapsulamiento de conexiones TCP acualquier puerto dentro de una
conexin SSH.
59

Leccin 16: Caractersticas del protocolo SSH

SSH proporciona servicios de seguridad equivalentes a los del protocolo SSL/TLS.
Confidencialidad. SSH sirve para comunicar datos, que habitualemente sonla
entrada de una aplicacin remota y la salida que genera, o bien la informacinque
se transmite por un puerto redirigido y la confidencialidad de estos datos se
garantiza mediante el cifrado.
Como en el caso del protocolo SSL/TLS, en SSH se aplica un cifrado simtricoa
los datos y por lo tanto, ser necesario realizar previamente un intercambioseguro
de claves entre cliente y servidor. Una diferencia respecto a SSL/TLSes que en
SSH2 se pueden utilizar algoritmos de cifrado distintos en los dossentidos de la
comunicacin.
Un servicio adicional que proporciona SSH es la confidencialidad de la
identidaddel usuario. Mientras que en SSL 3.0 y TLS 1.0, si se opta por
autenticaral cliente, ste tiene que enviar su certificado en claro, en SSH (y
tambinen SSL 2.0) la autenticacin del usuario se realiza cuando los paquetes ya
semandan cifrados.
Por otro lado, SSH2 tambin permite ocultar ciertas caractersticas del
trficocomo, por ejemplo, la longitud real de los paquetes.
Autenticacin de entidad. El protocolo SSH proporciona mecanismos
paraautenticar tanto el equipo servidor como el usuario que se quiere conectar.
La autenticacin del servidor suele realizarse conjuntamente con el intercambiode
claves. En SSH2 el mtodo de intercambio de claves se negocia entreel cliente y
el servidor, aunque actualmente slo hay uno definido, basado enel algoritmo de
Diffie-Hellman.
Para autenticar al usuario existen distintos mtodos; dependiendo de cul
seutilice, puede ser necesaria tambin la autenticacin del equipo cliente,mientras
que otros mtodos permiten que el usuario debidamente autenticadoacceda al
servidor desde cualquier equipo cliente.
Autenticacin de mensaje. Igual que en SSL/TLS, en SSH2 la autenticidadde los
datos se garantiza aadiendo a cada paquete un cdigo MAC calculadocon una
clave secreta. Tambin existe la posibilidad de utilizar algoritmosMAC distintos en
cada sentido de la comunicacin.
Igual que SSL/TLS,
criteriosadicionales:
SSH
tambin
est
diseado
con
los
siguientes
60

Eficiencia. SSH contempla la compresin de los datos intercambiados parareducir

la longitud de los paquetes. SSH2 permite negociar el algoritmo quese utilizar en
cada sentido de la comunicacin, aunque solamente existe unodefinido en la
especificacin del protocolo. Este algoritmo es compatible conel que utilizan
programas como gzip (RFC 19501952).
A diferencia de SSL/TLS, en SSH no est prevista la reutilizacin de claves
desesiones anteriores: en cada nueva conexin se vuelven a calcular las claves.
Esto es as porque SSH est pensado para conexiones que tienen una
duracinms o menos larga, como suelen ser las sesiones de trabajo interactivas
conun equipo remoto, y no para las conexiones cortas pero consecutivas, queson
ms tpicas del protocolo de aplicacin HTTP (que es el que inicialmentese quera
proteger con SSL). De todas formas, SSH2 define mecanismos paraintentar
acortar el proceso de negociacin.
Extensibilidad. En SSH2 tambin se negocian los algoritmos de cifrado,
deautenticacin de usuario, de MAC, de compresin y de intercambio de
claves.Cada algoritmo se identifica con una cadena de caracteres que representa
sunombre. Los nombres pueden corresponder a algoritmos oficialmente
registrados,o bien a algoritmos propuestos experimentalmente o definidos
localmente.
Adaptacin de SSH a idiomas locales. Por otro lado, SSH2 facilita la adaptacin
de las implementaciones a los idiomas locales.
Donde el protocolo prev la transmisin de un mensaje de error o informativoque
pueda ser mostrado al usuario humano, se incluye una etiqueta que identifica
elidioma del mensaje, de acuerdo con el RFC 1766.
Tanto estos mensajes como los nombres de usuario se representan con el juego
decaracteres universal ISO/IEC 10646 mediante la codificacin UTF-8, de acuerdo
conel RFC 2279 (el cdigo ASCII es un subconjunto porque en UTF-8 los
caracteres concdigo menor a 128 se representan con un solo byte, de valor igual
al cdigo).
61

Leccin 17: Tneles a nivel de transporte

El protocolo SSH (Secure Shell), ofrece la posibilidad de redirigirpuertos TCP
sobre un canal seguro, que podemos considerar como un tnel a nivel de
transporte. Desde este punto de vista, tambin se podra consideraruna conexin
SSL/TLS como un tnel a nivel de transporte que proporcionaconfidencialidad y
autenticacin. Habitualmente, este ltimo tipo de tnel nosirve para cualquier tipo
de trfico si no solamente para datos TCP, y por tantono se considera parte
integrante de una VPN.
A continuacin se explicar el uso de estos tneles bajo tecnologas UNIX.
Una de las ventajas que nos brinda SSH, es la posibilidad de crear tneles locales
y remotos.
Usando Tneles Locales
La sintaxis para crear un tnel local es:
ssh -L [puerto_local]:localhost:[puerto_remoto] servidor_remoto
Un claro ejemplo y muy sencillo para comprender, es que tengamos un servidor
Web y necesitemos visualizar alguna pgina protegida por el servidor (por los
archivos .htaccess). El problema en las pginas protegidas mediante ste mtodo
radica en que cada vez que ingresamos un usuario y contrasea, stas viajan por
la red como texto plano y puede ser interceptada por algn tercero. Usando
tneles SSH podemos controlar este problema, ya que todos los datos viajan
encriptados y seguros.
Para redireccionar el puerto que escucha el servidor web remoto a nuestro equipo,
ejecutamos:
ssh -L 10080:localhost:80 usuario@servidor-web-remoto.com
El parmetro -L nos permite realizar el tnel a travs de un puerto local. Con esto,
ya tenemos creado un tnel entre el puerto 10080 de nuestra computadora y el
puerto 80 que atiende el servidor Web remoto. Si tecleamos en el navegador web
http://localhost:10080 podremos acceder sin problemas al servidor web remoto
con la seguridad de que todos los datos viajan encriptados.
Usando Tneles Remotos
La sintaxis es la siguiente:
62

ssh -R [puerto_remoto]:localhost:[puerto_local] terminal_remoto

Siguiendo con el ejemplo antes mencionado, imaginemos un servidor Web
escuchando el puerto 80 y deseamos que una computadora remota pueda tener
acceso al puerto del servidor web y en ste caso, nos encontramos del lado del
servidor. Para realizar el tnel remoto ejecutamos:
ssh -R 10080:localhost:80 usuario@pc-cliente-remoto
Usando el parmetro -R podremos crear tneles remotos desde el puerto del
servidor.
Figura 9: Modelo de comunicacin

http://marronetis.blogspot.com
con
tnles
SSH.-
Fuente

aprendizaje ptimo.
Ejemplo de Uso de SSH Secure Shell - Julio Snchez
Link:https://www.youtube.com/watch?v=qI9DZmRKgHQ
63

Leccin 18: La capa de transporte SSH

De la misma forma que en SSL/TLS se distinguen dos subcapas en el nivel de
transporte seguro, en SSH tambin se puede considerar una divisin endos
subniveles. Adems, en SSH2 el nivel superior est estructurado en
tresprotocolos, uno por encima del otro, como muestra la siguiente figura:
Figura 10: Estructura

http://www.uoc.edu
de
la
capa
de
transporte
SSH.-
Fuente
64

Leccin 19: Ataques contra el protocolo SSH

Muchas de las consideraciones sobre la proteccin que proporciona SSL/TLSson
aplicables tambin al protocolo SSH. Este protocolo est diseado paraque un
atacante no pueda leer el contenido de los mensajes ni alterarlos, ytampoco
cambiar la secuencia de los mismos.
La confidencialidad queda garantizada con el mtodo de intercambio de
clavesbasado en criptografa de clave pblica, que protege contra los ataques del
hombre en el medio.
Adems, este mtodo permite que el cliente se asegure de que se est
conectandoal servidor autntico. Para comprobar que la clave pblica que enva
elservidor es realmente la suya, se pueden usar certificados, o bien una base
dedatos local del cliente en la que estn guardadas las claves de los
servidoresreconocidos. Y para autenticar al usuario mediante una clave pblica (la
suyao la del cliente desde el cual se conecta, dependiendo del mtodo de
autenticacin),tambin existen las dos opciones: certificados o una base de datos
declaves en el servidor.
Si no se usan certificados, el protocolo contempla la posibilidad (aunque nose
recomienda) de dar por buena la clave pblica de un servidor la primeravez que se
establezca una conexin, sin necesidad de ninguna comunicacinprevia. Esto no
es apropiado en un entorno donde la seguridad sea crtica,porque representa una
vulnerabilidad a ataques de hombre en el medio.
En otros entornos, y mientras no se disponga de una infraestructura de
clavesampliamente extendida, aceptar directamente claves recibidas por primera
vezpuede suponer un equilibrio entre comodidad de uso y seguridad.
Una caracterstica interesante aadida a SSH2 es que las longitudes de los
paquetesse envan cifradas. Un atacante que vea los datos intercambiados
comoun flujo de bytes no puede saber dnde empieza y dnde acaba cada
paqueteSSH2 (si tiene acceso al nivel de paquetes TCP puede intentar hacer
deducciones,pero sin una certeza absoluta). Esto, conjuntamente con la
posibilidad deincluir padding arbitrario (hasta 255 bytes) y enviar mensajes
IGNORE, puedeservir para ocultar las caractersticas del trfico y dificultar los
ataques contexto claro conocido.
Por otra parte, merece la pena sealar que los mtodos de autenticacin
deusuario mediante listas de acceso se basan en la confianza del servidor en
eladministrador del sistema cliente (del mismo modo que los protocolos rsh
yrlogin):
Cuando no se autentica el sistema cliente (posibilidad contemplada

solamente en SSH1), el servidor slo tiene que aceptar conexiones que
65

provengan de un puerto TCP privilegiado (menor que 1024) para que a un

usuario cualquiera no le sea fcil enviar paquetes suplantando la identidad
de otro.
Cuando hay autenticacin del sistema cliente, el servidor confa que los
usuarios no tendrn acceso a la clave privada de este sistema, porque si no
podran utilizarla para generar mensajes de autenticacin con la identidad
de otro usuario.
Finalmente, igual que pasa con SSL/TLS, el protocolo SSH est diseado
paraofrecer determinadas protecciones, pero el nivel de seguridad que
proporcione en cada caso vendr dado por las implementaciones y por el uso que
se hagadel mismo.
Se recomienda que se puedan deshabilitar o restringir las caractersticas(mtodos
de autenticacin de usuario, redireccin de puertos TCP,etc.) que en un
determinado entorno impliquen alguna vulnerabilidad o posibilidadde abuso.

aprendizaje ptimo.
Ataque SSH - Verandir Araujo
Link:https://www.youtube.com/watch?v=Wswx3harxsk
66

Leccin 20: Aplicaciones que utilizan el protocolo SSH

Dado que el objetivo principal de SSH es permitir la ejecucin remota de
procesosal estilo de los programas rsh y rlogin, se pueden implementar, y dehecho
se han implementado, otros programas (por ejemplo ssh y slogin)que hagan lo
mismo, pero utilizando el protocolo SSH.
Los argumentos pueden ser los mismos: el nombre del servidor, -l usuariopara
especificar el nombre de usuario en el servidor, etc. Los programas
tambinpueden estar configurados para utilizar distintos mtodos de
autenticacin:el basado en los ficheros .rhosts y /etc/hosts.equiv funcionacomo en
rsh/rlogin, y el basado en contrasea funciona como en rlogin.
Si se utiliza autenticacin del sistema cliente ser preciso guardar su clave
privadaen algn lugar de acceso restringido. Y si la autenticacin de usuarioest
basada en su clave pblica, la clave privada correspondiente se deberguardar
protegida, normalmente cifrada con una clave simtrica derivada deuna
contrasea o de una passphrase.
La implementacin original del programa ssh, en sus distintas versiones,
admiteargumentos de la forma -L p1:adr:p2 y -R p1:adr:p2 paraespecificar
redirecciones TCP del puerto local (del cliente) o remoto (del servidor)p1,
respectivamente, al puerto p2 del computador adr.
Ejemplos de redireccin de puertos TCP con SSH
1. Desde un computador llamado cerca podemos hacer:
ssh -L 5555:srv.lejos.com:23 -l admin medio
Si nos autenticamos correctamente, habremos establecido una conexin
interactivacon el computador medio como usuario admin, y adems,
cualquier conexin alpuerto 5555 de cerca, como sta:
telnet cerca 5555
estar redirigida al puerto 23 (TELNET) del computador srv.lejos.com
(pasandopor medio, y con el tramo entre cerca y medio protegido con SSH).
2. sta sera una forma de proteger una conexin a un servidor HTTP
mediante untnel SSH, suponiendo que podamos autenticarnos ante este
servidor:
67

ssh -L 5678:localhost:80 www.lejos.com

Un vez realizada esta operacin, podemos introducir la direccin
http://localhost:5678/
en cualquier navegador web del computador local, y nos llevar
automticamente ala direccin http://www.lejos.com/ con una conexin
cifrada (y si en estadireccin existe una pgina HTML con referencias no
absolutas a pginas delmismo servidor, estas otras pginas tambin nos
llegarn a travs de SSH).

aprendizaje ptimo.
Conectar BackTrack5 r3 desde VMware a Windows con Putty (Protocolo SSH) C1b3rKr1m3n
Link:https://www.youtube.com/watch?v=qMlIKnjvThE
68

CAPITULO 5: CORREO ELECTRNICO SEGURO

Introduccin
El correo electrnico es una de las aplicaciones ms utilizadas en las redes
decomputadores. En el caso de Internet, el protocolo sobre el que se sustentala
transferencia de mensajes, el SMTP, fue publicado en el estndar RFC 821en
1982. Como su nombre lo indica, la principal caracterstica de este protocolo es su
simplicidad. Esto ha permitido que el SMTP, junto con el estndar parael formato
de los mensajes (RFC 822) y la especificacin MIME, sean la basetecnolgica de
la gran mayora de los sistemas de correo actuales.
Esta gran virtud del SMTP, la simplicidad, es a su vez una fuente de
muchosproblemas de seguridad, ya que a un atacante puede resultarle
sorprendentementefcil capturar mensajes o enviar mensajes falsos en nombre de
otros.
En este captulo veremos algunas tcnicas existentes para aadir seguridad
alservicio de correo electrnico.
Si consideramos el correo electrnico como un protocolo de la capa de
aplicacin,una posibilidad para proteger los mensajes de correo sera utilizar
laseguridad que pueden ofrecer las capas inferiores, como la de red o la de
transporte.
Por ejemplo, con el protocolo SMTP se puede negociar el uso del
transporteseguro SSL/TLS, mediante un comando especial llamado
STARTTLS(RFC 2487).
Pero en la transferencia de los mensajes pueden intervenir distintos
agentesintermedios, y para realizar la comunicacin segura de extremo a
extremosera necesario proteger todos los enlaces o intentar hacer una conexin
directaentre el sistema del originador y los de los destinatarios. Por otro lado,la
naturaleza store-and-forward (almacenamiento y reenvo) del servicio decorreo
electrnico implica que los mensajes sean vulnerables no slo cuandose
transfieren de un nodo intermedio a otro, sino tambin mientras estn
almacenadosen estos nodos. Esto incluye el sistema de destino final: una vez
elmensaje ha llegado al buzn del usuario, su contenido puede ser
inspeccionadoo modificado por terceros antes de que lo lea el destinatario
legtimo, o inclusodespus de que ya lo haya ledo.
69

Leccin 21: Seguridad en el correo electrnico

Cuando se aaden servicios de seguridad al correo electrnico es preciso teneren
cuenta las siguientes consideraciones:
En el correo electrnico la transmisin de mensajes se lleva a cabo de manerano
interactiva, y por lo tanto no puede haber negociacin de algoritmoso intercambio
de claves cuando se enva un mensaje. Esto significa queposiblemente ser
necesario un paso adicional para obtener la clave requeridapara comunicarse con
un determinado corresponsal (consultar unabase de datos de claves pblicas,
pedir al usuario que enve su clave, etc.).
Todos los sistemas de correo seguro deben prever algn mecanismo de
distribucinde claves.
Una funcionalidad bsica del correo electrnico es el envo de un mismo mensaje
a mltiples destinatarios. Con el correo seguro, si es precisoutilizar parmetros
criptogrficos distintos para cada destinatario, unasolucin poco eficiente sera
efectuar envos separados. Pero si queremosaprovechar las capacidades de los
sistemas de correo existentes, debemosutilizar una tcnica que permita combinar
en un solo mensaje toda la informacinnecesaria para que pueda ser procesada
por cada uno de los destinatarios.
Los servicios que proporcionan los sistemas de correo electrnico seguro
sonbsicamente dos:
Confidencialidad. Mediante las tcnicas de cifrado, se puede garantizar queun
mensaje slo podr ser ledo por sus destinatarios legtimos.
Autenticacin de mensaje. Los mensajes pueden incluir un cdigo de
autenticacin(un cdigoMAC o una firma digital) para que los destinatarios
puedanverificar que han sido generados por el originador autntico, y que nadie
losha modificado o falsificado.
Cada uno de estos dos servicios puede basarse en tcnicas criptogrficas declave
simtrica o de clave pblica.
Hay otros servicios queno pueden ofrecer todoslos sistemas de correoseguro:
70

Confidencialidaddel flujo de trfico (que nose sepa quin manda mensajes a quin
ycundo, y qu longitudtienen), proteccin contranegacin de recepcin(que un
usuario no puedadecir que no ha recibidoun mensaje, o que untercero no pueda
borrarmensajes para que eldestinatario no los lea) ocontra ataques derepeticin
de mensajes,etc.

aprendizaje ptimo.
Configuracin de un completo servidor de correo seguro con Postfix y
Cyrus- Jaume Sabater
Link:http://www.redes-linux.com/manuales/Servidor_correo/postfixcyrus.pdf
Servidor de correo integral seguro - Miguel ngel Poza
Link:http://www.irisnova.es/difusion/publicaciones/boletin/7475/ponencia8.pdf
71

Leccin 22: Autenticacin de mensaje

Para la autenticacin de los mensajes tambin se pueden utilizar tcnicas
simtricaso de clave pblica.
Las tcnicas simtricas consisten en aadir al mensaje un cdigo MAC,
calculadocon una clave secreta compartida con el destinatario. Esto significa
quese debe calcular un cdigo MAC distinto para cada destinatario, y adems,
queno hay proteccin contra un posible repudio por parte del originador.
Por este motivo, los sistemas de correo seguro actuales utilizan las tcnicasde
autenticacin de clave pblica, es decir, las firmas digitales.
La firma de un mensaje puede ser verificada por cualquier persona que lo reciba y
conozca la clave pblica del firmante, y hasta puede reenviar el mensajea otros
usuarios, que tambin podrn comprobar su autenticidad. Y por otrolado, las
firmas proporcionan el servicio de no repudio.
La criptografa permite asegurar la confidencialidad de un mensaje pero no su
integridad. Un atacante podra modificar (tamperear) un mensaje cifrado en
medio de la comunicacin y el receptor no tendra elementos para determinar si
esto ocurri.
Las tcnicas de encadenamiento de bloques (block-chaining), utilizadas
habitualmente en la criptografa, hacen que la tarea de modificar un mensaje no
sea tan fcil. Si todos los bloques se encuentran encadenados y dependen de los
anteriores, probablemente al realizar una modificacin estemos introduciendo
basura que no puede ser descifrada por el receptor. Sin embargo, en
determinadas condiciones puede construirse un mensaje vlido para el receptor
a partir, por ejemplo, de mensajes cifrados -previamente interceptados- que
guarden una estructura comn.
MAC (Message Authentication Code) es una tcnica destinada a autenticar
mensajes y verificar, por lo tanto, su integridad. Dado un mensaje (m) y una clave
(K), llamamos tag (T) al resultado de aplicarle al par mensaje-clave la funcin
MAC.
Para ser ms claros: T = MAC(K, m).
72

Al enviar el mensaje al receptor adjuntamos T. El receptor, quien conoce

previamente a K, realiza el mismo clculo y comprueba de esa forma si el mensaje
es autntico. Un atacante que intercepte la comunicacin no sabra, al modificar el
mensaje, cmo generar un T vlido.
Todo mensaje distinto tendr un T distinto. Al igual que ocurre con las funciones
de hash, el conjunto imagen (T) es finito y esto hace que la funcin no sea
inyectiva. Si no fuera posible generar colisiones intencionadas, no se sabra qu
bits agregar para hacer pasar un mensaje modificado por uno autntico (dado un T
conocido).

aprendizaje ptimo.
Servicios avanzados de telecomunicacin - Mara Carmen Espaa Boquera
Link:http://books.google.com.co/books?hl=es&lr=lang_es&id=yTSoYCiXYA
AC&oi=fnd&pg=PR7&dq=autenticacin+de+mensajes&ots=F2pUD3ps4&sig=1zjydrncjBZ3S77IUG0ipzKxJo#v=onepage&q=autenticacin%20de%20mensajes&f=false
73

Leccin 23: Compatibilidad con los sistemas de correo no seguro

Si queremos utilizar la infraestructura SMTP existente para el correo
seguro,debemos tener presente que este protocolo impone ciertas restricciones
paraintentar maximizar la interoperabilidad entre las implementaciones,
incluidaslas ms antiguas.
Algunas de estas restricciones son, por ejemplo, que en principio los mensajesslo
pueden contener caracteres ASCII, y que las lneas de los mensajes nopueden
tener ms de 1.000 caracteres. Actualmente muchos agentes SMTPson capaces
de trabajar sin estas restricciones pero de todas formas debemostenerlas en
cuenta porque no sabemos por que implementaciones pueden pasarnuestros
mensajes.
Adems, SMTP define una representacin para los mensajes que puede
serdistinta de la representacin local de cada sistema. El proceso que se
encargade enviar los mensajes tiene que transformarlos del formato local al
formatoSMTP en el momento de transferirlos. Y a la inversa, cuando llega un
mensajeva SMTP normalmente se convierte al formato local antes de
almacenarlo enel buzn de los destinatarios.
Ejemplos de transformacin a formato SMTP:
Un ejemplo tpico de transformacin es el de los finales de lnea: en SMTP se
representancon los caracteres <CR><LF>, mientras que en Unix se representan
solamentecon <LF>.
Otro ejemplo: algunos lectores de correo en Unix, especialmente los ms
antiguos,interpretan que en un buzn de mensajes la secuencia de caracteres
From al iniciode lnea indica el inicio de un nuevo mensaje. En estos sistemas,
cuando llega unmensaje que contiene esta secuencia al inicio de una lnea, se
aade automticamenteel carcter > delante de la lnea, (los lectores de correo
ms modernos utilizan elcampo Content-Length de la cabecera para saber dnde
termina cada mensaje ydnde empieza el siguiente).
Por lo tanto, cuando se deben aplicar operaciones criptogrficas a unmensaje, es
preciso hacerlo sobre una codificacin cannica que seaconvertible al formato
74

local de forma no ambigua.

De este modo, si tenemos que mandar un mensaje confidencial, cifraremosla
forma cannica del mensaje para que cuando el receptor la descifre
puedaconvertirla a su formato local. Y si tenemos que calcular un cdigo de
autenticacino una firma, lo haremos tambin sobre la forma cannica, para que el
receptor sepa exactamente a partir de qu datos se ha generado y puedarealizar
su verificacin.
Cada sistema de correo seguro puede definir su codificacin cannica.
Porejemplo, los sistemas basados en MIME utilizan el modelo de la
especificacinRFC 2049. En el correo multimedia las reglas de codificacin
dependen deltipo de contenido, pero en el caso de mensajes de texto, por
simplicidad, loms normal es que la codificacin cannica coincida con el formato
SMTP, esdecir, con caracteres ASCII y con lneas acabadas en <CR><LF>.
Por otra parte, existen agentes de correo que pueden introducir modificacionesen
los mensajes para adaptarlos a sus restricciones. Algunos ejemplos son:
Poner a 0 el 8avo bit de cada carcter, cortar las lneas demasiado largas
insertandofinales de lnea, eliminar los espacios en blanco al final de
lnea,convertir los tabuladores en secuencias de espacios, etc.
Dado que la informacin criptogrfica constar en general de datos arbitrarios,
debemos utilizar mecanismos de proteccin del contenido para garantizarque
ninguna de estas modificaciones afectar a los mensajes seguros. ste esel
mismo problema que se plante en el correo MIME para enviar
contenidosmultimedia, y la solucin consiste en utilizar una codificacin de
transferencia,como puede ser la codificacin base 64.
La codificacin base 64consiste en representarcada grupo de 6 bits conun
carcter ASCII de unjuego de 64 (26 = 64),formado por las letras, losdgitos y los
smbolos +y /.
75

Leccin 24: S/MIME

S/MIME (Secure MIME) es una especificacin de correo seguro basada en
lanorma PKCS #7, que fue desarrollada inicialmente por RSA Data Security.
El sistema de correo S/MIME utiliza la tcnica MIME para trasmitirmensajes
protegidos criptogrficamente segn el formato PKCS #7.
Durante los primeros aos se elaboraron distintos borradores de la
especificacinS/MIME, que fueron adoptados por varios implementadores
independientes.
Las versiones iniciales definan dos perfiles de uso: el normal, que noera
exportable fuera de los Estados Unidos, y el restringido, que impona unlmite de
40 bits secretos en las claves simtricas. Por motivos de interoperabilidad,muchos
de los sistemas S/MIME que se desarrollaron seguan el perfilrestringido.
En 1998 se publicaron los documentos informativos RFC 2311 y 2312,
querecogen las caractersticas comunes a la mayora de implementaciones que
existan entonces, en lo que se conoce como versin 2 de S/MIME. En esta
versin ya no se hace distincin entre perfil normal o restringido.
Algoritmos previstos en S/MIME versin 2
La versin 2 de S/MIME prev los siguientes algoritmos criptogrficos:
Para el cifrado simtrico: Triple DES y RC2.
Para los resmenes de mensajes (hash): MD5 y SHA-1.
Para el cifrado de clave pblica: RSA.
El estndar oficial de correo seguro S/MIME es la llamada versin 3, publicadaen
los documentos RFC 26322634, de junio de 1999. Una diferenciarespecto a
76

S/MIME versin 2 es que, en lugar de utilizar directamente el estndarPKCS #7,

se basa en el nuevo estndar CMS (RFC 2630). El CMS mantiene la
compatibilidad con PKCS #7 pero incluye nuevos mtodos parael intercambio de
claves, en particular el mtodo Diffie-Hellman (descrito enel RFC 2631).
La versin 3 est diseada en general para ofrecer la mxima
compatibilidadposible con la versin 2. De todas formas, conviene saber que la
versin 3soporta nuevos servicios, conocidos como ESS, que incluyen:
Recibos firmados.
Etiquetas de seguridad, que dan informacin sobre el nivel de sensibilidaddel
contenido de un mensaje (segn una clasificacin definida por unadeterminada
poltica de seguridad).
Listas de correo seguras.
Certificados de firma, que permiten asociar directamente una firma con
elcertificado necesario para validarla.
El formato PKCS #7
PKCS #7 es un formato para representar mensajes protegidos criptogrficamente.
Cuando la proteccin est basada en criptografa de clavepblica, en PKCS #7 se
utilizan certificados X.509 para garantizar laautenticidad de las claves.
La norma PKCS #7 define unas estructuras de datos para representar cada unode
los campos que forman parte de un mensaje. A la hora de intercambiarestos datos
se deben codificar segn las reglas especificadas por la notacinASN.1 (la misma
que se utiliza para representar los certificados X.509 y lasCRL).
sta es la estructura general de un mensaje PKCS #7, descrita con la
mismanotacin que utilizamos para los certificados (opc. significa opcional y
rep.significa repetible):
Campo
contentType
content (opc.)
Tipo
identificador nico
Data,
SignedData,
EnvelopedData,
SignedAndEnvelopedData,
DigestedData,
o EncryptedData
77

El campo contentType es un identificador que indica cul de las seis

estructurasposibles hay en el campo content. Estas estructuras son:
1) Data: sirve para representar datos literales, sin aplicarles ninguna
proteccin criptogrfica.
2) SignedData: representa datos firmados digitalmente.
3) EnvelopedData: representa un mensaje con sobre digital (es decir, un
mensaje cifrado simtricamente al que se aade la clave simtrica cifrada
con la clave pblica de cada destinatario).
4) SignedAndEnvelopedData: representa datos firmados y cerrados en un
sobre digital.
5) DigestedData: representa datos a los cuales se les aade un resumen o
hash.
6) EncryptedData: representa datos cifrados con clave secreta.
El campo content es opcional, porque en ciertos casos existe la posibilidadde que
los datos de un mensaje no estn dentro del propio mensaje, sino enalgn otro
lugar.
De estos seis posibles tipos de contenido, los tres ltimos no se utilizan
enS/MIME: para datos firmados y con sobre se utiliza una combinacin
deSignedData y EnvelopedData, y los mensajes que slo contienen datoscon
hash o datos cifrados simtricamente no se envan nunca con correo
electrnicoseguro.
Por lo tanto, los tipos de contenido PKCS #7 que puede haber en un
mensajeS/MIME son Data, SignedData o EnvelopedData.
1) El tipo Data
Si el contenido PKCS #7 es de tipo Data, no est estructurado deningn
modo especial, sino que simplemente consiste en una secuenciade bytes.
Cuando se utiliza en S/MIME, su contenido debe seruna parte de mensaje
MIME, con sus cabeceras y su cuerpo en formacannica.
El tipo Data no aparece nunca solo en un mensaje S/MIME, sino
quesiempre se usa en combinacin con alguno de los otros tipos PKCS #7,
esdecir, con SignedData o con EnvelopedData.
2) El tipo SignedData
El tipo SignedData bsicamente contiene datos, representados
recursivamentecon otro mensaje PKCS #7, y la firma de estos datos
generada poruno o ms firmantes. La estructura del contenido de tipo
SignedData esla siguiente:
78

Campo
version
digestAlgorithms(rep.)
algorithm
parameters
contentInfo
certificates (opc. rep.)
crls (opc. rep.)
signerInfos (rep.)
version
issuerAndSerialNumber
issuer
serialNumber
digestAlgorithm
algorithm
parameters
authenticatedAttributes (opc. rep.)
digestEncryptionAlgorithm
algorithm
parameters
encryptedDigest
unauthenticatedAttributes (opc. rep.)
Tipo
entero
identificador nico
(depende del algoritmo)
mensaje PKCS #7
certificado X.509
CRL
entero
DN
entero
identificador nico
atributo X.501
identificador nico
cadena de bytes
atributo X.501
El significado de cada campo es el siguiente:
El campo version indica la versin del formato de la estructura

SignedData.
El campo digestAlgorithms es una lista de los algoritmos de resumen

o hash que han utilizado los firmantes para firmar los datos.
El campo contentInfo contiene los datos que hay que firmar,

representados en forma de mensaje PKCS #7. Este mensaje
normalmenteser de tipo Data (para firmar datos literales) o de tipo
Enveloped-Data (para firmar un mensaje confidencial).
En el campo certificates hay certificados o cadenas de

certificadosque pueden ser tiles para verificar la autenticidad de las
clavespblicas de los firmantes.
79

En el campo crls aparece una lista de CRLs que se pueden usar

juntamentecon los certificados del campo anterior.
El campo signerInfos contiene una estructura para cada firmante,con

los siguientes subcampos:
o digestAlgorithm es el algoritmo de hash que ha usado este
firmante (tiene que ser uno de los que haba en el campo
digestAlgorithms del principio).
o authenticatedAttributes es un conjunto de atributos que se
aaden a los datos sobre los cuales se calcula la firma.
o digestEncryptionAlgorithm es el algoritmo con el que el
firmante ha cifrado el hash para calcular la firma.
o encryptedDigest es la firma, es decir, el hash cifrado con la
clave privada del firmante.
o unauthenticatedAttributes es un conjunto adicional de atributos
que no intervienen en la firma.
Como podemos ver, PKCS #7 permite que cada firmante aada atributosa
su firma, que pueden ser autenticados o no autenticados. Cada uno deestos
atributos sigue la estructura definida en la Recomendacin X.501,que
simplemente consta de un nombre de atributo y de uno o ms valores.
Cuando hay atributos autenticados, uno de ellos tiene que ser
obligatoriamenteun atributo llamado messageDigest, que tiene como valor
elhash del campo contentInfo. En este caso, la firma se calcula a partirdel
hash de todo el subcampo authenticatedAttributes. Deeste modo se puede
comprobar la autenticidad de los datos del mensaje(contentInfo) y del resto
de atributos autenticados.
Cuando no hay atributos autenticados, la firma se calcula simplemente
apartir del hash del campo contentInfo.
3) El tipo EnvelopedData
El tipo EnvelopedData contiene datos con sobre digital. Los
datoscorresponden recursivamente a otro mensaje PKCS #7. La estructura
delcontenido de tipo EnvelopedData es la siguiente:
Campo
version
recipientInfos (rep.)
version
issuerAndSerialNumber
issuer
serialNumber
Tipo
entero
entero
DN
entero
80

keyEncryptionAlgorithm
algorithm
parameters
encryptedKey
encryptedContentInfo
contentType
contentEncryptionAlgorithm
algorithm
parameters
encryptedContent (opc.)
identificador nico
cadena de bytes
identificador nico
identificador nico
cadena de bytes
El significado de cada campo es el siguiente:

El campo version indica la versin del formato de la estructura
EnvelopedData.
El campo recipientInfos contiene una estructura para cada destinatario

del mensaje, con los siguientes subcampos:
version indica la versin del formato de esta estructura.
issuerAndSerialNumber sirve para saber a qu destinatario
corresponde esta estructura. Cada destinatario debe buscar entre
los elementos del campo recipientInfos el que tenga este
subcampo igual a la CA y el nmero de serie de su certificado.
keyEncryptionAlgorithm indica con qu algoritmo de clave pblica
se ha cifrado la clave de sesin.
encryptedKey es la clave de sesin cifrada con la clave pblica de
este destinatario.
En el campo encryptedContentInfo hay la informacin sobre los datos

cifrados, con los siguientes subcampos:
contentType indica que tipo de mensaje PKCS #7 hay en los
datos cifrados: normalmente ser Data (cuando se cifran datos
literales) o SignedData (cuando se cifra un mensaje firmado).
contentEncryptionAlgorithm es el algoritmo simtrico con el que
se han cifrado los datos (utilizando la clave de sesin).
encryptedContent son los datos (es decir, un mensaje PKCS #7)
cifrados.
Como hemos visto, los contenidos de tipo SignedData y EnvelopedDatacontienen

recursivamente otros mensajes PKCS #7. La combinacin quese puede encontrar
en un mensaje S/MIME ser una de estas cuatro:
SignedData[Data] (mensaje con datos firmados).

SignedData[EnvelopedData[Data]] (mensaje con datos cifrados y firmados).
EnvelopedData[Data] (mensaje con datos cifrados).
81

EnvelopedData[SignedData[Data]] (mensaje con datos firmados y cifrados).
Podemos ver, por lo tanto, que si un mensaje se tiene que firmar y cifrar,
sepueden realizar las dos operaciones en cualquier orden, segn interese.
Porejemplo, firmar primero y cifrar despus permite que el destinatario guarde
elmensaje descifrado para verificaciones posteriores, posiblemente por parte
deterceros. Cifrar primero y firmar despus permite verificar la autenticidad deun
mensaje sin necesidad de descifrarlo.
Formato de los mensajes S/MIME
Un mensaje S/MIME es un mensaje MIME con las siguientes caractersticas:
Su tipo de contenido (campo Content-Type de la cabecera MIME) es

application/pkcs7-mime.
En su cuerpo hay una estructura PKCS #7 codificada segn la notacin
ASN.1.
Para los mensajes S/MIME que slo estn firmados existe una
representacinalternativa, llamada firma en claro, que veremos ms adelante.
Compatibilidad con versiones anteriores de S/MIME
Para los tipos de contenido, como pkcs7-mime y otros que veremos a
continuacin,las primeras versiones de S/MIME utilizaban nombres que
empezaban por x-.
En las versiones experimentales de algunos protocolos es habitual utilizar un
prefijocomo ste para representar valores que an no estn estandarizados. Por
compatibilidad con estas versiones, las aplicaciones de correo S/MIME deberan
tomar enconsideracin los nombres antiguos equivalentes a los nombres sin
prefijo, como porejemplo:
Nombre antiguo
x-pkcs7-mime
x-pkcs7-signature
x-pkcs10
Nombre actual
pkcs7-mime
pkcs7-signature
pkcs10
La cabecera MIME Content-Type, adems del valor application/pkcs7-mime,

debe tener al menos uno de estos dos parmetros:
smime-type: indica el tipo de contenido PKCS #7 que hay en el cuerpodel
mensaje.
name: indica un nombre del fichero asociado al contenido del mensaje.
Fichero asociado a un mensaje S/MIME
82

El parmetro name sirve para mantener la compatibilidad con las primeras

versionesde S/MIME, en las cuales no estaba definido el parmetro smime-type.
En estasversiones, la especificacin del tipo de contenido PKCS #7 se realizaba
con la extensinde un nombre de fichero. La parte del nombre que haya antes de
la extensin esindiferente, pero por convencionalmente suele ser smime.
Para especificar este nombre de fichero se puede utilizar el parmetro name de
lacabecera Content-Type, y tambin el parmetro filename de la cabecera
MIMEContent-Disposition (definida en la especificacin RFC 2183), con el valor
deesta cabecera igual a attachment.
Adems, dado que el cuerpo del mensaje son datos binarios (la
representacinASN.1 de una estructura PKCS #7), normalmente habr una
cabecera Content-Transfer-Encoding con valor base64 para indicar que estos
datosestn codificados en base 64.
Existen tres formatos bsicos de mensajes S/MIME: los mensajes con sobredigital,
los mensajes firmados y los mensajes firmados en claro.
1) Mensajes S/MIME con sobre digital
Un mensaje S/MIME con sobre digital tiene las siguientes caractersticas:
En el cuerpo del mensaje hay una estructura PKCS #7 con tipo de

contenidoEnvelopedData.
El valor del parmetro smime-type es enveloped-data.
Si se especifica un nombre de fichero asociado, su extensin es
.p7m(por ejemplo, smime.p7m).
ste es un ejemplo de mensaje S/MIME con sobre digital:

Date: Mon, 14 Jun 2013 12:10:11 -0500
From: alumno@unad.edu.co
Subject: Muestra de correo
To: profe@unad.edu.co
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDBzAgEAMC8wKjELMAkGA1UEBhMCRVMxDDAKBgNVBAoT
A1VPQzENMAsGA1UEAxMEQ0EtMQIBBjANBgkqhkiG9w0BAQEFAAQuCYHs970aZmmqKTr3gemZ
LzHVtB266O/TrIv4shSvos8Ko8mUSQGov0JSIugmeDBzAgEAMC8wKjELMAkGA1UEBhMCRVMx
DDAKBgNVBAoTA1VPQzENMAsGA1UEAxMEQ0EtMQIBBzANBgkqhkiG9w0BAQEFAAQuC14oIhps
+mh8Wxp79A81uv2ltG3vt6J9UdJQcrDL92wD/jpw1IKpoR224LT4PQAAMIAGCSqGSIb3DQEH
ATARBgUrDgMCBwQIZbTj6XqCRkGggARAF8K8apgPtK7JPS1OaxfHMDXYTdEG92QXfAdTPetA
FGuPfxpJrQwX2omWuodVxP7PnWT2N5KwE1oc6faJY/zG0AAAAAAAAAAAAAA=
2) Mensajes S/MIME firmados

Un mensaje S/MIME firmado tiene un formato anlogo al de los mensajescon
sobre digital. Sus caractersticas son:
83


contenidoSignedData.
El valor del parmetro smime-type es signed-data.
Si se especifica un nombre de fichero asociado, su extensin es la mismaque
en los mensajes con sobre digital, es decir .p7m (por ejemplo,smime.p7m).
Este es un ejemplo de mensaje S/MIME firmado:
Date: Mon, 14 Jun 2013 12:10:51 -0500
Subject: Muestra de correo 2
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAaCAJIAE
OUNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KDQpFeGVtcGxlIGRlIG1pc3NhdGdlIHNpZ25h
dC4NCgAAAAAAAKCAMIIBSDCCAQWgAwIBAgIBBjANBgkqhkiG9w0BAQQFADAqMQswCQYDVQQG
EwJFUzEMMAoGA1UEChMDVU9DMQ0wCwYDVQQDEwRDQS0xMB4XDTAwMDkwMTAwMDAwMFoXDTEw
MDkwMTAwMDAwMFowVTELMAkGA1UEBhMCRVMxDDAKBgNVBAoTA1VPQzElMCMGCSqGSIb3DQEJ
ARYWdXN1YXJpLTFAY2FtcHVzLnVvYy5lczERMA8GA1UEAxMIdXN1YXJpLTEwSTANBgkqhkiG
9w0BAQEFAAM4ADA1Ai4MNRLOaI30lrRQjyyznTjQTs/vLveiFadRiGKlVNnsFkGx/EwHdFDy
7z4CpbtnAgMBAAEwDQYJKoZIhvcNAQEEBQADLgACRZrDsL/MJv9VZdbxNMpbjKcwwFPPVG9L
TqOZ8sTdAF09UnFsSj5jE0ABAPEAADGAMIGBAgEBMC8wKjELMAkGA1UEBhMCRVMxDDAKBgNV
BAoTA1VPQzENMAsGA1UEAxMEQ0EtMQIBBjAMBggqhkiG9w0CBQUAMA0GCSqGSIb3DQEBAQUA
BC4DMwI+4fvRqBPhFj/wB7gI+Or7nSYfkqP1fxbjdTqwu9B5jsnxDIs+PUYsboQIAAAAAAAA
AAA=
3) Mensajes S/MIME firmados en claro

Cuando se enva un mensaje firmado, los receptores que utilicen un lectorde
correo apropiado podrn leer el mensaje y verificar la firma. Muchas
vecesinteresa que el mensaje pueda ser ledo por todos, aunque no se
dispongade un lector con soporte para correo seguro.
Lo que se hace en estos casos es formar un mensaje con dos partes: laprimera
se representa como un mensaje normal, que puede ser ledo porcualquier
cliente de correo, y la segunda es la firma de la primera. Unmensaje de este
tipo se llama mensaje firmado en claro.
De esta forma, quien disponga de un lector de correo seguro podr leerel mensaje
y verificar la firma, y quien utilice un lector tradicional podrigualmente leer el
mensaje, aunque no podr comprobar si la firma esautntica.
Una de las especificaciones del estndar MIME, el RFC 1847, define laforma de
aadir una firma a un mensaje MIME. El mensaje resultantetiene las siguientes
caractersticas:
El tipo de contenido del mensaje (cabecera MIME Content-Type)es

multipart/signed.
La cabecera Content-Type tiene tres parmetros obligatorios.
84

o boundary: como en todos los mensajes de tipo multipart,

esteparmetro indica el delimitador que se utiliza para separar las
partes.
o protocol: indica el tipo de contenido que hay en la parte del
mensajeque contiene la firma.
o micalg: indica el algoritmo o algoritmos de hash, tambin llamado
o MIC, con los que est calculada la firma (para facilitar el
procesado delmensaje en un solo paso).
El cuerpo del mensaje consta de dos partes MIME.
La primera parte es el mensaje sobre el cual se calcula la firma.
Tiene la estructura de una parte MIME, con cabeceras y cuerpo.
Como caso particular, puede tratarse de un mensaje MIME
multiparte si, por ejemplo, se quiere firmar un mensaje con
imgenes o documentos anexos.
La segunda parte contiene la firma, calculada a partir de la forma
cannica de la parte anterior. Esta segunda parte tambin debe
tener la estructura de una parte MIME, y el valor de su cabecera
Content-Type debe ser igual al del parmetro protocol de la
cabecera Content-Type del mensaje principal.
Cuando se aplica esta tcnica MIME de firmas en claro a S/MIME,
lascaractersticas de los mensajes son las siguientes:
El parmetro protocol y, por lo tanto la cabecera Content-Type de la

segunda parte del mensaje, debe tener el valor application/pkcs7signature.
Si se especifica un nmero de fichero asociado a la firma, es decir, a la

segunda parte, su extensin es .p7s (por ejemplo, smime.p7s).
En el cuerpo de la segunda parte del mensaje hay una estructura PKCS
#7 con tipo de contenido SignedData, pero sin el campo content en el
campo contentInfo.
A la hora de enviar un mensaje S/MIME con firma en claro, en la

estructuraSignedData de la segunda parte no se incluyen los datos
firmadosporque ya estn en la primera parte del mensaje. En el momento de
verificarla firma, el receptor debe actuar igual que si en la estructura SignedDatade
la segunda parte hubieran los datos de la primera parte.
En este caso, se dice que la estructura PKCS #7 tiene datos firmados no incluidos
(detached), a diferencia del otro formato de mensajes firmados, enel cual la
estructura PKCS #7 tiene los datos firmados incluidos (attached).
ste es un ejemplo de mensaje S/MIME firmado en claro:
85

Date: Mon, 18 Jun 2013 14:20:08 -0500

Subject: Muestra de correo 3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="20040301104740";
protocol=application/pkcs7-signature"; micalg=md5
--20040301104740
Content-Type: text/plain
Ejemplo de mensaje firmado.
--20040301104740
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIAw
ggFIMIIBBaADAgECAgEGMA0GCSqGSIb3DQEBBAUAMCoxCzAJBgNVBAYTAkVTMQwwCgYDVQQK
EwNVT0MxDTALBgNVBAMTBENBLTEwHhcNMDAwOTAxMDAwMDAwWhcNMTAwOTAxMDAwMDAwWjBV
MQswCQYDVQQGEwJFUzEMMAoGA1UEChMDVU9DMSUwIwYJKoZIhvcNAQkBFhZ1c3VhcmktMUBj
YW1wdXMudW9jLmVzMREwDwYDVQQDEwh1c3VhcmktMTBJMA0GCSqGSIb3DQEBAQUAAzgAMDUC
Lgw1Es5ojfSWtFCPLLOdONBOz+8u96IVp1GIYqVU2ewWQbH8TAd0UPLvPgKlu2cCAwEAATAN
BgkqhkiG9w0BAQQFAAMuAAJFmsOwv8wm/1Vl1vE0yluMpzDAU89Ub0tOo5nyxN0AXT1ScWxK
PmMTQAEA8QAAMYAwgYECAQEwLzAqMQswCQYDVQQGEwJFUzEMMAoGA1UEChMDVU9DMQ0wCwYD
VQQDEwRDQS0xAgEGMAwGCCqGSIb3DQIFBQAwDQYJKoZIhvcNAQEBBQAELgMzAj7h+9GoE+EW
P/AHuAj46vudJh+So/V/FuN1OrC70HmOyfEMiz49RixuhAgAAAAAAAAAAA==
--20040301104740--
Distribucin de claves con S/MIME

Como hemos visto hasta este punto, el mtodo que se utiliza en PKCS #7 ypor lo
tanto, en S/MIME, para identificar los usuarios y sus claves pblicas espor medio
de sus certificados X.509.
Esto quiere decir que un usuario no necesita verificar las identidades de losdems
porque de esto ya se encargan las autoridades de certificacin. Lonico que debe
hacer el usuario es comprobar si el certificado (o cadena decertificados) de su
corresponsal est firmado por una CA reconocida y es uncertificado vlido, es
decir, no est caducado ni revocado.
Idealmente, la distribucin de los certificados de los usuarios se debera
poderrealizar mediante el servicio de directorio X.500, pero si este servicio no
estdisponible se pueden utilizar otros mtodos alternativos.
S/MIME define un tipo especial de mensaje que sirve para transportar
certificadoso listas de revocacin. Se trata de un mensaje S/MIME con las
siguientescaractersticas:

contenido SignedData, pero sin datos firmados (campo content del
elemento contentInfo) ni firmas (campo signerInfos con 0 elementos).
Por lo tanto, los campos con informacin til son certificates y crls.
El valor del parmetro smime-type es certs-only.
Si se especifica un nombre de fichero asociado, su extensin es .p7c
(por ejemplo, smime.p7c).
86

ste es un ejemplo de mensaje S/MIME con slo certificados:

Date: Mon, 25 Jul 2013 24:25:17 -0500
Subject: Certificados del alumno y de la CA
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=certs-only;
name="smime.p7c"
Content-Disposition: attachment; filename="smime.p7c"
MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCAUgwggEFoAMCAQICAQYw
DQYJKoZIhvcNAQEEBQAwKjELMAkGA1UEBhMCRVMxDDAKBgNVBAoTA1VPQzENMAsGA1UEAxME
Q0EtMTAeFw0wMDA5MDEwMDAwMDBaFw0xMDA5MDEwMDAwMDBaMFUxCzAJBgNVBAYTAkVTMQww
CgYDVQQKEwNVT0MxJTAjBgkqhkiG9w0BCQEWFnVzdWFyaS0xQGNhbXB1cy51b2MuZXMxETAP
BgNVBAMTCHVzdWFyaS0xMEkwDQYJKoZIhvcNAQEBBQADOAAwNQIuDDUSzmiN9Ja0UI8ss504
0E7P7y73ohWnUYhipVTZ7BZBsfxMB3RQ8u8+AqW7ZwIDAQABMA0GCSqGSIb3DQEBBAUAAy4A
AkWaw7C/zCb/VWXW8TTKW4ynMMBTz1RvS06jmfLE3QBdPVJxbEo+YxNAAQDxMIIBGzCB2aAD
AgECAgEBMA0GCSqGSIb3DQEBBAUAMCoxCzAJBgNVBAYTAkVTMQwwCgYDVQQKEwNVT0MxDTAL
BgNVBAMTBENBLTEwHhcNMDAwOTAxMDAwMDAwWhcNMTAwOTAxMDAwMDAwWjAqMQswCQYDVQQG
EwJFUzEMMAoGA1UEChMDVU9DMQ0wCwYDVQQDEwRDQS0xMEgwDQYJKoZIhvcNAQEBBQADNwAw
NAItDgNwpzTW3wWW7che7zeVoV4DbqznSQfm5hnUe3kkZOelPU4o8DJqMav2JyxjAgMBAAEw
DQYJKoZIhvcNAQEEBQADLgACXnrqZYIk3CY+641wJs99q7mIC4bPK3O75IskUrvGxs1PvZRt
yoj8zZDJtcAAADGAAAAAAAAAAAA=
Finalmente, existe otro tipo de mensaje S/MIME para enviar peticiones

decertificacin a una CA. Una peticin de certificacin es un mensaje que
contienelos datos necesarios para que la CA genere un certificado, bsicamenteel
nombre del titular y su clave pblica.
A veces se utiliza como peticin de certificacin un certificado X.500
autofirmadopor el interesado. Otras veces se utiliza una estructura de datos
definidaexpresamente a tal efecto, especificada en la norma PKCS #10.
El tipo de mensaje S/MIME utilizado para enviar peticiones de certificacintiene las
siguientes caractersticas:
En el cuerpo del mensaje hay una estructura PKCS #10.
El valor de la cabecera Content-Type es application/pkcs10.
Si se especifica un nombre de fichero asociado, su extensin es .p10

(por ejemplo, smime.p10).
87

Figura 11: Escenario tpico S/MIME. - Fuente http://windowsitpro.com
88


aprendizaje ptimo.
Criptografa e Infraestructura de clave pblica en Internet Klaus
SchmehLink:http://books.google.es/books?id=9NqidkUqHdgC&pg=PA366&
dq=S/MIME&hl=es-419&sa=X&ei=KvIIUrX0J46WyAGtIGIAg&ved=0CFIQ6AEwBA#v=onepage&q=S%2FMIME&f=false
Gestin de la seguridad actual y Cuestiones ticas de Tecnologa de la

Informacin - Rasool Azari
Link:http://books.google.es/books?id=uU5JrygkdukC&pg=PA22&dq=S/MIM
E&hl=es-419&sa=X&ei=KvIIUrX0J46WyAGtIGIAg&ved=0CFoQ6AEwBQ#v=onepage&q=S%2FMIME&f=false
89

Leccin 25: PGP y OpenPGP

PGP (Pretty Good Privacy) es un software que proporciona funciones
criptogrficasy de gestin de claves, desarrollado inicialmente por Philip
Zimmermannen 1990. Se puede utilizar para proteger cualquier tipo de datos,pero
su uso ms habitual consiste en enviar mensajes de correo electrnicocifrado y/o
firmado.
Una de las caractersticas distintivas de PGP es el mtodo que utiliza para
certificarla autenticidad de las claves pblicas. En lugar de recorrer a
autoridadesde certificacin, como hace S/MIME, cada usuario puede certificar
directamentelas claves que est convencido que son autnticas. Y tambin
puedetomar decisiones respecto a una clave desconocida en funcin de quienes
seanlos usuarios que hayan certificado esta clave.
Otra caracterstica propia de PGP es la eficiencia en el intercambio de
losmensajes ya que, siempre que sea posible, los datos se comprimen antes
decifrarlos y/o despus de firmarlos.
Con el paso del tiempo han ido apareciendo distintas versiones de PGP,
algunasde las cuales con distintas variantes como, por ejemplo,
versionesinternacionalespara cumplir las restricciones de exportacin de
software criptogrficofuera de los Estados Unidos, o versiones que para poder ser
distribuidasde forma gratuita no incluyen algoritmos sujetos a patentes en ciertos
pases.
Las versiones de PGP hasta la 2.3 se consideran obsoletas: el formato delas
firmas es incompatible con el de las versiones posteriores.
Despus de la versin 2.5 se introdujo otro cambio de formato, a causa delas
condiciones de uso de algoritmos patentados en los Estados Unidos
(enconcreto,el algoritmo RSA).
Las versiones 2.6.x y sus variantes han sido durante mucho tiempo las ms
difundidas. El formato de los mensajes, llamado indistintamente versin 2 o
versin 3 (V3), est documentado en la especificacin RFC 1991.
En las versiones 4.x se introdujeron, entre otras novedades, las claves de una
sola funcin: claves slo para cifrar o slo para firmar.
Lo que se empez a disear con el nombre de PGP 3.0 finalmente dio lugar a
las versiones 5.x, que utilizan un nuevo formato para los mensajes, conocido
como versin 4 (V4) o OpenPGP y documentado en la es pecificacin RFC
2440.
Las nuevas versiones (PGP 6 y posteriores) aaden mejoras a la
funcionalidad,pero manteniendo la compatibilidad con las anteriores.
90

Tambin se est desarrollando en paralelo, como parte del proyecto GNU, el

software GnuPG (GNU Privacy Guard), basado en OpenPGP y de distribucin
totalmente libre (no utiliza algoritmos patentados como RSA o IDEA).
Formato de los mensajes PGP

Los datos que procesa PGP se codifican con unas estructuras de datos
llamadaspaquetes PGP. Un mensaje PGP est formado, pues, por uno o ms
paquetesPGP.
Un paquete PGP es una secuencia de bytes, con una cabecera que indicade qu
tipo de paquete se trata y su longitud y a continuacin, unoscampos de datos que
depenen del tipo de paquete.
El formato V3 define diez tipos de paquetes, mientras que el formato V4
definecatorce. A continuacin veremos los principales tipos de paquetes PGP.
1) Paquete de datos literales
Sirve para representar datos en claro, sin cifrar (sera el anlogo del contenido
Data en PKCS #7).
En un paquete de este tipo existe un campo que da el valor de los datos y otro
que indica si este valor se debe procesar como texto o como datosbinarios. En
el primer caso, las secuencias <CR><LF> que haya en el textocorresponden a
finales de lnea y se pueden convertir a la representacinlocal cuando se
tengan que visualizar o guardar en fichero, mientras que enel segundo caso no
se tienen que modificar.
2) Paquete de datos comprimidos
En este tipo de paquete hay un campo que indica el algoritmo de compresin, y
otro que contiene una secuencia de bytes comprimida. Cuando
sedescomprimen estos bytes, el resultado debe ser uno o ms paquetes PGP.
Normalmente lo que se comprime es un paquete de datos literales,
opcionalmenteprecedido por un paquete de firma (que veremos a continuacin).
3) Paquete de datos cifrados con clave simtrica
El contenido de este paquete es directamente una secuencia de bytes cifra dos
con un algoritmo simtrico. El resultado de descifrarlos tiene que serun o ms
paquetes PGP.
Tpicamente lo que se cifra simtricamente son paquetes de datos en claroo
paquetes de datos comprimidos.
Los paquetes de este tipo se usan para enviar un mensaje de correo cifradocon
sobre digital, o bien cuando el usuario quiere simplemente cifrar un archivo. En
91

el primer caso, es preciso adjuntar al mensaje la clave simtricacifrada de tal

forma que slo la pueda descifrar el destinatario o destinatarios.
Esto se realiza con paquetes cifrados con clave pblica (el tipo depaquete PGP
que veremos a continuacin). En el segundo caso, la clave nose guarda en
ningn sitio sino que el usuario la tiene que recordar cuandoquiera descifrar el
fichero. En realidad, el usuario no da directamente laclave de cifrado si no una
passphrase, a partir de la cual se obtiene la clavesimtrica aplicndole una
funcin de hash.
4) Paquete de datos cifrados con clave pblica
En este tipo de paquete hay un campo que sirve para identificar la clavepblica
utilizada, otro que indica el algoritmo de cifrado, y otro con losdatos cifrados.
Habitualmente este paquete se utilizaba para cifrar una clave de sesin,con la
cual se habr generado un paquete de datos cifrados simtricamente,para
enviar un mensaje con sobre digital. La clave pblica utilizada en estecaso es la
de cada uno de los destinatarios del mensaje.
5) Paquete de firma
Un paquete de este tipo contiene campos con la siguiente informacin:
Clase de firma, que puede ser:
Firma de datos binarios.
Firma de texto cannico.
Certificado, es decir, asociacin de clave pblica con nombre de usuario.
Revocacin de clave pblica.
Revocacin de certificado.
Fechado (timestamp).
Fecha y hora en que se cre la firma.
Identificador de la clave con la que se ha creado.
Algoritmos utilizados para el hash y el cifrado asimtrico.
La firma, que se obtiene aplicando los algoritmos especificados en losdatos
que hay que firmar, concatenados con los campos autenticados.
En el formato V3 estos campos autenticados son la clase de firma yla fecha de
creacin. En el formato V4 se puede especificar que otroscampos se
autentican.
Otros campos aadidos en el formato V4, entre los cuales hay:
Fecha de caducidad de la firma y de la clave.
92

Comentarios del autor de la firma.

Motivo de revocacin (en el caso de las firmas de revocacin).
El modo de saber a qu datos corresponde una firma depende del contexto.
Si es la firma de un mensaje de correo, en el mismo mensaje tiene quehaber el
paquete con los datos (normalmente datos literales) despues del defirma. Si es
un certificado o una revocacin, la firma tiene que ir despusde los paquetes de
clave pblica y de nombre de usuario correspondientes(a continuacin veremos
estos dos tipos de paquetes PGP).
Tambin es posible firmar el contenido de un fichero y dejar el paquete defirma
en un fichero separado. Esto se suele hacer cuando se distribuyenprogramas
(como, por ejemplo, el propio PGP) para garantizar que unaversin es autntica
y no constituye un caballo de Troya. En este casola asociacin entre datos y
firma se puede establecer mediante los nombresde los ficheros: por ejemplo, el
fichero con la firma se puede llamar comoel original, pero con la extensin .sig.
6) Paquete de clave pblica
Este tipo de paquete contiene la siguiente informacin relativa a una
clavepblica:
o La fecha de creacin de la clave.
o El algoritmo al que corresponde la clave.
o Los valores de los componentes de la clave. Si el algoritmo es RSA, estos
valores son el mdulo n y el exponente pblico e.
La clave pblica de un usuario se utiliza para enviarle datos cifrados opara
verificar las firmas que genere. Pero los paquetes correspondientes(datos
cifrados con clave pblica o firma, respectivamente) no contienenel valor de la
clave pblica utilizada, sino solamente su identificador declave.
El identificador de una clave pblica es un nmero de ocho bytes que sepuede
utilizar para buscar el valor de la clave en una base de datos.
Identificadores de claves PGP repetidos
Las implementaciones no tienen que suponer que los identificadores
declave seannicos: podra haber dos claves PGP distintas con el mismo
identificador. Sinembargo, la probabilidad de que pase esto es muy baja (a
no ser que se haga deliberadamente),porque puede haber 264 (> 1019)
identificadores distintos.
Si, por ejemplo, una firma est generada con una clave que tiene un
determi nado identificador, y resulta que hay dos claves con este
identificador, es precisoverificarla con cada una de las claves para
comprobar si es vlida.
93

7) Paquete de nombre de usuario

El contenido de un paquete de este tipo es simplemente una cadena
decaracteres, que se utiliza para identificar el propietario de una clave pblica.
Por tanto, tiene la misma funcin que el DN del sujeto en los certificadosX.509,
pero sin ninguna estructura predefinida.
8) Paquete de clave privada
Este tipo de paquete sirve para guardar los componentes de la clave privadade
un usuario. Nunca existe ningn motivo para enviarlo a otro usuario y por lo
tanto, el formato exacto del paquete puede depender de la implementacin.
Para asegurar la confidencialidad, en el fichero donde se guarde este
paquetelos componentes secretos de la clave deberan estar cifrados,
normalmentecon una clave simtrica derivada de una passphrase. De este
modo,cada vez que el usuario quiera descifrar o firmar un mensaje con su
claveprivada, deber indicar esta passphrase para poder obtener los valores
necesarios.
Un usuario puede tener varias claves, asociadas al mismo o a distintos
nombres.
En el fichero en el que haya los paquetes de clave privada, a continuacinde
cada uno habr el paquete o paquetes de nombre de usuariocorrespondientes.
9) Paquete de nivel de confianza en una clave
Este tipo de paquete tampoco se enva nunca sino que solamente se guardaen
el almacn de claves propio de cada usuario, ya que nicamente
tienesignificado para quien lo ha generado. Sirve para indicar el grado de
fiabilidadde una clave certificadora, es decir, se utiliza para asociar otras
clavescon nombres de usuarios.
En el formato V3 hay otro tipo de paquete que sirve para incluir
comentarios,pero se ha suprimido en el formato V4 porque no lo utilizaba
ningunaimplementacin.
El formato V4 tambin utiliza otros cinco tipos de paquetes, entre ellos
losrelacionados con las llamadas subclaves. Una clave puede tener
asociadasuna o ms subclaves: normalmente, la clave principal se utiliza para
firmar ylas subclaves, para cifrar.
Distribucin de claves PGP
94

Como hemos comentado al inicio de este apartado, la certificacin de claves

enPGP no sigue un modelo jerrquico, como el de las autoridades de
certificacinX.509, sino un modelo descentralizado de confianza mutua, a veces
llamadomalla de confianza (web of trust).
Figura 12: Modelo de confianza PGP. - Fuente http://pki.mikedaigle.ca/

Cuando un usuario genera su par de claves PGP (pblica y privada), a la
clavepblica le tiene que asociar un nombre de usuario y, a continuacin, tiene
queautocertificar esta asociacin, es decir, firmar con su clave privada
laconcatenacinde la clave pblica y el nombre. El paquete de la clave pblica, el
delnombre de usuario y el de la firma forman un bloque de clave.
Opcionalmente, el usuario puede asociar ms de un nombre a la clave
(porejemplo, si tiene diversas direcciones de correo electrnico) y entonces,
elbloque estar formado por la clave pblica y tantos pares nombrefirma
comosea preciso.
En este caso el usuario puede enviar este bloque a otros con los que tenga
quemantener correspondencia. Cada receptor, si est convencido de que la
claveefectivamente corresponde al usuario originador, la certificar aadiendo
otropaquete de firma al bloque (o uno para cada nombre, si hay ms de uno
ytambin los considera autnticos). De este modo, cada usuario dispondr deun
almacn de claves pblicas certificadas (keyring) que podr utilizar paracifrar
mensajes y verificar firmas de sus corresponsales.
Adems de paquetes de claves pblicas, nombres de usuario y firmas de
certificacin,en un keyring tambin puede haber firmas de revocacin para
invalidaruna clave o para anular un certificado. La revocacin debe estar
95

firmadapor la propia clave (la que se quiere invalidar o la que gener el certificado
quese quiere anular) y, una vez emitida, es irrevocable.
Otra posibilidad para realizar la distribucin es a travs de un servidor declaves
PGP, que gestiona un almacn global de claves pblicas con sus certificados(y
revocaciones, si es el caso). Varios de estos servidores estnsincronizados entre
si, de modo que las actualizaciones del almacn que serealicen en uno de ellos se
propagan automticamente a todos los dems.
Cualquier usuario puede enviar a un servidor PGP los certificados de su clave,ode
las claves de otros usuarios, para que los aada al Keyring global. En estecaso se
pueden realizar consultas a los servidores para obtener la clave y loscertificados
asociados a un determinado nombre de usuario (o a los nombresque contengan
una determinada subcadena, si no se conoce su valor exacto).
Es importante sealar que los servidores PGP no son autoridades decertificacin:
cualquier clave pblica que se les enve ser aadida alalmacn sin realizar
ninguna verificacin respecto a la identidad delpropietario.
Es responsabilidad de cada usuario que quiera utilizar una clave de un
servidorPGP asegurarse de la autenticidad de dicha clave. Para ello, se puede
tener encuenta que otros usuarios han certificado esta clave.
El proceso de certificacin PGP
Para facilitar el intercambio y la certificacin de claves, PGP asigna acada clave
pblica una huella (fingerprint), que es simplemente un hashdel valor de la clave.
Esta huella se utiliza para que un usuario pueda comprobar que la clave queha
recibido de otro, o de un servidor de claves, sea efectivamente la que querarecibir
y no una falsificacin. El identificador de clave no es suficiente paraeste fin, ya que
es posible para un impostor construir una clave pblica dela cual conozca la clave
privada y que tenga el mismo identificador que otraclave pblica. En cambio,
construir una clave con la misma huella que otra esprcticamente imposible.
El uso de la huella facilita la comprobacin de la autenticidad de la clave.
La alternativa sera comprobar todos los bytes uno por uno, lo cual puedeser
incmodo y pesado teniendo en cuenta que actualmente se suelen utilizarclaves
de 1.024 bits (256 dgitos hexadecimales) o incluso de 2.048 bits.
Supongamos, por ejemplo, que un usuario A necesita certificar la clave deotro
usuario B porque tiene que intercambiar con l mensajes seguros. Elusuario A
puede pedir a B que le mande su clave pblica por correo electrnicotradicional, o
bien obtenerla de un servidor de claves. Entonces A tiene quecomprobar que
96

nadie ha manipulado el mensaje de respuesta, obteniendo de Bla siguiente

informacin por un canal aparte (no por correo electrnico):
El identificador de la clave pblica de B.
La huella de esta clave.
El algoritmo y el nmero de bits de la clave (el nmero de bits puede
sernecesario para evitar colisiones en la huella).
Mtodos para comunicar la informacin sobre una clave pblica
Un canal seguro para enviar la informacin anterior puede consistir, por ejemplo,
enla comunicacin directa cara a cara en una conversacin telefnica. Tambin
hayquien se imprime el valor de la huella PGP en su tarjeta, o quien lo hace
accesible vafinger o HTTP (pero este mtodo no es tan seguro).
Otra posibilidad es organizar una key-signing party o reunin de firma de claves.
Aunque PGP trabaja internamente con identificadores de clave de 8 bytes,cuando
tiene que mostrar sus valores al usuario solamente muestra los 4 bytesde menos
peso. Por ejemplo, si una clave tiene por identificador el valor
hexadecimal657984B8C7A966DD, el usuario solamente ve el valor C7A966DD.
Esto da ms comodidad sin aumentar significativamente, en la prctica,
lasposibilidades de repeticin.
ste sera, pues, un ejemplo de toda la informacin necesaria para certificaruna
clave:
bits /keyID User ID
1024R/C7A966DD Philip R. Zimmermann <prz@acm.org>
Key fingerprint = 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6
Cuando el usuario A ha comprobado que los valores que le ha comunicado

Bcoinciden con los calculados a partir de la clave pblica recibida
electrnicamente,ya puede certificar que esta clave corresponde al nombre o
nombres deusuario que identifican al usuario B.
Integracin de PGP con el correo electrnico
Como hemos visto anteriormente, un mensaje PGP consta de una secuenciade
paquetes PGP. Pueden existir distintas combinaciones:
Si es un mensaje cifrado con sobre digital, primero hay tantos paquetes como
destinatarios, cada uno con la clave de sesin cifrada con la clave pblica del
destinatario correspondiente. A continuacin aparece el cuerpo del mensaje,
posiblemente comprimido, en un paquete cifrado simtricamente con la clave
de sesin.
97

Si es un mensaje firmado, primero encontramos el paquete de firma, y despus

el cuerpo del mensaje en un paquete de datos literales. Opcionalmente, estos
dos paquetes se pueden incluir dentro de un paquete comprimido.
Si es un mensaje firmado y cifrado, la estructura es como la de los mensajes
cifrados, con la excepcin de que cuando se descifra el paquete de datos
cifrados el resultado es un mensaje firmado, es decir, un paquete de firma
seguido de un paquete de datos literales, o bien un paquete comprimido que
cuando se descomprime da los dos paquetes anteriores.
Los mensajes construidos de esta manera contendrn datos binarios arbitrarios.

Para enviarlos a travs de los sistemas de correo electrnico tradicionalesse
pueden utilizar dos tcnicas: encapsulacin RFC 934 y MIME (con el
mtodollamado PGP/MIME). Con la encapsulacin RFC 934 se pueden
representarmensajes cifrados y/o firmados, mensajes firmados en claro, o bloques
declaves pblicas.
La tcnica de encapsulacin RFC 934
La especificacin RFC 934 define una tcnica para combinar uno o ms mensajes
enun nico cuerpo. sta es la tcnica que utiliza MIME para juntar distintas partes
en unmensaje multiparte.
La encapsulacin RFC 934 consiste en concatenar los mensajes que hay que
combinar,ponindolos simplemente uno a continuacin de otro, y utilizando
delimitadores deencapsulacin para indicar dnde empieza cada uno y dnde
termina el ltimo.
El texto que haya antes del primer delimitador se considera como un prlogo y
elque hay despus del ltimo delimitador se considera como un eplogo, pero
ningunode los dos forma parte del mensaje encapsulado.
Como delimitadores de encapsulacin se utilizan lneas que empiezan con un
guinseguido de otro carcter que no sea espacio. Si dentro de los mensajes que
hay queencapsular hay alguna lnea que empiece por un guin, simplemente se le
antepone unguin y un espacio. En el momento de desencapsular, a las lneas
que empiecen porguin y espacio se les suprimen estos dos caracteres. Las que
empiecen por guin yotro carcter sern consideradas como delimitadores. Esto
permite la encapsulacinrecursiva de mensajes compuestos dentro de otro
mensaje compuesto.
1) Mensajes PGP cifrados y/o firmados
ste es un ejemplo de mensaje PGP, codificado con el mtodo de
encapsulacinRFC 934.
Date: Mon, 13 Jul 2013 12:53:22 -0500
98

Subject: Ejemplo de PGP
-----BEGIN PGP MESSAGE----Version: 2.6.3y
iQBDAwUBObNQzFDy7z4CpbtnAQF9aQFrBtyRK8bdaPFlht7KeFzO/N0lJTcnYhbS
TvlZsTwr6+iQJqHP5nKnYr0W/Q9mo60AI3QAAAAAAEV4ZW1wbGUgZGUgbWlzc2F0
Z2Ugc2lnbmF0Lg0K
=8gbQ
-----END PGP MESSAGE-----
Como podemos ver en el ejemplo, la estructura del mensaje es la siguiente:
Como delimitador inicial de encapsulacin se utiliza la cadena BEGIN

PGP MESSAGE entre dos secuencias de cinco guiones, y el
delimitador final es igual pero cambiando BEGIN por END.
Despus del delimitador inicial puede haber distintas cabeceras, con
campos como Version para indicar qu versin de PGP ha generado el
mensaje, Comment para introducir comentarios del usuario, o Charset,
para especificar el juego de caracteres utilizado en el texto del mensaje.
Despus de las cabeceras aparece una lnea en blanco, y el paquete o
paquetes PGP que forman el mensaje codificado en base 64.
Inmediatamente despus de los paquetes PGP y antes del delimitador
de final, aparece una lnea de cinco caracteres: el primero es el signo
= y los otros cuatro son la codificacin en base 64 de un CRC de 24
bits de todos los bytes de los paquetes. Este CRC sirve para comprobar
que no se hayan producido modificaciones en el mensaje que hayan
podido afectar a la descodificacin.
En la terminologa PGP, la secuencia de lneas desde el delimitador

deencapsulacin de inicio hasta el del final se llama armadura ASCII
delmensaje.
2) Mensajes PGP firmados en claro
Igual que S/MIME, PGP tambin define un formato para enviar mensajes
firmados en claro, que permite leer el contenido a los usuarios que no disponen
de PGP. ste es un ejemplo:
Date: Mon, 13 Jul 2013 12:53:22 -0500
Subject: Ejemplo de mensaje firmado en claro
-----BEGIN PGP SIGNED MESSAGE----Hash: MD5
Ejemplo de mensaje firmado en claro.
-----BEGIN PGP SIGNATURE----Version: 2.6.3y
iQBDAwUBObNQzFDy7z4CpbtnAQF7aQFrBtyRK8bdaPFlht7KeFzO/N0lJTcnYhbS
TvlZsTwr6+iQJqHP5nKnYr0W/Q9mow==
=5TnX
-----END PGP SIGNATURE-----
En este caso aparecen dos submensajes encapsulados, con la siguiente

estructura:
99

El delimitador de inicio de la primera parte es la cadena BEGIN PGP

SIGNED MESSAGE, con una secuencia de cinco guiones delante y
detrs.
En el primer submensaje aparecen cero o ms cabeceras Hash, que
indican el algoritmo (o algoritmos) de hash utilizados para calcular la
firma (o firmas), seguidos de una lnea en blanco y del cuerpo del
mensaje.
La especificacin del algoritmo al inicio permite procesar el mensaje
enun solo paso. En ausencia de este campo, se entiende por defecto
que lafuncin de hash utilizada es MD5.
Despus del primer submensaje aparece la armadura ASCII de uno
oms paquetes de firma, con un delimitador de inicio formado por
lacadena BEGIN PGP SIGNATURE, tambin con cinco guiones
delantey detrs, y con un delimitador de final igual, aunque
cambiandoBEGIN por END.
Las firmas se calculan a partir del cuerpo del mensaje en forma
cannica,es decir, representando los finales de lnea con <CR><LF>.
Adems,PGP siempre elimina los espacios en blanco y los tabuladores
que hayaantes de un final de lnea en el momento de obtener las firmas
3) Mensajes de bloques de claves pblicas

Hay otro formato de armadura PGP que sirve para enviar bloques de
clavespblicas y certificados. El delimitador de inicio consta de la cadena
BEGINPGP PUBLIC KEY BLOCK rodeada de dos secuencias de cinco
guiones,y el de final es igual, aunque cambiando BEGIN por END. ste es
unejemplo:
Date: Mon, 13 Jul 2013 12:53:22 -0500
Subject: Mi clave PGP
-----BEGIN PGP PUBLIC KEY BLOCK----Version: 2.6.3y
mQA9AzmvN9AAAAEBbAw1Es5ojfSWtFCPLLOdONBOz+8u96IVp1GIYqVU2ewWQbH8
TAd0UPLvPgKlu2cAEQEAAbQhVXN1YXJpIDEgPHVzdWFyaS0xQGNhbXB1cy51b2Mu
ZXM+iQBCAwUQOa830FDy7z4CpbtnAQFdoQFox7LHdl8wdIA69f4REn14bVYxBaxw
4Y35PJwRWqI2c+8T75vqUdBhiydsZ2Fo
=Ninr
-----END PGP PUBLIC KEY BLOCK-----
Cualquiera de los tipos de armadura que hemos visto se puede utilizar

paraintercambiar informacin PGP con otros medios de transferencia ademsdel
correo electrnico: FTP, HTTP, etc.
4) PGP/MIME
Para incorporar PGP a MIME, inicialmente se defini el tipo de contenidoMIME
application/pgp. Ms tarde, sin embargo, este tipo de contenidose abandon en
favor del mtodo RFC 1847, que es el mismo queutiliza S/MIME para los
mensajes firmados en claro. Adems del tipo decontenido multipart/signed
100

correspondiente a los mensajes firmados,RFC 1847 tambin define el tipo

multipart/encrypted correspondientea los mensajes cifrados.
La tcnica para incluir mensajes PGP en mensajes MIME RFC 1847 sedenomina
PGP/MIME, y est especificada en el RFC 2015. PGP/MIMEdefine tres tipos de
contenido para las partes MIME que representen mensajesPGP: application/pgpencrypted, application/pgpsignaturey application/pgp-keys.
Sin embargo, actualmente es mucho ms habitual el uso de las armadurasASCII
para encapsular mensajes PGP que la tcnica PGP/MIME.

aprendizaje ptimo.
PGP 10.2.0 Cifrado Simtrico y Asimtrico - MrDragon hack
Link:https://www.youtube.com/watch?v=NXTX3oXv1rA
Cmo utilizar GPG Cifrado-ssyrianking44
Link:https://www.youtube.com/watch?v=m56dsDc2808
101

CAPITULO 6: PROTECCIN DEL NIVEL DE TRANSPORTE Y REDES

PRIVADAS VIRTUALES
Introduccin
Algunos algoritmos han perdido parte de su interscomo es el caso de DES,
quefue vencidoen 1998, nuevas tcnicas han surgido o se han popularizado
PGPes un claro ejemplo de que para el usuario de a pie se puede conseguir
autntica privacidad,temas que antes tenan un inters limitado se han convertido
en fundamentales, la rpidaexpansin de Internet obliga no slo al profesional,
sino al usuario medio, a tener ciertosconocimientos bsicos sobre seguridad, etc.
Como hemos definido ya, en los ltimos apartados de este material de estudio, la
criptografa es la herramientaque nos permite evitar que alguienmanipule o
falsifique los datostransmitidos.
Debemos evitar, de esta forma, que despus de tomar todas las medidas
necesariaspara que slo el destinatario final pueda leer la informacin, resulte
queeste destinatario sea un impostor que haya conseguido hacerse pasar por
elautntico destinatario. En la segunda parte del mdulo veremos algunos
sistemaspara garantizar la autenticidad en las comunicaciones, la mayora deellas
basadas en tcnicas criptogrficas.
En el resto de este mdulo didctico estudiaremos ejemplos de protocolos
decomunicacin que, aplicado los mecanismos anteriores, permiten proteger
lainformacin que se transmite entre ordenadores. Esta proteccin se
puedeobtener en distintos niveles de la arquitectura de comunicaciones. A
nivelred, el mecanismo principal en un entorno de interconexin basado en IP esel
conjunto de protocolos conocido como IPsec.
Alternativamente, se puede implementar la proteccin a nivel de
transporte,aprovechando as la infraestructura IP existente, principalmente los
encaminadoreso routers. Como ejemplo de proteccin a nivel de transporte
veremosla familia de protocolos SSL/TLS/WTLS.
102

Para finalizar el captulo, introduciremos la tecnologa de redes privadas virtualeso

VPN, que permite utilizar una red pblica ampliamente extendidacomo es Internet
para comunicaciones seguras, como si fuera una red privadadedicada.
Leccin 26: Caractersticas del protocolo SSL/TLS

El objetivo inicial del diseo del protocolo SSL fue proteger las conexionesentre
clientes y servidores web con el protocolo HTTP. Esta proteccin debapermitir al
cliente asegurarse que se haba conectado al servidor autntico,y enviarle datos
confidenciales, como por ejemplo un nmero de tarjeta decrdito, con la confianza
que nadie ms que el servidor sera capaz de verestos datos.
Las funciones de seguridad, pero, no se implementaron directamente en
elprotocolo de aplicacin HTTP, si no que se opt por introducirlas a nivel
detransporte. De este modo podra haber muchas ms aplicaciones que
hicieranuso de esta funcionalidad.
Con este fin se desarroll una interfaz de acceso a los servicios del nivel
detransporte basada en la interfaz estndar de los sockets. En esta nueva
interfaz,funciones como connect, accept, send o recv fueron sustituidaspor otras
equivalentes pero que utilizaban un protocolo de transporte seguro:
SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseo serealiz de tal
modo que cualquier aplicacin que utilizara TCP a travs de lasllamadas de los
sockets poda hacer uso del protocolo SSL solamente cambiandoestas llamadas.
De aqu proviene el nombre del protocolo.
103

Figura 13: Esquema de sesin

http://www.tuempresaenlared.ne
con
certificados
SSL.
Fuente
Los servicios de seguridad que proporcionan los protocolos SSL/TLS son:

Confidencialidad. El flujo normal de informacin en una conexin
SSL/TLSconsiste en intercambiar paquetes con datos cifrados mediante claves
simtricas(por motivos de eficiencia y rapidez). Al inicio de cada sesin, clientey
servidor se ponen de acuerdo en que claves utilizarn para cifrar los datos.
Siempre se utilizan dos claves distintas: una para los paquetes enviados delcliente
al servidor, y la otra para los paquetes enviados en sentido contrario.
Para evitar que un intruso que est escuchando el dilogo inicial pueda
sabercuales son las claves acordadas, se sigue un mecanismo seguro de
intercambiode claves, basado en criptografa de clave pblica. El algoritmo
concreto paraeste intercambio tambin se negocia durante el establecimiento de la
conexin.
Autenticacin de entidad. Con un protocolo de reto-respuesta basado en
firmasdigitales el cliente pude confirmar la identidad del servidor al cual se
haconectado.
Para validar las firmas el cliente necesita conocer la clave pblicadel servidor, y
esto normalmente se realiza a travs de certificados digitales.
SSL/TLS tambin prev la autenticacin del cliente frente al servidor.
Estaposibilidad, pero, no se usa tan a menudo porque muchas veces, en lugar
deautenticar automticamente el cliente a nivel de transporte, las mismas
aplicacionesutilizan su propio mtodo de autenticacin.
104

Autenticacin de mensaje. Cada paquete enviado en una conexin SSL/TLS,a

ms de ir cifrado, puede incorporar un cdigo MAC para que el
destinatariocompruebe que nadie ha modificado el paquete. Las claves secretas
par elclculo de los cdigos MAC (una para cada sentido) tambin se acuerdan
deforma segura en el dilogo inicial.
A ms, los protocolos SSL/TLS estn diseados con estos criterios adicionales:
Eficiencia. Dos de las caractersticas de SSL/TLS, la definicin de sesiones yla
compresin de los datos, permiten mejorar la eficiencia de la comunicacin.
Si el cliente pide dos o ms conexiones simultneas o muy seguidas, en

lugar de repetir la autenticacin y el intercambio de claves (operaciones
computacionalmente costosas porque intervienen algoritmos de clave
pblica), hay la opcin de reutilizar los parmetros previamente acordados. Si
se hace uso de esta opcin, se considera que la nueva conexin pertenece a
la misma sesin que la anterior. En el establecimiento de cada conexin se
especifica un identificador de sesin, que permite saber si la conexin
empieza una sesin nueva o es continuacin de otra.
SSL/TLS prev la negociacin de algoritmos de compresin para los datos
intercambiados, para compensar el trfico adicional que introduce la
seguridad.
Pero ni SSL 3.0 ni TLS 1.0 especifican ningn algoritmo concretode compresin.
Extensibilidad. Al inicio de cada sesin, cliente y servidor negocian los
algoritmosque utilizarn para el intercambio de claves, la autenticacin y el
cifrado(a ms del algoritmo de compresin). Las especificaciones de los
protocolosincluyen
unas
combinaciones
predefinidas
de
algoritmos
criptogrficos,pero dejan abierta la posibilidad de aadir nuevos algoritmos si se
descubrenotros que sean ms eficientes o ms seguros.
105


aprendizaje ptimo.
Lesson 9: Introduction to the SSL protocol (Intypedia) - UPM
Link:https://www.youtube.com/watch?v=hCfRGhFBZd8
SSL / TLS - Como Funciona (parte 1 de 2) - Galeno Garbe

Link:https://www.youtube.com/watch?v=bGZ9HXxegno
Leccin 27: El transporte seguro SSL/TLS

La capa de transporte seguro
considerardividida en dos subcapas.
que
proporciona
SSL/TLS
se
puede
La subcapa superior se encarga bsicamente de negociar los parmetros de

seguridad y de transferir los datos de la aplicacin. Tanto los datos de
negociacin como los de aplicacin se intercambian en mensajes.
106

En la subcapa inferior, estos mensajes son estructurados en registros a los

cuales se les aplica, segn corresponda, la compresin, la autenticacin y el
cifrado.
Figura
14:
Modelo
http://www.vircom.com
TCP/IP
Protocolo
SSL/TLS.
Fuente
El protocolo de registros SSL/TLS es el que permite que los datos protegidossean

convenientemente codificados por el emisor y interpretados por elreceptor. Los
parmetros necesarios para la proteccin, como pueden ser losalgoritmos y las
claves, se establecen de forma segura al inicio de la conexinmediante el
protocolo de negociacin SSL/TLS. A continuacin veremos lascaractersticas de
cada uno de estos dos protocolos.
Leccin 28: Ataques contra el protocolo SSL/TLS

Los protocolos SSL/TLS estn diseados para resistir los siguientes ataques:
Lectura de los paquetes enviados por el cliente y servidor. Cuando los
datosse envan cifrados, un atacante que pueda leer los paquetes, por ejemplo
utilizandotcnicas de sniffing, se enfrenta al problema de romper el cifrado siquiere
interpretar su contenido. Las claves que se utilizan para el cifrado seintercambian
107

con mtodos de clave pblica, que el atacante tendra que rompersi quiere saber
cuales son los valores acordados.
Es preciso advertir, pero, que dependiendo de la aplicacin que lo utilice,
elprotocolo SSL/TLS puede ser objeto de ataques con texto en claro conocido.
Por ejemplo, cuando se utiliza conjuntamente con HTTP para acceder a
servidoresweb con contenidos conocidos.
Si la comunicacin es totalmente annima, es decir sin autenticacin de servidorni
cliente, s que existe la posibilidad de capturar las claves secretas conun ataque
conocido como hombre en el medio (en ingls, man-in-themiddleattack). En
este ataque el espa genera sus propias claves pblicas yprivadas, y cuando una
parte enva a la otra informacin sobre su clave pblica,tanto en un sentido como
en el otro, el atacante la intercepta y la sustituyepor la equivalente con la clave
pblica fraudulenta. Dado que el intercambioes annimo, el receptor no tiene
manera de saber si la clave pblica que recibees la del emisor autntico o no.
En cambio, si se realiza la autenticacin de servidor y/o cliente, es necesarioenviar
un certificado donde tiene que haber la clave pblica del emisor firmadapor una
autoridad de certificacin que el receptor reconozca, y por tanto nopuede ser
sustituida por otra.
Suplantacin de servidor o cliente. Cuando se realiza la autenticacin de
servidoro cliente, el certificado digital debidamente firmado por la CA sirve
paraverificar la identidad de su propietario. Un atacante que quiera hacerse
pasarpor el servidor (o cliente) autntico debera obtener su clave privada, o bienla
de la autoridad de certificacin que ha emitido el certificado para podergenerar
otro con una clave pblica diferente y que parezca autntico.
Alteracin de los paquetes. Un atacante puede modificar los paquetes paraque
lleguen al destinatario con un contenido distinto del original (si estn cifradosno
podr controlar cual ser el contenido final descifrado, solamente sabrque ser
distinto al original). Si pasa esto, el receptor detectar que el paqueteha sido
alterado porque el cdigo de autenticacin (MAC) casi con totalseguridad ser
incorrecto.
Si la alteracin se realiza en los mensajes de negociacin cuando aun no seaplica
ningn cdigo MAC, con la finalidad por ejemplo de forzar la adopcinde
algoritmos criptogrficos ms dbiles y vulnerables, esta manipulacin
serdetectada en la verificacin de los mensajes Finished.
Repeticin, eliminacin o reordenacin de paquetes. Si el atacante vuelvea
enviar un paquete correcto que ya haba sido enviado antes, o suprime
algnpaquete haciendo que no llegue a su destino, o los cambia de orden, el
receptorlo detectar porque los cdigos MAC no coincidirn con el valor esperado.
108

Esto es as porque en el clculo del MAC se utiliza un nmero de secuenciaque se

va incrementando en cada paquete.
Tampoco se pueden copiar los mensajes enviados en un sentido (de cliente
aservidor o de servidor a cliente) al sentido contrario, porque en los dos flujosde la
comunicacin se utilizan claves de cifrado y de MAC diferentes.
Como consideracin final, cabe destacar que la fortaleza de los protocolos
segurosrecae no solamente en su diseo si no en el de las implementaciones.
Si una implementacin solamente soporta algoritmos criptogrficos dbiles(con
pocos bits de clave) o genera nmeros pseudoaleatrios fcilmente predecibles o
guarda los valores secretos en almacenamiento (memoria o disco)accesible por
atacantes, etc., no estar garantizando la seguridad del protocolo.
aprendizaje ptimo.
Leccin 10. Ataques al protocolo SSL (intypedia) - UPM
Link:https://www.youtube.com/watch?v=pSVNnShpCOM
Leccin 29: Aplicaciones que utilizan SSL/TLS

Como hemos visto al inicio de este apartado, los protocolos SSL/TLS
fuerondiseados para permitir la proteccin de cualquier aplicacin basada en
unprotocolo de transporte como TCP. Algunas aplicaciones que utilizan
estacaracterstica son:
HTTPS (HTTP sobre SSL/TLS): el protocolo ms utilizado actualmente para la

navegacin web segura.
109

NNTPS (NNTP sobre SSL): para el acceso seguro al servicio de News.
Estas aplicaciones con SSL/TLS funcionan exactamente igual que las originales.
Las nicas diferencias son el uso de la capa de transporte seguro queproporciona
SSL/TLS y la asignacin de nmeros de puerto TCP propios: 443para HTTPS y
563 para NNTPS.
En muchos otros casos, pero, es preferible aprovechar los mecanismos de
extensinprevistos en el propio protocolo de aplicacin, si hay, para negociar eluso
de SSL/TLS, a fin de evitar la utilizacin innecesaria de nuevos puertosTCP.
As lo hacen aplicaciones como:
TELNET, usando la opcin de autenticacin (RFC 1416).

FTP, usando las extensiones de seguridad (RFC 2228).
SMTP, usando sus extensiones para SSL/TLS (RFC 2487).
POP3 y IMAP, tambin usando comandos especficos para SSL/TLS (RFC
2595).
Tambin hay definido un mecanismo para negociar el uso de SSL/TLS en

HTTP (RFC 2817), como alternativa a HTTPS.
aprendizaje ptimo.
SSL TLS HTTPS y HSTS Nadeem Mujahid

Link:https://www.youtube.com/playlist?list=PLmklf43ZLHbDrZLuu1ZsQ6Gyj
tuC-lcRX
Leccin 30: Definicin, tipos y configuraciones de VPN

TLS (Transport Layer Security)
El desarrollo de TLS se basa en el protocolo SSLv3, al ser una versin avanzada
proporciona mejores caractersticas de seguridad. La arquitectura de los dos
protocolos es bastante similar, sin embargo no se asegura la compatibilidad entre
estos.
110

Una red privada virtual (VPN) es una configuracin que combina eluso de dos
tipos de tecnologas:
Las tecnologas de seguridad que permiten la definicin de una red privada, es

decir, un medio de comunicacin confidencial que no puede ser interceptado
por usuarios ajenos a la red.
Las tecnologas de encapsulamiento de protocolos que permiten que, en lugar
de una conexin fsica dedicada para la red privada, se pueda utilizar una
infraestructura de red pblica, como Internet, para definir por encima de ella
una red virtual.
Por tanto, una VPN es una red lgica o virtual creada sobre una
infraestructuracompartida, pero que proporciona los servicios de proteccin
necesarios parauna comunicacin segura.
Dependiendo de la situacin de los nodos que utilizan esta red, podemos
considerartres tipos de VPN:
VPN entre redes locales o intranets. Este es el caso habitual en que una
empresadispone de redes locales en diferentes sedes, geogrficamente
separadas,en cada una de las cuales hay una red privada o intranet, de acceso
restringidoa sus empleados. Si interesa que desde una de sus sedes se pueda
acceder a lasintranets de otras sedes, se puede usar una VPN para interconectar
estas redesprivadas y formar una intranet nica.
VPN de acceso remoto. Cuando un empleado de la empresa quiere acceder ala
intranet des de un ordenador remoto, puede establecer una VPN de este tipoentre
este ordenador y la intranet de la empresa. El ordenador remoto puedeser, por
ejemplo, un PC que el empleado tiene en su casa, o un ordenadorporttil des del
cual se conecta a la red de la empresa cuando est de viaje.
VPN extranet. A veces, a una empresa le interesa compartir una parte de
losrecursos de su intranet con determinados usuarios externos, como por
ejemploproveedores o clientes de la empresa. La red que permite estos accesos
externosa una intranet se llama extranet, y su proteccin se consigue medianteuna
VPN extranet.
Configuraciones y protocolos utilizados en VPN
A cada uno de los tipos de VPN que acabamos de ver le suele corresponderuna
configuracin especfica.
En las VPN entre intranets, la situacin ms habitual es que en cada intranet hay
una pasarela VPN, que conecte la red local con Internet. Esta pasarela se
comunica con la de las otras intranets, aplicando el cifrado y las protecciones que
sean necesarias a las comunicaciones de pasarela a pasarela a travs de Internet.
111

Cuando los paquetes llegan a la intranet dedestino, la pasarela correspondiente

los descifra y los reenva por la redlocal hasta el ordenador que los tenga que
recibir.
De esta manera es utiliza la infraestructura pblica de Internet, en lugarde
establecer lneas privadas dedicadas, que supondran un coste ms elevado.
Tambin se aprovecha la fiabilidad y redundancia que proporcionaInternet, ya que
si una ruta no est disponible siempre se pueden encaminarlos paquetes por otro
camino, mientras que con una lnea dedicada laredundancia supondra un coste
an ms elevado.
En las VPN de acceso remoto, a veces llamadas VPDN, un usuario se
puedecomunicar con una intranet a travs de un proveedor de acceso a
Internet,utilizando tecnologa convencional como por ejemplo a travs de un
mdemADSL. El ordenador del usuario ha de disponer de software clienteVPN
para comunicarse con la pasarela VPN de la intranet y llevar a cabola
autenticacin necesaria, el cifrado, etc.
De este modo tambin se aprovecha la infraestructura de los proveedores
deInternet para el acceso a la intranet, sin necesidad de llamadas a un mdemde
la empresa, que pueden llegar a tener un coste considerable.
El caso de las VPN extranet puede ser como el de las VPN entre intranets,en que
la comunicacin segura se establece entre pasarelas VPN o biencomo el de las
VPN de acceso remoto, en que un cliente VPN se comunicacon la pasarela de la
intranet. La diferencia, pero, es que en este caso normalmenteel control de acceso
es ms restrictivo para permitir solamente elacceso a los recursos autorizados.
La definicin de una red virtual lleva a cabo mediante el establecimiento detneles,
que permiten encapsular paquetes de la red virtual, con sus protocolos,dentro de
paquetes de otra red, que normalmente es Internet, con suprotocolo, es decir IP.
Para la comunicacin entre las distintas intranets, o entre el ordenador que
accederemotamente y la intranet, se pueden utilizar los protocolos que sean
msconvenientes. Los paquetes de estos protocolos, para poderlos hacer llegar
asu destino a travs de Internet, se pueden encapsular en datagramas IP,
quedentro suyo contendrn los paquetes originales. Cuando lleguen a su
destino,se desencapsulan estos datagramas para recuperar los paquetes con el
formatonativo del protocolo correspondiente.
112

Figura 15: Esquema

http://virtual.uaeh.edu.mx
de
conectividad
con
VPN.
Fuente
REFERENCIAS
[1] http: //www.acis.org.co/archivosAcis/Inseguridad.doc, Jeimy Cano, 2004
113

[2] Moron Lerma, Esther. (2002). Internet y derecho penal: Hacking y otras
conductas ilcitas en la red. Editorial Aranzadi, S.A.
[3] Villaln Huerta, Antonio. (2002). Seguridad en UNIX y redes. Versin 2.1,
http://www.rediris.es/cert/doc/unixsec/
[4] Colobran Huguet, Miguel. (2002): Administracin de sistemas operativos en
Zarza. Barcelona: Universidad Oberta de Catalunia
[5] Schneier Bruce, Beyond Fear. Thinking Sensibly about security in an uncertain
world. Copernicus Books. 2003
[6] Stallings, W. (2003). Cryptography and Network Security, Principles
andPractice,3rd ed. Upper Saddle River: Prentice Hall.
[7] Menezes, A. J.; van Oorschot, P. C.; Vanstone, S. A. (1996). Handbook of
AppliedCryptography. Boca Raton: CRC Press.
[8] Yuan, R.; Strayer, W. T. (2001). Virtual Private Networks, Technologies and
Solutions.Boston: Addison-Wesley.
[9] RFC 2440: Open PGP Message Format.
http://www.ietf.org/rfc/rfc2440.txt
[10] RFC 1750: Randomness Recommendations for Security.
http://www.it.kth.se/docs/rfc/rfcs/rfc1750.txt
[11] Pgina Web de Kriptopolis.
http://www.kriptopolis.com
[12] Pgina Web de PGP International.
http://www.pgpi.org
[13] Pgina Web de Zedz Consultants (antes Replay).
http://www.zedz.net
114

Modulo de Criptografia PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo de Criptografia PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Escuela de Ciencias Bsicas, Tecnologa e ingeniera

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

PRIMERA UNIDAD: INTRODUCCIN A LA CRIPTOGRAFA1

Captulo 1: Conceptos bsicos de criptografa

Leccin 1: Criptografa de clave simtrica

Leccin 2: Criptografa de clave pblica

Leccin 3: Infraestructura de clave pblica (PKI)

Leccin 4: Sistemas de autenticacin

Leccin 5: Proteccin del nivel de red: IPsec

Captulo 2: Mtodos de Autenticacin

Leccin 6: Firmas Digitales. Funciones Resumen

Leccin 7: Autenticacin de Dispositivos

Leccin 8: Autenticacin de Usuario Mediante Contrasea

Leccin 9: Ataques Mediante Diccionario

Leccin 10: Estenografa

Captulo 3: Comunicacin segura

Leccin 11: Autenticidad

Leccin 12: Confidencialidad

Leccin 13: Integridad

Leccin 14: No repudio

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Leccin 15: Protocolos Seguros

SEGUNDA UNIDAD: APLICACIONES SEGURAS

Captulo 4: El protocolo SSH

Leccin 16: Caractersticas del protocolo SSH

Leccin 17:Tneles a nivel de transporte

Leccin 18:La capa de transporte SSH

Leccin 19:Ataques contra el protocolo SSH

Leccin 20: Aplicaciones que utilizan el protocolo SSH

Captulo 5: Correo electrnico seguro

Leccin 21: Seguridad en el correo electrnico

Leccin 22: Autenticacin de mensaje

Leccin 23: Compatibilidad con los sistemas de correo no seguro

Leccin 24: S/MIME

Leccin 25: PGP y OpenPGP

Captulo 6: Proteccin del nivel de transporte y Redes privadas virtuales

Leccin 26: Caractersticas del protocolo SSL/TLS

Leccin 27: El transporte seguro SSL/TLS

Leccin 28: Ataques contra el protocolo SSL/TLS

Leccin 29: Aplicaciones que utilizan SSL/TLS

Leccin 30: Definicin, tipos y configuraciones de VPN

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Tabla 1. Comparacin de mtodos biomtricos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

LISTADO DE GRFICOS Y FIGURAS

Figura 1: Proceso de cifrado y descifrado simtrico.

Figura 3: Infraestructura de clave pblica PKI.

Figura 4: Esquema muestra una implementacin tpica donde la autenticacin de los

Figura 6: Proceso de firma digital.

Figura 7: Ejemplo de proceso para garantizar la confidencialidad.

Figura 8: Esquema de firma de un mensaje o documento.

Figura 9: Modelo de comunicacin con tnles SSH.

Figura 10: Estructura de la capa de transporte SSH.

Figura 11: Escenario tpico S/MIME.

Figura 12: Modelo de confianza PGP.

Figura 13: Esquema de sesin con certificados SSL.

Figura 14: Modelo TCP/IP Protocolo SSL/TLS.

Figura 15: Esquema de conectividad con VPN.