La comprensin de las

limitaciones de la firma digital S /

MIME para mensajes de correo
electrnico: Un enfoque basado
en GUI
RESUMEN:
S/MIME (Secure / Multipurpose Internet
Mail Extensions) es un estndar conocido
para el intercambio de correo electrnico
seguro. S / MIME se basa su gestin de
identidad en las direcciones de correo
electrnico, en lugar de nombres reales.
Este hecho puede causar a veces el envo
de un correo electrnico firmado con un
nombre falso en l. Por otra parte, la
informacin de cabecera de un mensaje
de correo electrnico firmado, como
asunto el nombre, puede alterarse sin
afectar a la verificabilidad de la firma. En
este trabajo se ve a los detalles de este
tipo de problemas de S / MIME y discute
algunas de las soluciones de ambos
puntos de usuarios y desarrolladores de
vista. Por otra parte, las consideraciones
de interfaz grfica de usuario acerca de
estos problemas tambin se analizan en
este documento. Una interfaz grfica de
usuario ideal se modela y se desarroll.
INTRODUCCION
La respuesta a la pregunta de '' Ha
recibido un e-mail inesperado de s
mismo o de otra persona que l / ella no
envi? '', Probablemente sera '' s '' para
una gran mayora de los usuarios de
correo electrnico . Las normas actuales

permiten que casi ningn control por

defecto en la autenticidad de los
remitentes de mensajes de correo
electrnico. Algunos servidores SMTP
(Simple Mail Transfer Protocol) prohben
rels y el mandato de entrar nombre de
usuario y contrasea, incluso para el
envo de correos electrnicos, por lo que
slo los usuarios legtimos pueden enviar
correos electrnicos a otros. Sin embargo,
siempre es posible ejecutar un servidor
SMTP independiente para controles de
autenticacin de by-pass forzadas por los
servidores
SMTP
decente
y
sus
administradores. problema mensaje falso
es poco probable que sea impedido por
las medidas restrictivas, pero los
receptores debe ser capaz de detectar
mensajes falsos. Tenga en cuenta la
(caracol) servicio de correo convencional.
Cualquiera puede escribir cualquier
nombre en una carta y el sobre, y
enviarlo por correo. USPS u otro servicio
postal no tiene nada que hacer para
identificar al remitente. El receptor debe
identificar al remitente mediante la
informacin, en especial la firma, en la
carta. Una situacin similar existe en el
caso del e-mail. El mensaje de correo
electrnico debe contener una especie de
firma para que el receptor puede
identificar
al
remitente.
Afortunadamente, las firmas digitales
criptogrficas son posibles en los correos
electrnicos. Las firmas digitales en los
correos electrnicos estn estandarizados
por el IETF (Internet Engineering Task
Force) como S / MIME (Secure /
Multipurpose Internet Mail Extensions). La
firma de un mensaje es una operacin

criptogrfica que requiere la clave

privada del firmante. Dado que la clave
privada es conocida slo por el firmante y
no se comparte, la salida del proceso de
firma se considera como firma. La
verificacin de una firma digital requiere
la clave pblica correspondiente. Es por
ello que el firmante debe hacer de su / su
clave pblica accesible por otra
gente. Distribucin de claves pblicas en
S / MIME se realiza utilizando certificados
digitales. Sin embargo, S / MIME no es a
prueba de balas. Los problemas de
gestin de la identidad y algunas
decisiones de diseo de S / MIME causan
algunos problemas prcticos en la
percepcin de la verificacin de la firma
por los usuarios promedio. Por ejemplo, el
nombre
del
remitente
podra
ser
cambiado por un atacante y la firma
todava se muestra como verificado. Por
otra parte, el tema original puede ser
modificado sin afectar a la verificabilidad
de la firma.
En este documento, se detallan estos
tipos de problemas de S / MIME.
Proponemos
algunas
soluciones
y
desarrollar criterios para una interfaz
grfica de usuario ideal que lleva hechos
S / MIME a los usuarios de una manera
adecuada.
En la Seccin 2 se muestra una visin
general del esfuerzo de S / MIME del IETF.
S / MIME prefiere el uso de direcciones de
correo electrnico como identidades, no
nombres reales. Las razones de este
hecho y posibles consecuencias se
resumen en la Seccin 2 tambin.
Seccin 3 se trata de demostracin de
algunos problemas prcticos en S / MIME.

Tambin proponemos algunas soluciones

en la misma seccin. Seccin 4 discute
las consideraciones acerca de la GUI S /
MIME; define una interfaz grfica de
usuario ideal y se compara con algunos
clientes de correo electrnico existentes.
Las discusiones y conclusiones se
presentan en la Seccin 5.
2.1. Certificados digitales
Los certificados digitales (identidades
digitales
alias)
son
ampliamente
utilizados como un mecanismo que
permite a las aplicaciones pblicas de
criptografa de clave basados. Los
certificados que se utilizan para S / MIME
se vinculaciones entre la identidad de los
titulares de certificados y sus claves
pblicas aprobadas. Los certificados son
emitidos por entidades emisoras de
certificados de confianza (CA) con su
firma digital sobre el contenido del
certificado. Antes de la verificacin de la
firma sobre el mensaje de correo
electrnico, el destinatario verifica la
firma sobre el certificado del remitente
para averiguar su / su clave pblica. De
esta manera, el destinatario se asegura
sobre la identidad de la persona de la que
l / ella est utilizando la clave pblica
para la verificacin de la firma. En
general, una serie de certificados que se
verifica a partir de una raz-CA de
confianza, para los que el receptor
conoce la clave pblica. Las claves
pblicas (certificados de firma propia
realidad) de conocida la Root-CAs vienen
con clientes de correo electrnico
habilitado S / MIME.

