On Saturday 24 July 2010 11:02:15 Marcos Germán Guglielmetti wrote:
para tener en cuenta:
Re: [Gleducar] Contacto con Coordinador Regional de proyecto laptops INET De: Marco Antonio <[email protected]> Para: [email protected] Fecha: 24/06/10 12:52 El día 24 de junio de 2010 11:56, Federico Heinz
<[email protected]> escribió:
On 24/06/2010, Marco Antonio wrote:
estimado federico .. me podrias decir, porque a tu opinion, el "supuesto sistema antirrobo" no deberia estar alli ?
Porque se presta al abuso por parte de la autoridad central, por ejemplo imponiendo el uso de tal o cual software, como en este caso.
ok.. entiendo tu postura.. pero.. si tuvieses una aplicacion cliente, que sea multiplataforma, opinarias igual ?
y porque los padres no deberian dejar que acepten los equipos a los alumnos ?
Porque parte de la educación que los padres, en mi opinión, deben darle a sus niños es que no deben aceptar que las autoridades centrales ejerzan poder indebido sobre ellos, ni siquiera a cambio de un soborno.
muy buen punto y comparto. pero si los padres no saben nada sobre el tema, y los hijos pueden tener un primer contacto con las nuevas tecnologias, no seria mejor, que los profesores les enseñen esto primero a los alumnos y estos ultimos a los padres ? se que con el tiempo, cuando los alumnos sean padres sabran que no deberian aceptar esto como una "imposicion" por parte de las autoridades. si no les explican cuales son sus libertades, la gente no nace sabiendo.. todos aprendemos a medida que pasa el tiempo.. :)
vos hablas de crackear un componente de hardware ? un soft te creo, pero un hardware ? no digo que no sea imposible, pero hasta lo que haga, creo que va pasar mucho tiempo !!!
Hay varias posibilidades de ataque. La más efectiva, por cierto, sería obtener la clave privada del chip, pero no creo que contemos por estos pagos con el equipamiento y en know-how necesario. Pero no necesariamente hace falta atacar el hardware: es bastante probable que el software que hace la autenticación contra el servidor y/o los drivers tengan errores que uno pueda explotar para recuperar control de la máquina. No soy especialista en esas cosas, pero si se puede hacer para las consolas de juego, estimo que se debe poder hacer también para estas máquinas, a menos que Intel haya encontrado un depósito de programadores infalibles en algún lado.
se que pueden haber varios tipos de ataques y no soy ageno a ello, pero.. como bien dices, por estos lados, aun (y solo aun) no contamos con ese equipamiento para obtener de alguna manera el certificado raiz (o de apareamiento entre exomate-servidor) por lo que hay un tiempo para seguir avanzando en mejorar el sistema de seguridad. no es lo que me toca hacer, pero no quita que otros lo puedan hacer. el software "cliente" solo descarga del servidor, un certificado de tiempo, que en la exomate, queda la llave publica del servidor, para que no sea "otro server" el que le entrega esa llave. es por ello, que una exomate asociada a un server, "queda pegada" solo a esa (por el momento). con respecto a las consolas de juego, paso un buen tiempo para poder "chipearlas" y poder pasar por arriba la seguridad, pero como en el caso de las exomate, no estan exentas de ello (y lo tengo claro) pero va a pasar bastante tiempo, hasta que logren (en el supuesto caso de que se pueda) re-chipearlas contra otro server (o hacerlas "inbloqueables") :P
y a tu opinion, cual seria el metodo de poder tener un sistema "anti robo" o de "bloqueo por sustraccion" ? te pregunto, porque es lo que solicito el ME y el estado, que deben tener los equipos para ser entregados a los alumnos. recorda que en la sociedad en argentina (a diferencia de otros paises) lo que se puede robar, pasa al mercado negro...
La sociedad argentina no es distinta de la de otros países en ese sentido. Y sé que eso es lo que el estado pidió. Lo que estoy diciendo es que no debió haberlo pedido. O en su defecto, como propuse para el famoso documento del que Vía Libre se bajó, que la medida antirrobo sea tal que no impida al usuario legítimo del equipo modificar el software, eventualmente desactivando el mecanismo, bajo su propia responsabilidad.
el usuario legitimo (a.k.a ministerio de educacion) es quien es el propietario de los equipos. este, decide (de la mano de los RT) si los equipos son asegurados o no contra un servidor. los equipos pueden o no ser asegurados contra un servidor, eso dependera de la responsabilidad que les compete a cada uno. el mecanismo NO es activado por defecto, sino "bajo responsabilidad" del RT.. por ende, se cumple el 50% de lo que decis.
intel tiene un cliente bajo linux.. pero.. por tema de "convenios" firmados, no liberan el codigo..
Excusa barata. No deberían haber firmado ese convenio. No quieren liberar el código, y por eso les viene bárbaro "firmar convenios" (que ni siquiera sabemos si existen, por cierto, porque nunca te los muestran ni te explican por qué era *imprescindible* que los firmaran.
comparto. el problema, es como se lo explicas a quienes "firman" ese convenio de confidencialidad, siendo una de las partes, muy "astuta" con temas legales.. :)
salu2
Re: [Gleducar] Contacto con Coordinador Regional de proyecto laptops INET De: Marco Antonio <[email protected]> Para: Lista general de Educación y Conocimiento Libre <[email protected]> Fecha: 24/06/10 15:54 El día 24 de junio de 2010 15:12, Federico Heinz <[email protected]> escribió:
On 24/06/2010, Marco Antonio wrote:
ademas, si en el caso de que fueran "asegurados" o asociados a un servidor, y es solicitado un "desbloqueo de por vida" tambien es posible (con un certificado permanente o "sin limite").
Deshabilitar el TPM por BIOS no se puede? O, en vez de darle un certificado sin límite, simplemente decirle que no pida uno?
Fede
si fuese desactivado por el BIOS, estamos en la misma, no seria seguro :D el TPM es independiente al BIOS. para que entiendas o comprendas como funciona: proceso de encendido: boton encendido > TPM > BIOS > su ruta. si el ticket de validez del TPM esta vencido o bloqueado, no pasa al BIOS y por ende no enciende. para poder pasar, hay que colocar un codigo numerico de 10 digitos, que se genera desde el servidor que esta asociado el equipo. este valor de desbloqueo se genera con: una marca de arranque (boot tick) que aparece en la pantalla del equipo + hardware ID de la exomate + fecha que fue generado el ultimo certificado + certificado raiz = numero unico para desbloqueo. si en el TPM no tiene certificado alguno (ni del server, ni de bloqueo, ni nada.. "totalmente en blanco") el equipo no se bloqueara nunca. si el TPM tiene el certificado del server solamente, ya tiene uno "Minimo" de 99 arranques.. por ende, cuando le queden menos de 10, se tratara de comunicar con el server, si no lo hace, se bloquea. si el TPM tiene el certificado del server, y ya descargo un certificado general (ej: 30 dias o 600 arranques) lo que suceda primero, se bloquea. si el TPM tiene el certificado del server, y se le entrega un certificado "sin vencimiento" el equipo no se bloqueara jamas. si el TPM tiene el certificado del server y por alguna causa, se interrumple la descarga de un nuevo certificado, prima el certificado anterior. si por primera vez al descargar el certificado TPM del server y este no es aceptado, el equipo no queda asegurado, pero si asociado al servidor por lo que no sera posible re-asociarlo a otro servidor. espero haber sido claro.. salu2 -- Marco Antonio de Hoyos twitter: @mhoyos (011)15-5157-2322 // (011)4268-1557 ----------------------------------------------------------------- “Cuando existe la voluntad, existen mil recursos. Cuando no existe la voluntad, existen mil excusas”. _______________________________________________ Gleducar - http://www.gleducar.org.ar Para enviar mensajes: [email protected] Desuscripción: escribir un correo a [email protected] Información de la lista: http://gleducar.org.ar/cgi-bin/mailman/listinfo/gleducar Para ver los mensajes anteriores: http://news.gmane.org/gmane.linux.edu.gleducar