[Solar-general] "el mecanismo NO es activado por defecto, sino "bajo responsabilidad" del RT"

Lun Jul 26 15:50:08 CEST 2010

El 24/07/10, Marcos Germán Guglielmetti <marcos en ovejafm.com> escribió:
> 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 <mhoyos en gmail.com>
>>   Para:
>> gleducar en gleducar.org.ar
>>   Fecha:
>> 24/06/10 12:52
>>
>> El día 24 de junio de 2010 11:56, Federico Heinz
>>
>> <fheinz en vialibre.org.ar> 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 <mhoyos en gmail.com>
>   Para:
> Lista general de Educación y Conocimiento Libre <gleducar en gleducar.org.ar>
>   Fecha:
> 24/06/10 15:54
>
> El día 24 de junio de 2010 15:12, Federico Heinz
> <fheinz en vialibre.org.ar> 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..
>

Pregunta desde la ignorancia: ¿cómo funciona dicho chip? En caso de
fallar la BIOS (por ejemplo se pierde la configuración por defecto),
¿el equipo queda inutilizado para siempre?
Para mí es muchísimo control (me gusta el término mass-surveillance)
"al pedo"; quiero decir, uno desarme el equipo, reinicia el BIOS,
remueve el chip, instala el gnu+linux y ya tiene un bonito -y útil-
ordenador para usar :)

-- 
Facundo Andrés Bianco (Vando.)
GNUPG ID: 0x89C1B42F
omb: identi.ca/vando