2.2. Cmo S / MIME funciona para

los mensajes firmados digitalmente?
Una vez que el contenido del mensaje
est listo, el remitente genera su / su
firma digital sobre el contenido y lo anexa
al mensaje. Remitente generalmente
enva a su / su certificado junto con el
mensaje firmado. El receptor procesa el
certificado y la firma de mensajes por
separado. En primer lugar el certificado
se verifica como se describe en la
Seccin 2.1. La clave pblica obtenida de
la verificacin del certificado se utiliza
para verificar la firma sobre la direccin
de correo. Por otra parte, la direccin de
correo electrnico en el certificado se
compara con el del mensaje de correo
electrnico; que deben ser iguales.
Higo. La figura 1 muestra el ciclo de vida
de un mensaje firmado enviado desde
Alice a Bob. Si todas las verificaciones y
controles en el receptor (Bob) estn bien,
entonces el cliente de correo electrnico
muestra un indicador de un mensaje
firmado y verificado con xito.
2.3. los esfuerzos de normalizacin
relacionados con S / MIME
La normalizacin es una necesidad para
la interoperabilidad adecuada entre las
distintas
correo
electrnico
(SMTP)
servidores, clientes y AC. S / MIME es un
esfuerzo de la IETF (Internet Engineering
Task Force), grupo de trabajo S / MIME
Mail Security (S / MIME WG). El grupo de
trabajo ha propuesto varias normas pista
RFC informativos y experimentales y
borradores de Internet que se puede
acceder desde la pgina web del Grupo
de Trabajo (/ MIME S Grupo de Trabajo,
2008).

S / MIME se basa tambin en algunos

otros estndares y RFC. Para el
procesamiento criptogrfico PKCS (Public
Key
Cryptography
Standards)
(RSA
Laboratories, 2008) se refieren en varios
documentos S / MIME. certificados S /
MIME se basan en PKIX (Infraestructura
de Internet X.509 Public Key) iniciativa
(Grupo de Trabajo PKIX, 2008),
y en consecuencia en el estndar X.509
(UIT-T, 2000).
En cuanto a los servicios postales
bsicos, S / MIME depende de RFC 2821
(especificacin de SMTP) (Klensin, 2001),
RFC 2822 (especificacin de formato de
mensaje)
(Resnick,
2001).
especificaciones
MIME
(Freed
y
Borenstein, 1996a; Freed y Borenstein,
1996b; Moore, 1996; Freed y Klensin,
2005; Freed y Borenstein, 1996c) tienen
una fuerte relacin con S / MIME as.
En este trabajo, que en su mayora se
refieren a la RFC 2632 (S / MIME versin 3
Certificado de Manejo) (Ramsdell, 1999a)
y RFC 2633 (Ramsdell, 1999b) (S / MIME
versin 3 Mensaje Especificacin). S /
MIME versin 3.1 de ambos RFC tambin
se public como RFC 3850 (Ramsdell,
2004a) y RFC 3851 (Ramsdell, 2004b),
respectivamente. Versin 3.1 obsoletes
versin anterior. Sin embargo, puesto que
todas las implementaciones S / MIME que
hemos tomado conocimiento todava
llevan versin 3.0 caractersticas para el
procesamiento de la firma digital, la
versin 3.0 es ms relevante que la
versin 3.1 de este documento.
2.4. La gestin de identidad en S /
MIME: principios y problemas

S / MIME se abstuvo sistemticamente el

uso de nombres reales como elementos
de identidad primarias de verificacin de
firma electrnica. En su lugar, utiliza
direcciones de correo electrnico para
este propsito. Las posibles razones
incluyen:
(I) La imposibilidad de tener un nombre
nico a nivel mundial, as posibles
ambigedades de nombres (por ejemplo,
podra haber dos John Smiths en,, la
misma unidad organizativa misma de la
organizacin del mismo pas)
(Ii) la dureza de la obtencin de un
nombre
estndar
de
campos
de
certificado complejos, y
(Iii)
la
atraccin
insoportable
de
direcciones de correo electrnico nicos
globales y especficas de la aplicacin.
Por desgracia, esta decisin de diseo
desencaden dos problemas importantes:
1) La informacin de nombre en el
certificado y el nombre en el mensaje de
correo electrnico a ser independientes
entre s, as que el nombre de
informacin en un certificado S / MIME
pierde su importancia en la verificacin
de la firma electrnica.
2) Los receptores se hacen cumplir para
identificar a las personas que utilizan sus
direcciones de correo electrnico. Esto
puede no ser la prctica comn. La gente
tiende a identificar a otras personas
usando sus nombres reales. Algunos
clientes de correo electrnico muestran
slo los nombres de las ventanas de
mensajes y / o paneles de vista previa.
Estos problemas, junto con algunos
defectos en las prcticas de certificacin
y el alcance de la firma en los mensajes

