Hoy en día ningún usuario
puede asegurar que sus transmisiones por la red no estén siendo
escuchadas, copiadas, intervenidas...... por terceras personas. Por ello
es necesario el uso de la criptografía en las transmisiones de red.
Hay dos técnicas de cifrado que
no son incompatibles entre sí. El cifrado de enlace y el cifrado
de extremo a extremo.
1. Cifrado de enlace --CENL--
El cifrado de enlace se realiza en el nivel
1. La tarea de cifrar la información que sale del ordenador o de
descifrar la que entra, en el cifrado de enlace se ubica en la capa física.
Cada bit que sale de la máquina sufre un proceso de cifrado y cada
bit que entra en la máquina sufre un proceso de descifrado. El encargado
de cifrar es el software de red, que es el que se comunica con las aplicaciones
y el sistema operativo.
La ventaja del cifrado de enlace es que
se cifra todo tanto los datos como las cabeceras añadidas por los
demás niveles y que todas las aplicaciones se benefician de él.
Es muy difícil extenderlo a una
red grande, pero va muy bien en redes inalámbricas, en las cuales
a los pc's se les colocan tarjetas que transmiten los datos cifrados. Esto
va muy bien porque interceptar datos en una red inalámbrica es muy
fácil, por lo tanto es mejor transmitir todo cifrado.
IPsec
Es un tipo de cifrado de enlace, provee
servicios similares a SSL pero a nivel de red, de un modo que es completamente
transparente a las aplicaciones y mucho más robusto.
Provee protección a los protocolos
clientes que residen sobre la capa IP.
2. Cifrado de extremo a extremo (TLS) --CEE--
El cifrado de extremo a extremo se realiza en el nivel 4, el nivel de Aplicación. La aplicación es la que cifra los datos antes de mandarlos al sistema operativo y este a la capa de red, y la que los descifra una vez recibidos.
SSL, SSL2, SSL3, TLS
Son protocolos de CEE para comunicaciones con sesión, se usan mayoritariamente para web. Sirven para poder comunicarse de manera confidencial utilizando el cifrado y para autentificación del servidor y opcionalmente del cliente.
Para establecer una conexión con
ssl es necesario tener un certificado x509. Protocolo:
-- El cliente se conecta.
-- Cliente y servidor tienen que ponerse
de acuerdo protocolo que usaran para conectarse. Que algoritmo de clave
privada usarán para comunicarse.
-- El servidor manda su certificado al
cliente. Este lo contrasta con las autoridades certificadoras de confianza
que tenga en el navegador.
-- Ahora el cliente tiene que verificar
que el certificado es del servidor. Para ello el cliente lanza un reto
al servidor, enviandole algo cifrado con la clave pública del servidor.
Si el servidor responde el reto es porque ha podido descifrarlo, por lo
tanto es quien dice ser. Normalmente lo que se manda en el reto es la clave
de sesión con la que se comunicarán en posteriores comunicaciones.
-- Ahora ambos pueden comenzar una comunicación
cifrada y totalmente confidencial con cualquier algoritmo de clave privada
y con la clave del reto.
-- Si el servidor quiere autentificar
al cliente puede hacerlo mediante el uso de una passwrd. Esto es
seguro ya que circulara cifrado. También es posible que el servidor
exija un certificado al cliente.
Hay 4 tipos de autentificación que
puede pedir el servidor al cliente:
1- no pedir, sin autentificación.
2- voluntario pero que el certificado
que aporte sea bueno, lo que el cliente quiera.
3- voluntario y aunque el certificado
no lo puedan verificar no importa.
4- Obligatorio presentar un certificado
y este ha de ser válido para el servidor, lo ha de poder verificar.
Cuando hacemos una conexión https estamos obligando a que se producía una conexión segura.
Es recomendable guardar nuestros certificados caducados por si alguna vez los necesitamos para leer algo que nos mandaron cuando era válido.
SMIME, PGP
Son protocolos de CEE para comunicaciones sin sesión, se usan para email. Diseñados para proteger la integridad y seguridad de datos entre dos aplicaciones que se comunican entre sí.
PGP suele ir integrado en los programas
de correo más usuales para facilitar el encriptado y firmado de
documentos sea más fácil. Cuando enviamos un mensaje encriptado
a otro usuario de PGP, el programa crea una clave de sesión, que
es independiente de nuestras claves privadas o públicas. Esta clave
de sesión es un número generado de forma aleatoria por el
programa. Esa clave de sesión se usa para encriptar el texto del
mensaje, con lo que ya no hay forma de “ver” el mensaje. Antes de enviarlo,
la clave de sesión se encripta utilizando la clave pública
del destinatario y ambos paquetes, texto encriptado y clave de sesión
encriptada se envían juntos.
Al recibir el mensaje, el destinatario
desencripta la clave de sesión usando la clave privada. Una vez
tiene la clave de sesión, se desencripta el texto del mensaje con
ella.
De este modo PGP garantiza que el mensaje
sólo será leído por quien debe leerlo y además
asegura la integridad del mismo, es decir asegurar que nadie ha modificado
su contenido.
3. Seguridad del correo electrónico (SMIME)
En el correo electrónico parece más lógico usar el CEE, para mayor seguridad. Por eso cuando se lee el código fuente de un e-mail está cifrado, la aplicación solo lo descifra cuando se lee el mensaje.
DER
Es un formato para e-mail. La información
del mensaje se codifica en binario. Pero la información almacenada
en der no es agradable a la vista y contiene caracteres no imprimibles.
Por ello hay expansores ( uuencode, mimencode, base64 ) que transforman
la información en formato der a un texto en el que solo hay caracteres
imprimibles del código ascii. Por cada tres caracteres de entrada
hay cuatro de salida. El mensaje resultante es más largo pero no
contiene ningún carácter no imprimible.
Los expansores también sirven para
evitar que los agentes de correo electrónico puedan realizar transformaciones
en el mensaje debido a malas interpretaciones de los retornos de carro
y otros caracteres no imprimibles.
Los pkcs12 contienen información
en formato der.
PEM
Un formato de correo electrónico
que ofrece también privacidad. Es un formato que permite enviar
información binaria por el correo electrónico.
La información (en formato der)
que se desea mandar se pasa a base64 y se le añaden estas lineas:
-------------- BEGIN xxx -----------------
al principio
-------------- END xxx -----------------
al final
que señalan el principio y el final
del mensaje. Toda la información de antes del begin y de después
del end es ignorada por el agente de correo.
Entre el begin y el end están la
cabecera y el mensaje cifrado. La cabecera contendrá información
sobre el mensaje, cosas como con que tipo de algoritmo se ha cifrado, destinatario,
emisor, etc... .
MIME
Es un formato de email. Con este formato podemos enviar distintos tipos de archivos en un único email.
El email en formato mime consta de dos partes: Cabecera y Cuerpo, separadas por una línea en blanco.
En la cabecera hay información sobre
el mensaje. En ella podemos encontrar los siguientes campos de los cuales
algunos son obligatorios y otros no:
--MIME-Version. Este campo es imprescindible,
en el se indica la versión del mime que se esta usando. --Content-type.
Indicará cual es el tipo mime del mensaje, es decir el tipo de archivo
que lleva el mensaje, para que así el receptor tenga una idea de
lo que ha recibido y sepa como interpretarlo. Si no está el
content-type se supondrá que el mensaje contiene texto plano sin
formato. Hay una lista de tipos mime en la que hay algunos de los tipos
más habituales y sus subtipos. Si queremos enviar algún subtipo
que no esté definido en esta lista entonces le añadiremos
delante del nombre una x. Ejemplos de tipos:
text/html
image/gif
video/quicktime
application/pdf
message/news
--Content-transfer-encoding. Es campo
imprescindible, el cual indicará como ha sido codificada la información.
Los tipos de codificación son:
7
bit, será el codificador por defecto
8
bit
base64
binary
Quoted-printable
--Contet-description. Será una
descripción en texto plano del objeto del cuerpo. Es útil
cuando el objeto no es legible.
El cuerpo contiene lo que se quiere enviar. Dentro del cuerpo podemos encontrar otro/s mensaje/s mime, ya que está permitida la recursividad.
Cuando se quieren enviar distintos tipos de documento en un mismo email se recurren a unos tipos especiales del mime que permiten hacerlo. El tipo se llama: multipart/ subtipos. Los subtipos del multipart pueden ser: signed, mixed, related, alternative.
-- multipart/ signed. Es el formato llamado SMIME, que es una expansión del mime. Incluye todas las ventajas del mime y además proporciona seguridad.
-- multipart/ mixed. Es la manera de indicar que el email contiene varias entidades mime. En la cabecera de este tipo de mensajes sólo se incluye:
multipart/ mixed ; boundary=???(aquí se pone lo que se quiera)????
Lo que se escriba en el boundary será lo que delimitará cada parte del mensaje mime, por eso hay que escoger algo con cuidado para que después sea fácilmente identificable y no se confunda con el mensaje. No debería aparecer en ninguna de las partes del mensaje.
Cada parte del mime tendrá que tener
su propia cabecera y el cuerpo, separados por una linea en blanco. Las
cabeceras llevarán el content-type y el content-transfer-encoding
pertenecientes a esa parte en concreto.
MENSAJES CIFRADOS
En un email cifrado solo hay una parte,
es todo un bloque en el que no hay partes distinguibles. En el pkcs7 se
describe el formato de un email cifrado.
Pkcs7 permite transportar datos y certificados,
pero llaves no. Modos en los que puede ir el mensaje en el formato pkcs7:
datos tal cual, signed data, enveloped data y signed and enveloped data.
En el signed data es costumbre enviar
una copia del certificado para que el receptor pueda comprobar la firma.
En un mensaje cifrado encontramos:
MIMEversion: (1.0)
content-type: Application/ x-pkcs7-mime
content-transfer.encoding: (base64)
# linea en blanco #
BLOQUE. Aquí estará todo
el mensaje cifrado.
Cuando se descifra se eliminan las tres
lineas del medio, es decir, el mensaje original estará compuesto
por la etiqueta MIMEversion y el bloque descifrado.
MENSAJES FIRMADOS
Los mensajes cifrados han de poder ser
leídos aunque el receptor no tenga la clave pública del emisor
para verificar la firma.
Estructura del email firmado: (consta
de dos partes: mail y firma)
MIMEversion
Content-type:multipart/signed;protocol="application/x-pkcs7-signature";micalg=sha1;boundary="??algo??"
??algo??
MAIL (con sus correspondientes cabecera
y cuerpo)
??algo??
content-type: application/x-pkcs7-signature
content-tansfer-encoding: base64
FIRMA ELECTRÓNICA (pkcs7)
??algo??
4. Seguridad en el web
APACHE
Sirve para controlar el acceso a las páginas
web. Puede ser controlad desde los directorios o desde el servidor.
Cada directorio puede tener sus propias
normas de acceso.
Lo primero que controla apache son la IP
a las que debe dar acceso.
AUTENTIFICACIÓN HTTP
Cuando aparece http en una dirección significa que se va a acceder a un recurso http. Este protocolo incorpora un método de autentificación. Estas páginas se pueden configurar para que requieran al usuario un user y una password, que serán comprobadas de una base de datos. Pero este es un protocolo débil en este aspecto ya que no hay límite de intentos de introducir la password debido a que el web no posee sesión.
SSL
Hay unas directivas que se pueden incluir
en las web que aportan seguridad. Estas directivas pertenecen al protocolo
SSL. Cifra los datos intercambiados entre el servidor y el cliente con
un algoritmo de cifrado simétrico. La clave de sesión es
diferente cada vez, así si queda comprometida una clave no la podrán
usar en posteriores comunicaciones.
Proporciona cifrado de datos, autenticación
de servidores, integridad de mensajes y, opcionalmente, autenticación
de cliente para conexiones TCP/IP.
Por ejemplo:
--SSL required SSL no permite el
acceso sino es con https
--SSL xxxxxxxxx se especifica
lo que se requiere para acceder a la web, en la especificación se
puede poner cualquier cosa, anidando mediante expresiones lógicas
o regulares.