Examen de SPI - I*38 - Septiembre 2006
!!!
-
Al exportar un certificado (y su llave privada correspondiente) instalado en el firefox
(en el m�dulo de seguridad por defecto), para guardarlo en un fichero PKCS12, explica qu�
contrase�as nos va a pedir y por qu�.
%%%
Primero me pide la del m�dulo criptog�fico. Aunque ya la haya introducido antes para usar
las llaves privadas, igual me la pide, por seguridad (puede que me haya levantado un
momento del ordenador ... y alguien se aproveche).
Despu�s me pide la que proteger� el PKCS12, me la pide dos veces por comprobaci�n.
%%%
-
El postgres instalado en lynx usa como contrase�a la misma que tienes en lynx y por tanto
la misma que usas en el e-ujier y para leer el correo. En una pr�ctica de una asignatura tienes que hacer
un script en PHP que muestra al visitante una p�gina para hacer consultas a la base de datos.
Estas consultas necesitan obviamente la contrase�a, que deber� estar disponible para el script PHP
antes de que el visitante haga las consultas.
�C�mo har�s para que la contrase�a no puedan leerla otros usuarios de anubis?.
%%%
Si la pongo en el script la tiene que poder leer el servidor y por tanto habra usuarios
que a podr�n leer. Y si no la pongo no hay acceso a la base de datos.
Una soluci�n es que el visitante antes de hacer las consultas
me pida que yo introduzca la contrase�a, bastar� con una vez por visitante, despu�s podr�
hacer m�s consultas sin mi intervenci�n, pero esta soluci�n exluye visitantes an�nimos.
Nota: no vale proteger el fichero contra lectura porque el php necesita leerse.
Tampoco poner lectura s�lo para otros, pues hay muchos "otros" en el sistema.
%%%
-
El software que controla la interacci�n de las aplicaciones con la zona criptogr�fica del clauer
(denominado clos) permite iniciar sesiones contra el clauer especificando una contrase�a.
Si �sta es correcta, clos devuelve un handle para
el uso de los sectores protegidos, pero si es incorrecta, devuelve un c�digo de error, permitiendo
un n�mero de reintentos indefinido. Teniendo en cuenta la naturaleza f�sica del clauer, discute
las ventajas e inconvenientes de que clos permitiera s�lo tres intentos.
%%%
El clauer es un disco duro, por lo que sus sectores pueden ser leidos por el administrador de sistema
donde se conecta.
Si perdemos el clauer y alguien lo encuentra, en su ordenador podr� leer lo que quiera sin pasar
por el clos, y con unos m�nimos conocimientos de la estructura interna del clauer, o con un
poco de imaginaci�n, podr� realizar
cuantos intentos quiera de acceso a la informaci�n protegida (obviamente in�tiles si la contrase�a
es adecuada). En cambio, un programa malicioso que
corra a nivel de usuario, y que necesitara usar el clos para acceder al clauer, se afectar�a por la
limitaci�n de intentos.
Ventajas:
- Protecci�n contra programas maliciosos no privilegiados.
Inconvenientes:
- Puede resultar molesto para el usuario que intenta leg�timamente recordar su contrase�a.
- Crea una falsa sensaci�n de seguridad, violando el principio de la no oscuridad.
Nota: un cuesti�n aparte ser�a el c�mo limitar a tres intentos. El clauer carece de
capacidad computacional propia. Por tanto, clos lo �nico que podr�a hacer ser�a, o bien no admitir
m�s conexiones de un determinado programa (poco efectivo) o bien destruir la informaci�n del clauer
-- sin comentarios :-) -- .
%%%
-
Sea el mensaje "Soy Bond, James Bond". Se lo env�o a un amigo haciendo un XOR con la cadena
binaria 87CF3A814BA9B7655F2196903020909218AC86151A que fue generada de forma suficientemente
aleatoria
y es secreta y compartida con mi amigo. Si alguien lo intercepta, discute si ser� m�s o menos
seguro que si el mensaje se hubiera enviado cifrado con 3DES con una buena contrase�a.
Si env�o despu�s el mensaje "Soy Brosio, Am Brosio", haciendo un XOR con la misma cadena
y es interceptado por la misma persona, discute lo que pasar�.
%%%
El XOR con una cadena secreta aleatoria es un cifrado perfecto y superior al 3DES y a cualquier otro
cifrado algor�tmico, pues el XOR con algo aleatorio produce algo aleatorio y por ello indescifrable.
En este caso no ser�a arriesgado afirmar que el 3DES (dejando aparte ataques te�ricos) es pr�cticamente
igual de bueno dado que sus 168 bits coinciden con la longitud del mensaje, �pero deber�amos usar
una clave que tuviese 168 reales!.
Pero con el m�todo del XOR, si se vuelve a realizar un XOR
entre otro mensaje y la misma cadena, el XOR de los mensajes
cifrados es el mismo que el XOR de los originales, dando cierta informaci�n sobre ellos. En este
ejemplo, si el atacante hiciera el XOR -- o sin hacerlo :-) --,
descubrir�a que muy probablemente se ha usado la misma
cadena y los primeros 4 caracteres de los mensajes originales son id�nticos. Si esto sucediera para
m�s mensajes, a la larga acabar�a averiguando la cadena y descifrando todos los mensajes.
%%%
-
Explica las diferencias entre la autenticaci�n en servidores mediante usuario y contrase�a
y la autenticaci�n mediante certificados, y explica cuales crees que son las razones de que
�sta �ltima se use menos.
%%%
B�sicamente las diferencias son:
- La aut. con (us,pw) se basa en algo que sabemos y la aut. con cert. en algo que tenemos, la llave
privada, y si �sta est� protegida con una contrase�a, tambi�n se basa en algo que sabemos,
por lo que en general, la aut. con cert. puede considerarse igual o m�s segura que con (us,pw).
-
En la aut. con (us,pw) compartimos esta informaci�n con el servidor, por lo que no es prudente
utilizar la misma pw en servidores ajenos entre s�, pues el administrador de uno podr�a
utilizarla para autenticarse con nuestra identidad en otro. En cambio, con los cert. no compartimos
ning�n secreto con elservidor, con lo que el mismo cert. puede valer para muchos servidores.
Las razones fundamentales par un menor uso de los certs puden ser:
- Dificultades t�cnicas, aunque es pr�cticamente igualde sencillo tratar las contrase�as
que los certificados, hay que consultar revocaciones, etc.
- Dificultad en la gestion de certs.: Hay que tener una CA, aunque podemos emplear una CA
p�blica que emita certificados para ciudadanos. Pero esto, a su vez, choca con ciertos servicios
en la red que, aunque supuestamente no son an�nimos, en la pr�ctica lo son: hotmail, yahoo, etc.
- La raz�n fundamental: la llave privada no es algo que podamos recordar, y si queremos usarla
en distintos ordenadores, como hacemos con (us,pw), necesitamos transportarla de forma segura y
eficiente. El hecho de no existir todav�a un soporte universalmente aceptado cuyos drivers est�n
instalados en lamayor�a de ordenadores, hace que sea dif�cil y muy inc�modo el uso de los cert.
fuera de nuestro propio ordenador.
Nota:
La universalidad del certificado puede estar aparentemente re�ida con el anonimato: en muchos servidores,
el usuario desea anonimato, �l mismo establece usuario y contrase�a y s�lo sirven para autenticar la
operativa, pero no a la persona. Este anonimato tb puede ser alcanzado con certificados, pues el usuario
puede usar un autogenerado, o uno que certifique s�lo un cierto aspecto de su identidad electr�nica, como
por ejemplo, la direcci�n de correo, no necesariamente debemos pensar en que un certificaco
es uno de ciudadano.
%%%