de correo electrnico, hacen que algunos

ataques prcticos sobre esquema de
firma S / MIME. Ms adelante se
describen en la Seccin 3.
3. Los problemas prcticos de S /
MIME
S / MIME proporciona servicios de
seguridad a los fuertes mensajes de
correo electrnico.
Sin embargo, todava hay algunos
problemas
prcticos
de
seguridad
especialmente
en
la
gestin
de
identidades, la gestin de certificados y
proteccin de cabecera. En esta seccin,
se explican los problemas
que existen en S / MIME versin 3, y
discutir algunas soluciones
y los esfuerzos de S / MIME del Grupo de
Trabajo para resolverlos en la Versin 3.1.
Se discuten tres cursos de problemas y
ataques contra S / MIME. 1. Uso de
identidad falso de clase en-1 certificados
2. El uso de un nombre diferente de aquel
en el certificado
3. Los temas de proteccin de
Cabecera
3.1. identidad falsa en la clase-1
certificados
AC realizar el control de identidad antes
de la emisin de un certificado.
Aunque no es una regla estndar,
Stallings (2006) analiza tres diferentes
niveles (clases) de los controles de
identidad. Aqu nosotros
dar una breve descripcin de estas
clases de ttulos que podran
ligeramente diferentes de CA a CA en la
prctica.

, Clase 1: Clase 1-emisin del certificado

es un proceso en lnea.
Nombre de la entidad sujeto no se valida.
Slo un e-mail control de direccin se
lleva a cabo mediante el envo de una
autenticacin cadena a la direccin de
correo electrnico que proporciona la
entidad sujeta
en la solicitud de certificado. Con el fin de
completar el certificado proceso de
emisin, la entidad debe utilizar este
tema cadena de autenticacin. Esta
direccin de correo electrnico aparece
en el
certificado. Algunas entidades emisoras
incluyen el nombre de la entidad sujeta
en el certificado, as, pero se especifica
que el nombre no es
validado.
Sin
embargo,
la
accin
apropiada sera no
incluir un nombre en un certificado de
clasificacin-1,
como
algunas
otras
entidades emisoras hacen.
, Clase 2: El proceso de certificacin
puede estar o no estar en lnea
dependiendo de la prctica de la AC.
informacin de la entidad sujeta
(Como el nombre y direccin) se
comprueba frente a un tercero base de
datos.
Algunas
entidades
emisoras
podrn solicitar a la entidad sujeta a
enviar
un acuerdo firmado en papel y / o una
copia impresa de identidad documento
por fax o por correo. Sin embargo,
personal No se requiere la presencia.
control
de
direcciones
de
correo
electrnico como en el Tambin se lleva a
cabo el certificado de clasificacin-1. ,
Clase 3: Adems del control de direccin

de e-mail, la
entidad sujeta debern
presentar un documento de identidad
personal
a una autoridad de registro. El proceso
est fuera de lnea y puede tomar algn
tiempo para ser completado. certificados
de clasificacin-1 proporcionan menor
grado de identidad
aseguramiento, pero son los ms fciles
de emitir y barata. As se vuelven muy
populares
entre
los
titulares
de
certificados. El nivel de fiabilidad dada en
un
certificado
es
ms
de
una
preocupacin de la entidad par, que
verificar el certificado,
que del titular del certificado. Por lo
tanto, los titulares de certificados por lo
general no les importa la falta de control
de identidad en la clase-1
certificados. Los certificados raz para
todas las clases de ttulos vienen con el
software
de
cliente,
por
lo que
prcticamente todos los certificados son
verificable y no hay ninguna diferencia
notable entre ellos desde el punto de
vista de un destinatario de la media. Por
otra parte, el uso de un certificado de
clasificacin-3 no hace que el propietario
del certificado criptogrficamente
ms seguro; todas las clases de
certificados de uso de la mismos
algoritmos de firma y son capaces de
pblico que certifique llaves de la misma
potencia
criptogrfica.
Como
se
mencion anteriormente, los certificados
de clase 1 no contienen
nombres validados. De hecho, es posible
obtener una clase-1 certificado de una CA
respetable con un nombre falso en l.

Por otra parte, los programas cliente de

correo
electrnico
permiten
usar
cualquier nombre
mientras se enva un mensaje de correo
electrnico. Estos dos hechos permiten el
envo de un S / MIME firmado mensaje
con un nombre falso. los
clientes de correo electrnico que hemos
considerado
(a
saber,
Netscape
Messenger;
7.2, MS Outlook XP y 2007, Mozilla
Thunderbird 1.5.0.10, y MS Outlook
Express 6) verificar esta firma con xito y
presentar el mensaje firmado como si se
enva
por
el
nombre
falso.
Los
Especificaciones S / MIME no hacen
cumplir el cliente de correo electrnico
programas para mostrar la informacin
de verificacin de firma en una forma
estndar. Es por eso que cada cliente
tiene interfaz grfica de usuario diferente
a mostrar un mensaje de correo
electrnico y la firma correspondiente
informacin.
Nosotros
analizamos
comparativamente las interfaces grficas
de diferente programas cliente de correo
electrnico
en
el
Captulo
4.
A
continuacin,
damos
dos
ejemplos
Interfaces grficas de usuario que
pertenecen a MS Outlook Express 6 y
Mozilla Thunderbird en la Fig. 2; las
interfaces grficas de usuario dicen que
John Doe ha firmado el mensaje, que es,
por supuesto, no es el caso. En este caso
de ejemplo, el certificado se obtuvo
incluye un nombre falso en ella. Sin
embargo, la mayora de las entidades
emisoras no incluyen los nombres de
certificados, ya que no garantizan la
identidad de clase 1. nuestro ataque

