Algunas lecciones de seguridad a propósito del caso Sony
Autor: Antonio Manuel Amaya
Este está siendo un año particularmente… interesante para Sony. Interesante en el sentido de la maldición china. Primero se hizo público que quien quiera que implementase la función de firma electrónica de los archivos que la PS3 podía ejecutar, evidentemente no se había molestado en leerse las molestas notas al pie del algoritmo que usaron, con el resultado de que la clave de firma se hizo pública. Después, decidieron solucionar el problema técnico denunciando al hacker que había publicado la susodicha clave.
Pero la denuncia tal vez sirva para que el próximo hacker no haga público escarnio de la compañía y en su lugar distribuya la clave de forma más discreta, pero no sirve para evitar que se use. Es difícil hacer desaparecer la información de la red una vez se ha publicado, particularmente si los propios directivos ficticios de la compañía se dedican a re-twittearla:
Así, de forma independiente al trasiego judicial empezaron a aparecer firmwares cocinados para la PS3. ¿Qué es un firmware cocinado, además de uno que se graba en un DVD y se mete en el microondas, con efectos perjudiciales para el DVD, el microondas y el mobiliario cercano? Pues es una versión del firmware de un aparato, en este caso la PS3, que ha sido retocado por alguien distinto del fabricante del aparato para alterar alguna función del mismo. Por ejemplo, para que el firmware ejecute alegremente cualquier cosa que el usuario le pida, sin verificar que el ejecutable está aprobado por el fabricante del aparato.
Evidentemente, un firmware que permite la ejecución de cualquier aplicación, además de permitir la ejecución de código homebrew (aplicaciones desarrolladas por aficionados, no aprobadas por el fabricante de la consola) permite la ejecución de copias de respaldo de juegos legítimos. O copias piratas, para entendernos. Lo cual no es bueno para los desarrolladores de juegos, y no es bueno para Sony. Y ese es el principal motivo por el que a Sony no le gusta que su consola ejecute cualquier aplicación, de forma lógica por otra parte.
El modelo de negocio de Sony con la PS3 (en versión Supercoco, y sin entrar en el papel de la PS3 en la guerra Blueray-HDDVD) podemos decir que tiene tres patas:
- Por una parte está la venta de la consola en si… si es que ya han conseguido fabricarla con un coste por debajo del precio de venta.
- Por otra parte está la venta de juegos de terceros. Para ejecutar los juegos en la consola, Sony tiene que firmar el ejecutable, y de esta forma Sony se asegura cobrar una parte de cada copia de cada juego que se vende para la PS3.
- Y la tercera pata es la red: PSN (Playstation Network). PSN es por una parte una tienda online donde los propietarios de PS3 pueden comprar juegos y servicios (juegos para descargar directamente a la consola, y servicios digitales), y por otra parte es un servicio que se ofrece a desarrolladores y usuarios de juegos multijugador. Digamos que ofrece un punto de registro y punto de encuentro para los jugadores, de forma que, para un juego concreto, puedan encontrar de forma sencilla a otros jugadores del mismo juego e iniciar partidas en red.
La primera pata del modelo de negocio es, o directamenente ruinosa, o en el mejor de los casos no muy rentable. Con el hardware o pierden dinero o ganan muy poco, y además se cobra solo una vez. La segunda pata está tocada por la publicación de la clave de firma, como comentaba antes.
¿Y la tercera pata? Pues para acabar un año redondo (y solo estamos en abril), hace una semana PSN (Playstation Network) sufrió un ataque y, de forma preventiva, Sony decidió cortar el ataque por lo sano, cortando el servicio mientras evaluaban el alcance del ataque y le ponían un tapón al agujero usado por los hackers. Para entender la importancia de cerrar el servicio, recordemos que cerrar PSN es igual a no poder comprar juegos online (y posiblemente no poder acceder a aquellos que ya hubieses comprado) y es igual a no poder jugar en red.
Y eso no tiene muy contentos a los usuarios, claro:
| The store, your friends list, these aren’t perks. By 2011, they’re bedrock assertions of the medium. The deal they made with users – one which, for years, was the justification for a gruesome price disparity – was “free Xbox Live,” not “shit happens.” |
Ahora, una semana después de cortar el servicio, Sony ha ‘descubierto’ que durante el ataque se ha producido una fuga de datos de sus usuarios. De todos los datos, de todos sus usuarios. Datos que, puesto que PSN además de un punto de contacto es también una tienda, incluyen números de tarjetas de crédito.
Ni Sony ni los atacantes han dado detalles de cómo se ha producido el ataque, pero los rumores apuntan a que en la base del ataque hay un fallo en la cadena de confianza en la arquitectura de seguridad de Sony. ¿Que es la cadena de confianza de la arquitectura de seguridad? Pues es un término que, hasta donde sé, me acabo de inventar, y cuya explicación da para otro artículo.
En este, más que el medio, me parece más interesante destacar que lecciones se puede aprender de esta fuga de datos masiva, porque creo que ninguno queremos el papel de Sony en esta historia. Lecciones que, para cualquier servicio que trate con datos personales, o económicos, podríamos resumir en algunas nociones que no por obvias dejan de ser válidas:
- El modelo de uso de datos no es opcional. Es imprescindible definir, al mismo tiempo que definimos el servicio, un modelo de uso de datos. Es decir, al mismo tiempo que definimos la función que un componente va a realizar definimos que datos necesita ese componente. Los datos imprescindibles que necesita.
- Los datos que se usan en sitios distintos, se almacenan en sitios distintos. El modelo de uso de datos nos debe servir para particionar los datos. Si por motivos de arquitectura, o porque en realidad es más práctico queremos tener todos los datos juntos en una tabla, para que no se nos constipen, entonces es necesario que el acceso a la tabla esté particionado. De forma que, por ejemplo, si para una parte del servicio sólo nos hace falta el nombre del usuario, entonces desde esa parte sólo se pueda extraer el nombre del usuario.
- El que almacena los datos impone las normas. Es decir, no vale con que sepamos que el módulo A, que por diseño solo necesita el nombre, por implementación solo va a pedir el nombre y ya hemos cumplido. Debemos dar por hecho que todos los componentes del servicio (y particularmente los expuestos hacia el exterior) pueden y van a ser comprometidos. Y que nuestro módulo A, totalmente confiable y al que tenemos un gran cariño va a ser suplantado por un módulo A’ al que no conocen ni en su casa a la hora de comer.
- El sentido importa. No todos los módulos que pueden escribir un dato tienen derecho a leerlo. Y hay datos que pueden (y deben) ser de ’solo escritura’ por lo que respecta a los componentes del servicio. Un ejemplo fácil de este tipo de datos son los datos bancarios. Los clientes del servicio introducirán sus datos bancarios a través de un componente que tendrá permiso de escritura de ese dato. Pero ese componente no tiene que tener permiso de lectura de los datos bancarios. Los clientes ya saben su número de tarjeta o de cuenta corriente, no tenemos que recordárselo.
- La contraseña no se le dice a nadie. Ningún módulo con el que los clientes interactúen necesita acceso de lectura a la contraseña. ¿Cómo hacemos entonces la validación de contraseñas? Implementando un módulo interno de autenticación que recibe una contraseña en claro, o un hash, y devuelve sí (es válida) o no (es válida).
- Usa la criptografía con juicio. Hay algoritmos bastante eficientes y seguros de cifrado de datos. Aquellos datos que son particularmente sensibles y que, además, no van a ser objeto de búsquedas (ejemplo sencillo, de nuevo los datos bancarios) pueden ser almacenados cifrados, de forma que aunque alguien se lleve un volcado en bruto de la base de datos no le valgan de nada.
Con estos puntos sigue siendo probable que alguien pueda robar algunos datos de algunos usuarios. O incluso algunos datos de todos los usuarios. ¿Pero robar todos los datos de todos los usuarios, como ha pasado en el caso de Sony? Eso exigiría el compromiso del módulo de almacenamiento y el módulo de cifrado, y en nuestro diseño estos módulos no están accesibles desde el exterior… ¿verdad?



(Votos: 8. Media: 4,38/5) 


(Votos: 1. Media: 4,00/5) 
















