La Electronic Frontier Foundation (EFF) está trabajando en un interesantísimo proyecto sobre privacidad: Panopticlick. Éste pretende investigar si nuestros navegadores, aun no emitiendo información de IP o a través de cookies, pueden ser fácilmente identificable por terceras aplicaciones web.
La información que proporciona el navegador, como la versión del sistema operativo, los plug-ins que tiene activado, las fuentes o tipos de letra que soporta, proporcionan una huella digital que podría servir para identificar nuestro puesto informático. De hecho, esta técnica se conoce como Device fingerprint y se sabe que es una de las técnicas que utilizan las empresas de publicidad en Internet, a la hora de personalizarnos los anuncios a mostrarnos.
Como vemos, el objetivo de esta investigación es obtener una base de datos anónima de navegadores de cara a saber si es posible o no identificar únicamente nuestro navegador con la información que envía y hasta que punto debería ser corregido este asunto.
Yo he probado con mi navegador Safari 4 y Firefox 3.5 y en ambos me ha informado que con su actual base de datos de más de 420.000 navegadores diferentes, podrían identificarlos unívocamente. Parece que la privacidad en Internet sigue siendo algo por lo que luchar, ¿no?
Últimamente me he visto envuelto en diferentes debates sobre si era seguro o no usar certificados con capacidades SSL, no sólo para asegurar conexiones TCP y/o autenticar servidores, sino también para firmar metadatos o aserciones.
El escenario en el que nos encontramos es el indicado en la figura, en el cual un cliente realiza conexiones HTTPS contra un IdP (Proveedor de Identidad) para acceder a un sistema SSO y por ende a recursos protegidos. Dónde al logarse el cliente con éxito, el IdP genera una aserción sobre quién es el cliente y qué atributos posee, el IdP firma esta aserción con el mismo certificado que se ha usado para establecer la conexión HTTPS.
Escenario
El problema, o mejor dicho, el origen de las inquietudes reside en el uso del mismo certificado para la conexión HTTPS y para la firma de la aserción o de cualquier otro tipo de metadatos, y en el cual confían los SPs (proveedor de servicio) que han establecido relaciones de confianza con el IdP.
Pues bien, estas inquietudes se basan en la creencia incierta de que un servidor web firmará alegremente cualquier cosa presentada por el cliente en el ‘random binary blob‘ durante el SSL-handshake. Si esto fuese cierto un atacante tendría la capacidad de enviar como ‘random binary blob‘ una aserción falsa, que al ser firmada por el certificado x509 en el que confían los SPs, le diese la capacidad de acceder a recursos a los cuales no tiene acceso.
Esto es totalmente falso, ya que bajo ninguna circunstancia un servidor web firmará datos arbitrarios presentados por un cliente. Para aclarar esto voy a explicar que datos presenta el cliente al servidor y que son susceptibles de ser firmados.
Durante el handshake del protocolo TLS/SSL se genera el master secret, el cual es un secreto compartido entre el cliente y el servidor, de 48 bytes y que es usado como clave simétrica para proteger la sesión. Este master secret, se genera mediante la siguiente función:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random);
Donde PRF es la Pseudoroandom Function elegida de la cipher-suite- especificada en fases previas del handshake, la cual es una función basada en HMAC, que no usa en ningún momento la clave privada del certificado.
El pre_master_secret, es una cadena de 48 bytes enviada por el cliente al servidor y que es lo que nos interesa en este caso, ya que representa los únicos datos que el servidor cifra de forma “alegre”.
La cadena “master secret” es una constante con dicho valor.
Y por último las cadenas ClientHello.random y ServerHello.random son dos blob de 28 bytes, el primero enviado por el cliente en la fase ClientHello del handshake y el segundo enviado por el servidor en la fase ServerHello.
Como he dicho anteriormente, nos interesa el pre_master_secret, ya que esta cadena son 48 bytes, de los cuales 46 son generados aleatoriamente por el cliente y 2 indican el protocolo. Estos 48 bytes son cifrados con la clave pública del servidor. Y es este cifrado el punto que ha generado tanta controversia.
Pues bien, al cifrarse estos datos con la clave pública del servidor, es este servidor el único que puede descifrar y por tanto entender estos datos, ya que es el único en posesión de la clave privada correspondiente.
Con esto, si un cliente malintencionado en vez de generar 46 bytes aleatorios, introduce la aserción falsa, lo que obtendría es un mensaje cifrado que sólo puede leer quien posea la clave privada del servidor. La cual no está en posesión de los SPs, ya que estos sólo necesitan la clave pública, para comprobar la firma de las aserciones.
Como conclusión, decir que podemos estar seguros de usar el mismo certificado x509 tanto para asegurar sesiones con TLS/SSL como para firmar aserciones o metadatos ya que según la especificación del protocolo TLS los datos que un servidor cifra “alegremente”, sólo los puede descifrar él.
Por último decir que separar por roles el uso de claves privadas de los certificados x509, es decir, usar una para TLS y otra para firmar aserciones y/o metadatos, es una buena práctica de seguridad. Ya que aunque TLS ha sido diseñado para resistir ataques contra autenticación y firmado, la historia nos ha demostrado muchas veces que confiar en la calidad de un algoritmo o protocolo y en su implementación debería evitarse en la medida de lo posible.
En entradas anteriores comentábamos qué era OAuth mediante un ejemplo ilustrativo sencillo, pero es mucho más que eso. Existen distintas configuraciones, escenarios y extensiones que merecen nuestra atención, por la flexibilidad que nos permiten obtener a la hora de implementar un sistema de autenticación y autorización.
En esta entrada vamos a comentaros los dos escenarios que pueden configurarse con OAuth y que nos hace a los desarrolladores la vida un poco más fácil: 
El primer de ellos es el escenario con Acceso Delegado (3-legged scenario), en el cual hay tres actores: Cliente, Propietario del Recurso y Servidor. El Cliente pide acceso a los recursos en nombre de un propietario de un recurso concreto. En este caso las Credenciales que serán necesarias intercambiar para garantizar un mínimo de seguridad son las propietario del recurso y las del cliente. Este escenario es el que ilustrábamos en nuestro anterior post.
El otro escenario que se propone es el que tiene un Acceso Directo ( 2-legged scenario). Los actores en este escenario son sólo dos: Cliente y Servidor. Esta situación se da cuando el Cliente pide acceso a los recursos en su nombre. En este caso el Cliente y el Propietario del Recurso serán la misma entidad y sólo será necesario enviar las Credenciales del Cliente.
En PRiSE hemos realizado un estudio de las sentencias realizadas por la Agencia Española de Protección de Datos en el año 2009.
El año pasado, la AEPD resolvió 419 procedimientos sancionadores de los cuales más de la mitad abarcaban los artículos 4 y 6 de la LOPD. Estos dos artículos tratan de la Calidad de los Datos y del Consentimiento del Afectado respectivamente.
Con respecto a la Calidad de los Datos, unos de los aspectos más sancionados es el que comprende el artículo 4.3:
Los datos de carácter personal serán exactos y puestos al día de forma que respondan con veracidad a la situación actual del afectado.
En cuanto al Consentimiento del Afectado, el apartado de más interés, en cuanto a sanciones procesadas es el 6.1:
El tratamiento de los datos de carácter personal requerirá el consentimiento inequívoco del afectado, salvo que la ley disponga otra cosa.
Para más información os adjuntamos dos gráficas que pensamos pueden ser bastante ilustrativas acerca de los artículos de las normas nacionales que han suscitado mas procedimientos sancionadores.
En posteriores entradas comentaremos los artículos con más procedimientos sancionadores y las resoluciones tomadas por la Agencia Española de Protección de Datos.
¡Estad atentos al blog!
OAuth (Open Authorization; Autorización abierta) es un estándar abierto que permite incluir seguridad en la autenticación para aplicaciones web y de escritorio.
Su origen se remonta a la necesidad de querer establecer un protocolo estándar que sacara factor común de las buenas prácticas existentes en los distintos sistemas de autenticación existentes, como por ejemplo Google AuthSub , AOL OpenAuth , Flickr API y Amazon Web Services API entre otras.
Para ilustrar las ventajas de OAuth, veamos el siguiente ejemplo: Una aplicación nueva incluye un servicio de avisos de fechas importantes que deberá importar de otra aplicación, por ejemplo, la agenda del gestor de correo. Para poder activar el servicio es necesario que el sujeto en cuestión le de su nombre de usuario y contraseña para así acceder al gestor de correo. El resultado obtenido es que ambas aplicaciones funcionan correctamente, pero existe un inconveniente primordial: la aplicación que da el servicio de avisos ya tiene su contraseña, lo cual puede llevar a un problema de seguridad grave.
OAuth intenta solucionar esta problemática restringiendo el acceso a los recursos. En el ejemplo anterior, mediante OAuth se habría conseguido que la aplicación servidora sólo pudiera acceder a la información del calendario, evitando así tener que darle el nombre de usuario y contraseña y que hubiera un acceso ilimitado a la información contenida en el gestor de correo.
En vez de utilizar nombre de usuario y contraseña, OAuth utilizará unas credenciales que permitirán el acceso a uno o varios recursos por un periodo de tiempo determinado.
Inteco organiza junto a la Dirección General de la Sociedad de la Información y Medios de Comunicación de la Unión Europea la Conferencia sobre Confianza en la Sociedad de la Información (Trust in the Information Society), que tendrá lugar en León el 10 y 11 de febrero.
Este evento incluye las siguientes temáticas:
- Servicios en red y entornos informáticos de confianza
- Un marco europeo común para gestión de identidades
- Desarrollo de tecnologías y marco legal de la Unión Europea para protección de datos y privacidad
- Cooperación internacional sobre confianza y la investigación sobre seguridad
Más información: http://trustworthyict.inteco.es
El próximo jueves 28 de enero se celebra un año más el día europeo de la Protección de Datos, promovido por el Consejo de Europa, la Comisión Europea y todas las autoridades de protección de datos de los países miembros de la Unión Europea.
La celebración del Día de Protección de Datos en Europa tiene como objetivo principal impulsar el conocimiento entre los ciudadanos europeos de cuáles son sus derechos y responsabilidades en materia de protección de datos, de forma que puedan familiarizarse con un derecho fundamental, que pese a ser menos conocido, está presente en todas las faceta de sus vidas diarias.
En España, las agencias catalana, vasca y la española celebrarán la jornada con la realización de diversos actos.
Más información:
- http://www.coe.int/t/e/legal_affairs/legal_co-operation/data_protection/Default_DP_Day_en.asp#TopOfPage
- http://www.agpd.es/portalweb/dia_proteccion-datos_2010-ides-idphp.php
- http://www.apdcat.net/ca/curs_jornada_activitat.php?cat_id=170&curs_id=100
El Data Privacy Institute celebra el próximo 21 de enero en Madrid su primer foro bajo el título “Recetas para la Privacidad de Datos”, ya que este primer encuentro se centrará en el sector sanitario.
Más información: https://www.ismsforum.es/noticias/noticia.php?noticia=240
Si te encuentras en el mundo sanitario, te gustará saber que PRiSE tiene experiencia con clientes en el sector sanitario privado en referencia a la protección de datos.
Próximamente publicaremos una nueva sección en nuestra página web donde daremos a conocer nuestros casos de éxito en este ámbito.
Al desarrollar aplicaciones con OAuth nos surge la duda de cuál librería de las que existen nos conviene más utilizar.
En el caso de que queráis programar en PHP hay varias opciones. A continuación comentamos cada una de ellas,
teniendo en cuenta los principales aspectos que interesan en OAuth como pueden ser qué versión soporta, si es genérica o es la extensión de un framework concreto o si contiene funciones para implementar un proveedor de servicio.
- Autor: John Jawed
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Andy Smith
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Cal Henderson
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: Escasa
- Autores: Jeff Hodsdon y Bill Shupp
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Daniel Hofstetter
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: No, es para CakePHP
- ¿Hay Documentación?: Escasa
- Autor: Justin Richer
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0
- ¿Genérica?: No, es para Elgg
- ¿Hay Documentación?: Escasa
- Autor: Pádraic Brady
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: No, es para Zend
- ¿Hay Documentación?: SI
Acabamos de finalizar el lanzamiento del repositorio Maven para los proyectos en Java que quieran trabajar con la tecnología de PAPI. Maven es una herramienta de software para la gestión de proyectos desarrollados en Java. Una de sus principales características es la posibilidad de definir dependencias de otras librerías Java externas, siendo capaz de instalarlas y utilizarlas en nuestros proyectos.
Para utilizar el repositorio Maven de PAPI, utilizaremos la siguiente configuración:
<repository>
<id>papimaven</id>
<name>papi maven repository</name>
<url>https://forja.rediris.es/svn/papi-ee/trunk/maven/</url>
</repository>
Como está bajo el protocolo https, tendréis que tener importado el certificado digital de su servidor web. Podéis hacerlo de la siguiente manera:
echo |openssl s_client -connect forja.rediris.es:443 2>&1 |sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ | keytool -import -trustcacerts -alias forja -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit -noprompt
Por ahora hay 4 módulos disponibles:
- papi-crypt: librería criptográfica para trabajar con los mensajes y las cookies de PAPI.
- papi-core: librería base para trabajar con la tecnología de PAPI.
- papi-filter: filtro J2EE que hace las funciones de PoA en Java.
- papi-jicgpoa: icGPoA desarrollado en Java.
- shib-filter: filtro J2EE que conecta un proveedor de identidad de Shibboleth con una infraestructura basada en PAPI.
Nosotros ahora mismo lo estamos utilizando para nuevos desarrollos basados en PAPI que ya os iremos contando en otras entradas del blog…