todava es posible con este tipo de

certificados de clase 1. S / MIME no lo
hace
hacer cumplir una verificacin del
nombre de existencia en fase de
verificacin del certificado.
Por lo tanto, es posible utilizar cualquier
nombre al enviar firmado mensajes,
incluso si el certificado contiene ningn
nombre en ella. Puesto que el S / MIME
clientes realizan una coincidencia entre el
direccin de correo electrnico en el
certificado y la direccin de correo
electrnico en el encabezado del correo
electrnico, el remitente debe utilizar la
direccin de correo electrnico dentro de
el certificado. Esta direccin sera
definitivamente diferente de la direccin
real de la persona cuya identidad se est
robado. Esto puede llevar al receptor a
darse cuenta de que existe
algo malo, si el receptor identifica los
remitentes de correo electrnico por sus
direcciones de correo electrnico en lugar
de sus nombres. Sin embargo,
las personas suelen utilizar nombres
reales
para
la
identificacin.
Los
identificadores de polticas que apuntan a
los CPS (Certificado Declaracin de
Prcticas) de la CA puede ser otro indicio
para el
destinatario
para
comprender
las
limitaciones de clase-1 certificados. Sin
embargo, tal control CPS puede requerir
una lectura largo, y
a veces la experiencia en tecnologa de
seguridad para la comprensin. Otra de
las acciones que el receptor puede tomar
es comprobar los detalles del certificado
haciendo clic en algunos botones. AC

mayora poner un comentario en el

certificado de mencionar que la persona
est No validado. Sin embargo, un
usuario con la informacin tcnica media
acerca de la seguridad no puede
comprender fcilmente los detalles de un
certificado, en especial cuando su / su
popular cliente de correo electrnico
programa dice '' el mensaje ha sido
firmado y confirmado '', y muestra el
nombre del remitente en el encabezado
del mensaje. En efecto,
hay algunos estudios en la literatura que
ha
propuesto
el
problemas
de
comprensin y uso de la funcin de
seguridad que existe en los programas de
los usuarios finales. Whitten y Tygar
(1999) analizaron PGP y conocer una
serie de interfaz de usuario fallas de
diseo que pueden contribuir a los fallos
de seguridad. Furnell et al. (2006) ha
realizado recientemente un estudio de
encuesta y lleg a la conclusin de que
ms de la mitad de la MS Outlook Express
usuarios
muestran
deficiencias
importantes en la comprensin de suficiente informacin sobre el cifrado del
correo electrnico y la firma digital. Otro
trabajo reciente de Furnell (2005)
destacado
problemas de los usuarios en trminos de
encontrar, la comprensin, y en ltima
instancia, el uso de los elementos de
seguridad que estn destinados a estar
en su disposicin. Como estos estudios
mostraron, la interfaz de usuario
con la que los elementos de seguridad se
presentan a los usuarios es muy
importante para un usuario medio para
protegerse a s mismo / a s misma.

Los usuarios deben ser educados para ser

ms conscientes de la limitaciones de
clase-1 certificados con el fin de no
cometer el servicio de correo electrnico
ms inseguro en nombre de la seguridad.
Por lo tanto, para identificar la clase-1
certificados y avisar al destinatario con
un mensaje de interfaz grfica de usuario
adecuada, aunque no es un mandato de
la estndares S / MIME. Se propone tal
solucin basada en una interfaz grfica
de usuario y
implementado en los puntos 4.3 y 4.4.
soluciones ms radicales podran ser: (a)
la interrupcin de la clase-1 emisin de
certificados por las entidades emisoras
y / o (b) detener la clase-1-CA raz
distribucin
de
certificados
con
programas
de
cliente
de
correo
electrnico, de modo que la
los receptores se hacen cumplir para
hacer una decisin de confianza en los
certificados. Francamente no creemos
que estas soluciones son aplicable en las
condiciones
del
mercado,
debido
principalmente a dos razones:
1) es contraria al acuerdo de beneficio
mutuo entre las CA y el desarrolladores
de clientes de correo electrnico, 2) una
accin de este tipo hara que el
la penetracin de certificados entre los
usuarios de Internet peor.
3.2. El uso de un nombre diferente
de aquel en el
el certificado
La nica conexin entre un certificado y
un e-mail
el mensaje es la direccin de correo
electrnico. S / MIME versin 3.0 de
verificacin

mandatos de proceso que tienen la

