Examen de SPI - I*38 - Septiembre 2006

!!!
  1. 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. %%%
  2. 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. %%%
  3. 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:Inconvenientes:

    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 :-) -- . %%%
  4. 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. %%%
  5. 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:
    1. 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).
    2. 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:
    1. Dificultades t�cnicas, aunque es pr�cticamente igualde sencillo tratar las contrase�as que los certificados, hay que consultar revocaciones, etc.
    2. 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.
    3. 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. %%%