Encriptacion

pues creo que el problema es ese, que no se tiene ni puta idea de como esta encriptada la ps3, weno yo no me entiendo de esto y no puedo opinar, espero que en el foro alguien se entere pero sinceramente lo dudo mucho, esto es muy complicado creo..

Tienes un interesante artículo resumen basado en las especificaciones de IBM sobre la arquitectura del Cell que te recomiendo leer, para conocer a grandes rasgos en qué se basa Sony para implementar su modelo de seguridad en la PS3.

http://playstation-disorder.com/comments.php?blog_id=187

P.D. Está en inglés.

Pues muchas gracias

La verdad es que me ha parecido muy interesante
aunque la verdad yo me referia mas a la encriptacion y codificacion de datos en el disco duro

but thanks, anyway

Muy buen enlace
Moulsin, lo que deberia interesarte, es la de los procesadores

devnul escribió:Muy buen enlace
Moulsin, lo que deberia interesarte, es la de los procesadores

No, porque me interesa digamos de un modo mas teorico..

El procesador me interesaria para lograr avances en la scene, cosa que ni me interesa ni conozco suficiente...

Te puse el enlace sobre el hardware porque es la única información que he conseguido localizar sobre el tema de la encriptación. De hecho todavía no tengo claro cuando comentan que el cell tiene 8 núcleos SPE, de los cuales sólo se utilizan 7, y en el caso de Linux, 6.

En linux uno de los SPE se usa como el hypervisor que controla absolutamente todas las llamadas al hw. Me queda la duda de si la PS3 también usa el 8 SPE (el teóricamente desactivado) como controlador exclusivo de la seguridad del sistema.

Si avanzas algo o consigues localizar más info sobre la encriptación usada postea aquí o mándame un privado que yo también estoy interesado en el tema.

Saludos

Oh, Dios, otro. No sabeis usar el buscador?

Si he puesto el enlace anterior es porque lo he encontrado usando el buscador. En cuanto a la info que he encontrado sólo hace referencia a los whitepapers de IBM sobre el cell, programación de las SPE, etc.

No he encontrado nada sobre el tipo de encriptación usado por los binarios. Ilumíname Mangafan.

Gracias.

No es por decepcionar pero... veo realmente jodido el tema.

Para explicarlo "facil" para los que no entienden de programacion, seria algo como matrix

Todo rula dentro de matrix y cualquier cosa creada ahi, solo funciona ahi sin poder salir fuera. La unica forma de salir fuera, es estar fuera.

El Arquitecto de Matrix (hypervisor + cell para ps3) es infranqueable desde fuera.

(bien no he dicho nada nuevo xD)

Una de las cosas mas interesantes a probar en los CELLS es la capacidad de recuperacion en caso de que uno de sus procesadores muera, activandose asi el "de respuesto". Pero que pasaria si fallasen no uno, sino todos excepto el de respuesto?

Paso uno "eliminar" los cells

Paso 2 trabajar con solo un procesador

Paso 3 ver si un unico procesador es capaz de mantener los cifrados a la hora de leer los BR

Paso 4 Suicidarse, porque la respuesta es si.

La unica manera de "acceder a la habitacion del Arquitecto" es haciendole otra habitacion y que entre ahi, y eso, no es moco de pavo.

En resumidas cuentas, que nos vayamos olvidando del tema.

devnul escribió:No es por decepcionar pero... veo realmente jodido el tema.

Para explicarlo "facil" para los que no entienden de programacion, seria algo como matrix

Todo rula dentro de matrix y cualquier cosa creada ahi, solo funciona ahi sin poder salir fuera. La unica forma de salir fuera, es estar fuera.

El Arquitecto de Matrix (hypervisor + cell para ps3) es infranqueable desde fuera.

(bien no he dicho nada nuevo xD)

Una de las cosas mas interesantes a probar en los CELLS es la capacidad de recuperacion en caso de que uno de sus procesadores muera, activandose asi el "de respuesto". Pero que pasaria si fallasen no uno, sino todos excepto el de respuesto?

Paso uno "eliminar" los cells

Paso 2 trabajar con solo un procesador

Paso 3 ver si un unico procesador es capaz de mantener los cifrados a la hora de leer los BR

Paso 4 Suicidarse, porque la respuesta es si.

La unica manera de "acceder a la habitacion del Arquitecto" es haciendole otra habitacion y que entre ahi, y eso, no es moco de pavo.

En resumidas cuentas, que nos vayamos olvidando del tema.

jajaja estoy como cuando vi matrix por primera vez, que me he tenido k leer el post unas cuantas veces pa enterarme!!!xD

Esque se me ha olvidado poner la pastilla junto con el post jejejej

Explicado de otro modo:


A hotel analogy clarifies this security model; the hotel manager (PPE) allocates a room (SPE) for a guest (application). � The guest can lock the room from the inside; the hotel manager, and other guests, cannot peek into the room. � However, the hotel manager can kick the guest out.

Respecto a la encriptacion directamente

Furthermore, the activation of the hardware decryption using this root key is tightly integrated with the SPE isolation mode.  When an SPE enters isolation mode, the hardware decryption facility is kick-started to fetch the encrypted data into the isolated SPE and decrypt the data using the hardware root key. The decrypted data is placed within the protected Local Store and is available for an isolated SPE application to use.  In fact, the decryption based on the root key can only happen within an isolated SPE and not outside of it;  no access to the root key is available, by hardware or software means, from a non-isolated SPE or the PPE.  First, this implies that a system designer can force all data decryptions by the root key to happen within the protected environment of the Secure Processing Vault;  the keys unsealed by the root key will always be placed (at least initially) in the Vault only.  Second, only applications that have successfully passed the Runtime Secure Boot authentication are given access to the keys unsealed by the root key.  Any software that might have been adversely modified will not be given access to the unsealed keys.  Because the foundation of this control is grounded in both the Runtime Secure Boot and Hardware Root of Secrecy features, the process is more resistant to manipulation than with a pure software-controlled access mechanism.

Another advantage of this feature answers the question, what prevents an adversary from taking an application intended to run within the Vault and executing it outside of the Vault?  The answer is to encrypt a portion of the application code using the hardware root key. Because the code is encrypted, it cannot be captured and directly executed on a regular, non-isolated SPE. The code needs to be decrypted, and therefore has to execute within the Vault where it can be decrypted by the root key.  This reassures the application writer that a particular application will only execute within a Secure Processing Vault.