misma direccin de correo electrnico
tanto en el
certificado de emisor y en el encabezado
del mensaje de correo electrnico. Sin
embargo,
S / MIME versin 3.0 no exige una
comparacin entre el nombre en el
certificado y el nombre de la direccin de
correo de acuerdo con RFC 2632, Seccin
3 (Ramsdell, 1999a). S / MIME Versin 3.1
(RFC 3850) tiene el mismo proceso de
verificacin como bien. Este proceso de
verificacin permite que el remitente sea
capaz de enviar un mensaje de correo
electrnico
firmado
utilizando
una
direccin de correo electrnico que existe
en un certificado, pero con un nombre
diferente. Por supuesto, la
campos de certificado no van a cambiar,
pero el e-mail se compruebe si es de otra
persona. Un ejemplo se muestra en la Fig.
3, superior instantnea izquierda. El
certificado utilizado en este ejemplo es el
mismo como la utilizada para el ejemplo
dado en la figura. 2. Como se puede ver
desde el campo '' de '', el nombre del
remitente es diferente y esto es
no el nombre que aparece en el
certificado; pero la firma Todava se
verifica.
Por otra parte, este problema particular
no es un problema de solamente
certificados
de
clasificacin-1,
sino
tambin de la clase-2 y el certificado de
clasificacin-3 as como. El problema est
en la verificacin de firma electrnica
proceso. Este proceso es independiente
de las clases de certificados y el nivel de
seguridad
de
identidad
en
los

certificados. Mientras los nombres no se

comparan durante la verificacin, no
importa
la forma de verificacin de identidad
fuerte se proporciona en el certificado.
emisin, esta seguridad no ser capaz de
ser transmitida a
verificacin de firma. El destinatario
puede comprender la existencia del
problema
mediante la comprobacin de direccin
de correo electrnico del remitente, que
es el original
del titular del certificado direccin de
correo electrnico (Fig. 3, la instantnea
superior derecha),
o mediante el examen de los detalles del
certificado, que muestran la Nombre y
datos del titular de certificado original.
Afortunadamente, S / MIME versin 3.1
(RFC
3850)
(Ramsdell,
2004a)
recomienda para mostrar el nombre y
otros detalles del certificado
cuando se muestra una indicacin de
xito o fracaso
verificacin de firma. Hemos probado
alguna S / MIME programas cliente de
correo
electrnico
compatible
para
evaluar cmo se transmiten
nombre
y
otros
detalles
de
los
certificados a los usuarios finales. Los
detalles de este anlisis se dar en la
Seccin 4.2 y 4.3, pero aqu dar una
breve descripcin y un ejemplo. Estas
pruebas muestran que los clientes de
correo electrnico, ya sea transmiten la
informacin del nombre de algunos
ventanas finales que aparecen despus
de hacer clic en tres o cuatro botones, o
de una manera confusa. Un caso de

ejemplo se muestra en la Higo. 3 para MS

Outlook Express 6. Como se muestra en
esta figura, la nombre en el certificado se
muestra despus de tres clics. de usuario
similar
Consideraciones
sobre
las
interfaces para otros sistemas cliente de
correo electrnico lo har se detallar
ms adelante en la Seccin 4. En
realidad, como se discuti en la seccin
anterior, no es una buena idea confiar en
los controles fuera de lnea de receptores
sobre los nombres o cualquier otro campo
del certificado para asegurar la validez de
una firma. expectativa de los usuarios 'de
un cliente de correo electrnico seguro el
software se automatiza la deteccin de
una anomala. Sin embargo, ninguno de
los clientes de correo electrnico realice
el nombre consistencia comprobar ya que
no es parte del estndar S / MIME.
3.3. E-mail alteracin de cabecera
Bsicamente hablando, un mensaje de
correo electrnico consta de dos partes:
'' Cabecera '' y '' contenido '' (contenido
es nombrado como el '' MIME entidades ''
en S / MIME documentaciones). Header
contiene el envolver la informacin, al
igual que desde, hacia, cc, fecha, asunto,
etc. Contenido no contiene la cabecera.
RFC 2633, Seccin 3.1 (Ramsdell, 1999b)
establece claramente que S / MIME
versin 3 es estar
utilizado para asegurar el contenido, no
la cabecera. Este hecho causas cualquier
alteracin maliciosas en el encabezado
del correo electrnico a no se detectan.
Un ataque prctica podra ser la
alteracin de la materia campo de un
mensaje por el receptor. Por ejemplo,
considere una Un inversor enva un

mensaje firmado a su corredor de B para

comprar X Inc. las acciones en el campo
del asunto y deja el espacio en blanco
cuerpo del mensaje.
B compra por error existencias Y en lugar
de X. Para compensar
este error, B
puede actualizar la fuente del mensaje de
tal manera que el asunto del mensaje de
las existencias A las rdenes ahora Inc. Y.
El mensaje alterado todava est firmada
y verificada de forma digital. En otro
escenario, un atacante podra modificar
el asunto campo, mientras que el
mensaje est en camino. Se muestra un
escenario de tales en la Fig. 4a y b. Higo.
4a muestra el mensaje original y su
fuente. Higo. 4b muestra el mensaje
alterado y la fuente. Adems del campo
de asunto, otros campos de cabecera,
como hacia, desde, cc, fecha, todo puede
ser alterado sin afectar a la verificabilidad
de
la firma existente sobre el contenido del
mensaje. Lo nico excepcin es la
direccin de correo electrnico (pero no el
nombre) a partir de la campo. Si se
modifica esta direccin, la firma se
convierte en no verificable debido a la
direccin
de
correo
electrnico
verificacin cruzada S / MIME de.
Una precaucin contra la alteracin
cabecera no es confiar en el informacin
de encabezado de correo electrnico, que
no es sino un sobre es
que puede ser alterado. El remitente
debe poner toda sensibles informacin,
incluyendo su / su nombre, afiliacin,
direccin y la informacin de los
destinatarios, asunto, fecha, etc., en el
Cuerpo del mensaje. S / MIME versin 3.1

