Archivado en la categoría (Identidad Digital, OpenID) por candido.rodriguez
Publicado el 22-03-2010

Parece que OpenID está ganando poco a poco la confianza de las administraciones públicas en otros países a la hora de utilizarlo para autenticar a sus ciudadanos.

Como la mayoría sabréis, el pasado Septiembre’09 el gobierno americano anunció que comenzaría a incluir dicha tecnología en alguna de sus agencias gubernamentales y es ahora el gobierno japonés quien anuncia que va a permitir la autenticación de los usuarios en un portal del Ministerio de Economía, Comercio e Industria.

El portal, que se llama IdeaBox, es una iniciativa para conocer la opinión del ciudadano japonés con respecto a las iniciativas de dicho ministerio y que además, pueden proponer y votar, nuevas ideas. Aunque por ahora sólo van a confiar en 4 proveedores de identidad de OpenID:

  • Yahoo! Japan
  • Google
  • Mixi
  • LiveDoor

Enhorabuena al gobierno japonés por dicha iniciativa y estamos seguro que no tardaremos en ver en otros portales gubernamentales de otros países tecnologías como OpenID u OAuth.

(0) Comments    Read More   
Archivado en la categoría (Identidad Digital, OAuth, OpenID, PAPI, Seguridad) por daniel.garcia
Publicado el 30-01-2010

Ú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

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.

(0) Comments    Read More   
Archivado en la categoría (Identidad Digital, OpenID) por candido.rodriguez
Publicado el 21-11-2009

Aanchal Gupta de YahooLos pasados días 3 al 5 de Noviembre de 2009 se celebró la novena edición de Internet Identity Workshop. Aunque la agenda estaba llena de temas muy interesantes, con numerosas sesiones que había en relación a OpenID, destaca la que se llamaba OpenID v.Next, que coordinaba Dick Hardt y David Recordon, donde se terminó de perfilar los principales aspectos de la próxima especificación de OpenID 3.

La principal característica de OpenID 3 es que no será compatible 100% con la actual especificación de OpenID 2. No habrá que asustarse, la base será la misma pero al igual que hay problemas de interoperabilidad entre OpenID 1 (¿todavía lo usa alguien?) y OpenID 2, habrá algunos ajustes en el protocolo con la nueva versión. Además de esta evolución, han publicado una lista con las novedades en las que se trabajará y cuántos votos obtuvo en la sesión:

  • Integrar la extensión UX (User eXperience), 12 votos. Parece que el punto más importante para OpenID 3 será la usabilidad, como podemos ver en este prototipo.
  • Evolucionar la etapa de descubrimiento (o discovering), 10 votos, para que llegue a admitir nuevos formatos para el identificador de OpenID, como el correo electrónico.
  • La extensión de atributos pasa a integrarse dentro de la especificación base, 9 votos.
  • La extensión OAuth hybrid pasa a integrarse dentro de la especificación base, 8 votos.
  • Integración de clientes externos a la hora de elegir proveedor de OpenID y también integración con clientes que no son aplicaciones web, 8 votos.
  • Mejorar la seguridad, incluso mayor soporte para LoAs (Level of Assurance), 8 votos.
  • Mejorar la integración con móviles, 8 votos.
  • Resolver la problemática de URLs muy largos, 6 votos, ya que hay algunos navegadores que las limitan a 256 caracteres.

La foto es propiedad de Silverisdead tomada mientras asistía a la sesión.

(0) Comments    Read More