(RFC 3851 (Ramsdell, 2004b)) ofrece una

proteccin encabezado opcional en cierta
medida, pero esto proteccin tiene
algunos
problemas
prcticos
como
veremos a continuacin.
El mtodo propuesto por RFC 3851
(Ramsdell, 2004b) es encapsular el
mensaje real en un nico objeto de MIME
tipo de mensaje / rfc822 como un archivo
adjunto y aplicar el S / MIME firma a este
objeto. Este mensaje / rfc822 firmado
MIME objeto se va a unir a otro mensaje
de correo electrnico que ser enviado al
destinatario. En este mtodo, los campos
de cabecera
del mensaje real sera en el mbito de lo
digital
firma. Sin embargo, el encabezado del
mensaje exterior que lleva el mensaje
real en su fijacin no est en el alcance
de proteccin S / MIME. Por lo tanto, con
el fin de la proteccin de la
(Encapsulado) mensaje real que se desea
transmitir a la verificacin destinatario
del correo electrnico, el mensaje
encapsulado se debe mostrar
como el nico mensaje. Aunque, RFC
3851 recomienda el clientes de correo
electrnico para mostrar el mensaje
encapsulado como el exterior
(Y por lo tanto solamente) mensaje al
destinatario, esto no hace cumplir con los
estndares del IETF relacionados con el
correo electrnico actual y el correo
electrnico implementaciones de los
clientes. Estndar existente mensaje /
rfc822 el procesamiento en el lado del
receptor es mostrar el encapsulado
mensaje como un archivo adjunto y
mostrar la cabecera del exterior

4. Consideraciones de interfaz de
usuario
Las precauciones discutidas por los
problemas dados en la Seccin 3 son
parcialmente interfaz hombre-mquina
(HCI) relacionado. Como se discutio en
(Johnston et al., 2003) de la interfaz de
un sistema es
importante y no se puede descuidar, en
particular en un valor ambiente. Por lo
tanto el rediseo de los usuarios de
correo electrnico de los clientes
nterfaz para capturar la asistencia de los
usuarios en caso de problema de
seguridad mejorara la seguridad general
de la sistema. En esta seccin, primero
describimos los criterios GUI que abordar
los problemas identificados en la Seccin
3. A continuacin, analizamos cmo los
clientes de correo electrnico actuales
cumplen con estos criterios y definir una
interfaz grfica de usuario ideal. Durante
nuestro anlisis, hemos considerado seis
diferentes programas cliente de correo
electrnico que son compatibles con S /
MIME. Estos son a saber, MS Outlook
Express, Microsoft Outlook XP, MS
Outlook 2007, Netscape Messenger 7.2,
Mozilla Thunderbird 1.5.0.10, y Eudora
7.1 con plug-in S / MIME. Las
caractersticas que cumplen
los criterios se muestran en cursiva en las
tablas de anlisis. Los tablas de anlisis
tambin muestran las caractersticas de
una interfaz grfica de usuario ideal.
Adems, la interfaz grfica de usuario
ideal se desarroll como una extensin de
Mozilla. Los criterios que consideramos se
agrupan en tres
categoras:

- El alcance de S / MIME firma

- El control de direccin de correo
electrnico en la verificacin
- Transmisin de la informacin del
certificado al verificador
4.1. criterios GUI para el alcance de
la firma
Como se mencion en la seccin 3.3, el
alcance de un S / MIME firma es el cuerpo
del mensaje, no los encabezados. La
interfaz grfica de usuario debe
reflejar este hecho, tanto en la
verificacin y firma.
Declaracin clara sobre el alcance de la
firma (verificacin): El forma bsica para
transmitir el alcance de verificacin de
firma S / MIME es tener una clara
declaracin que especifica que la firma
no verifica la cabecera, pero verifica slo
el cuerpo de la mensaje. Este mensaje
debera aparecer en la ventana que se
correo
electrnico
se
muestra
al
verificador. Declaracin clara sobre el
alcance de la firma (firma): No slo el
verificador, sino tambin el firmante debe
ser informado acerca de la mbito de
aplicacin de firma digital S / MIME
mientras que la firma. As, cada vez el
firmante selecciona la opcin para firmar
digitalmente un mensaje,
debe haber un mensaje claro de que
menciona que el alcance
de la firma no contiene la cabecera.
Preferiblemente, el firmante debe ser
aconsejado para incluir su nombre y otra
informacin necesaria para ser firmado
en el cuerpo del mensaje.
Otras precauciones en la fase de
verificacin que pueden reducir la
posibilidad de malentendidos que la

cabecera
es
protegidos
son
los
siguientes:
Sin verificacin de mensaje / icono en la
pantalla de cabecera: El icono o el
mensaje de verificacin no debe aparecer
en la cabecera
parte de la ventana de correo electrnico,
ya que tiene dicha verificacin indicacin
en la parte de cabecera hace que los
usuarios a pensar que
la verificacin se inicia a partir de ese
punto. La mejor parte para poner un
mensaje de verificacin de firmas y / o un
icono es el comienzo
del cuerpo del mensaje o entre el cuerpo
del mensaje y el encabezamiento.
No aparece el icono de verificacin en el
panel de vista previa: No debera haber
un icono que muestra que el mensaje
est firmado en el Lista de mensajes de
parte del panel de vista previa. La razn
es que en
esta lista slo se muestra la informacin
del encabezado. Dado que la cabecera no
est protegido, al ver una indicacin de la
firma existe
puede inducir a error a los usuarios.
Como se muestra en la Tabla 1, ninguno
de los clientes de correo electrnico que
examinada tiene declaracin sobre el
alcance de S / MIME la firma tanto en
firma y verificacin. Con respecto a
precauciones, Eudora tiene la mejor
precaucin ya que no hace tener un icono
o un mensaje, tanto en la cabecera y el
panel de vista previa. Como se muestra
en la Fig. 5, Eudora tiene un mensaje de
verificacin en el cuerpo del mensaje,
justo antes de que el mensaje real. En
Outlook XP, el mensaje de verificacin y

el icono se encuentran entre el mensaje y

la cabecera, y separado de la cabecera
con
una lnea (Fig. 6). Outlook 2007 tambin
tiene un icono y mensaje similar
al final de la parte de cabeza, pero a
diferencia de Outlook XP, se ven como
partes de la cabecera (Fig. 7). Netscape y
Thunderbird, como se muestra en la Fig.
2b, solo tienen un icono de la forma de la
pluma. Entre estos clientes de correo
electrnico, el peor de los casos (es decir,
el ms engaoso) cabecea es
la de Outlook Express, ya que ambos
icono y el mensaje inducir a error de
usuario como se muestra en la Fig. 2a.
4.2. Criterios de GUI para la
direccin de correo electrnico
el control en la verificacin Como se
mencion en la seccin 2.2 y varias
partes de la Seccin 3,
estndares S / MIME cumplir el software
de verificacin de cotejar la direccin de
correo electrnico en el certificado y el de
la encabezados de correo electrnico. La
interfaz grfica de usuario debe contener
varios temas relacionados
con
este
control.
Mensaje
sobre
verificacin de la direccin de correo
electrnico: El hecho de que
el proceso de verificacin slo comprueba
la direccin de correo electrnico de la
remitente como la identidad debe ser
visualizado por el verificador. Los mejor
manera de hacer esto es tener un
mensaje de texto que dice: que el
mensaje fue firmado por direccin de
correo electrnico del remitente. En otras
palabras, este mensaje debe obligar a la
firma o el firmante a la direccin de

correo electrnico. Este mensaje debe

aparecer en
la ventana de correo electrnico de
manera que el verificador no debe hacer
clic en algo que ver esta informacin.
Nos
caracterizamos
este
tipo
de
accesibilidad como '' 0-clic '' (en general,
definimos '' n-clic asequibilidad '', donde
n es el nmero de clics necesarios para
conseguir
esa ventana). Dado que
conceptualmente la firma no cubre
cabecera, la interfaz grfica de usuario
tambin debe reflejar este hecho
mediante la separacin de esta
mensaje de la cabecera.
Transmisin de informacin almacenada
en nombre de certificado: En el mensaje
descrito en el criterio anterior, el nombre
del remitente debe estar
deliberadamente
escondido
del
verificador ya que la norma proceso de
verificacin S / MIME no verifica el
nombre. Sobre el
otro lado, si la
informacin del nombre est incluido en
el firmante de certificado, este campo
certificado debe ser transmitida al
usuario. Esto es debido al hecho de que
algunos ataques se basan en el nombre
spoofing como se explica en la seccin
3.2 y la visualizacin de esta
campo del certificado podra advertir al
usuario sobre el ataque. El ideal lugar
para mostrar el campo de nombre de
certificado est en una por separado
ventana o cuadro de dilogo que puede
ser alcanzable en 1-clic. Sin embargo,
la frase nunca debe unirse el nombre de
la firma;
en cambio el nombre debera citarse
como un campo certificado solamente.

Advertencia sobre el correo electrnico

inconsistencia direccin: En caso de una
incoherencia entre la direccin de correo
electrnico de la persona que firma
certificado y la direccin de correo
electrnico en el encabezado del mensaje
( '' De '' cabecera), el usuario debe
verificar advirti. Esta advertencia puede
ser un mensaje de texto o un icono que
refleja la situacin.
Nombre informacin en el encabezado:
La parte de la direccin de correo '' de ''
encabezados pueden contener el nombre
y direccin de correo electrnico de la
remitente. Algunos clientes de correo
electrnico pueden mostrar el nombre y
la
direccin en la parte de cabecera de la
ventana de mensaje. Sin embargo,
algunos otros pueden mostrar slo el
nombre. Tener un solo nombre
la informacin en la parte de la cabecera
de la ventana de correo electrnico
puede
hacer que el verificador a pensar
errneamente que se firme ese mensaje
por esa persona independiente de la
direccin de correo electrnico. Como
se mencion antes, el control de nombre
no se realiza durante el verificacin de la
firma S / MIME. Por lo tanto, mostrando
slo la nombre en la cabecera es
engaosa;
los
clientes
de
correo
electrnico debe mostrar slo la direccin
de correo electrnico o ambos direccin y
el nombre
juntos. Nombre Informacin en el panel
de vista previa: Debido a las razones se
explica en el prrafo anterior, la
informacin del nombre no debe ser la

nica informacin del remitente que se

muestra en el panel de vista previa
tambin. En cambio, el panel de vista
previa debe mostrar
ya sea la direccin de correo electrnico
del remitente o ambas direcciones y
nombrar juntos.
verificacin de la firma S / MIME realidad
abarca
varios
controles,
como
la
validacin de certificados, la alteracin
de contenido, etc., Adems de la
direccin
de
correo
electrnico
verificacin cruzada. Los requisitos de la
GUI para todos los controles no se tratan
en este documento para el
aras de la brevedad y puesto que estos
controles
no
estn
directamente
relacionados
a los ataques cubiertos en la Seccin 3.
El anlisis de los dos primeros criterios se
da en la Tabla 2. Como se puede ver all,
ninguno de los clientes de correo
electrnico que hemos analizado
cumplir con todos los criterios. Sin
embargo, a excepcin de Eudora que falla
en todo aspectos, otros clientes pueden
mejorarse fcilmente. Todos los clientes,
excepto Outlook XP, o bien visualizar el
correo
electrnico
de
verificacin
mensaje a la 1-clic o clic con el botn a 0
pero al encabezado. Este mensaje se
debe mostrar en 0-clic separada de
cabecera; esto es
realizable. Como un buen ejemplo, la
ventana de correo electrnico de
Microsoft Outlook
XP se mostr en la Fig. 6. Perspectivas
2007 ventana de correo electrnico es
similar a Outlook XP (Fig. 7), pero el
mensaje que parece ser parte de la

encabezamiento. Adems, los productos

de Outlook tienen xito en mostrar la
direccin
de
correo
electrnico
correctamente (es decir, ligada a la firma
y / o firmante) en 1-haga clic en Windows.
Por ejemplo, la ventana de 1-Click
Outlook XP se muestra en la Fig. 8. Todos
los productos de Outlook muestran la
nombrar informacin con una interfaz
grfica de usuario adecuada (por ejemplo
para MS Outlook XP,
ver Fig. 9) y el mensaje, sino que se
muestran un poco tarde; ellos debe
mover la ventana en la que se muestran
el nombre de 1-clic. Por ltimo, Netscape
y Thunderbird deben mejorar sus GUI por
desatar la informacn del nombre de la
firma y firmante. La ventana de 1-clic de
Thunderbird es dada en la Fig. 10. Como
puede verse en esta figura, la direccin
de correo mensaje de direccin cumple
los criterios, pero el mensaje de nombre
no lo hace, ya que est vinculada al
firmante / firma.
El anlisis de los tres ltimos criterios se
da en la Tabla 3. Aunque la mayora de
los clientes (excepto Outlook Express)
contienen correo electrnico
direcciones en la cabecera, ninguno de
los clientes lo hacen en el panel de vista
previa. El panel de vista previa de
Thunderbird se da en Higo. 11 como un
ejemplo. Excepto la familia de Outlook
(XP y 2007), todos los clientes realizan
direccin de correo electrnico cotejar y
transmitir este control para la verifi- Fiers
como iconos y / o mensajes. Sin
verificacin cruzada se realiza y la firma
se considera que se han verificado en MS
Outlook 2007 y

XP incluso si la direccin de correo

electrnico en la cabecera del mensaje y
el
direccin de correo electrnico en el
certificado son diferentes. Aunque esto
Parece frente a los requisitos estndar S /
MIME, la verificacin mensaje y el
encabezado
de
correo
electrnico
muestran
la
direccin
de
correo
electrnico diferencias, como se muestra
en la fig. 12 (para Outlook 2007). Sin
embargo, verificar que el usuario debe
examinar la GUI y darse cuenta de esto

Problemas en su / su propio; esto puede

no ser fcil para un promedio
usuario.
4.3.
criterios
GUI
sobre
la
retransmisin del certificado
informacin para el verificador El
software de verificacin de S / MIME debe
verificar primero el firmante certificado
como se ha mencionado en la seccin
2.2. Sin embargo, el nico verificado
unin entre certificado y el mensaje es el
correo
electrnico
direccin
del
remitente. Los criterios relacionados con

la retransmisin este hecho para el

verificador se ha detallado en el anterior
seccin. Por otra parte, los criterios
relacionados con la retransmisin del
nombre
campo
del
certificado
al
verificador tambin se discuten all. Por
otro lado, sin mostrar adecuadamente el
contenido de el certificado del firmante al
verificador, el proceso de verificacin no
puede ser plenamente comprendido por
el verificador, pero el