OLPC Bitfrost/lang-es

  Esta página está supervisada por el equipo de OLPC.

Traducción de OLPC Bitfrost	original
english | español | 日本語   +/-	cambios

This is an on-going translation

Seguridad de la laptop XO de la OLPC

Plataforma de seguridad Bitfrost

System security on the One Laptop per Child's XO laptop

The Bitfrost security platform

Introducción

Prefacio

En 1971, los programadores Ken Thompson y Dennis Ritchie de AT&T produjeron la primera versión de UNIX. El sistema operativo, que comenzó en 1969 como un proyecto no-pago llamado UNICS, fue renombrado y financiado por Bell Labs cuando los programadores ofrecieron agregarle soporte para el procesamiento de texto. Muchas de esas ideas centrales detrás de Unix aún persisten hoy en día: los populares sistemas operativos para servidores como Linux, FreeBSD, y muchos otros comparten mucho del diseño básico de UNIX.

La versión de UNIX de 1971 soportaba los siguientes permisos de seguridad en los archivos de usuarios:

• no-dueño puede cambiar el archivo (escritura)
• no-dueño puede leer el archivo
• dueño puede cambiar el archivo (escritura)
• dueño puede leer el archivo
• el archivo puede ser ejecutado
• el archivo es set-uid

In 1971, 35 years ago, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.

The 1971 version of UNIX supported the following security permissions on user files:

• non-owner can change file (write)
• non-owner can read file
• owner can change file (write)
• owner can read file
• file can be executed
• file is set-uid

Estos permisos deben parecerles familiares, ya que son muy similares a los permisos de seguridad que un usuario puede darle a sus archivos hoy en día, en su sistema operativo de elección. Lo que es preocupante—casi increíble—acerca de estos permisos es que han permanecido virtualmente como el único mecanismo de control real que un usuario tiene sobre sus documentos personales actualmente: un usuario puede elegir proteger sus archivos de otras personas en el sistema, pero no tiene ningún control sobre lo que sus programas pueden hacer sobre sus archivos.

En 1971, esto podía ser aceptable: fue 20 años antes del arribo de la Web, y los riesgos para la mayoria de los usuarios era totalmente diferente al que se aplica hoy en día. Pero entonces, como es que nos sorprendemos al no poder detener los virus y malware, cuando nuestras defensas han permanecido básicamente las mismas desde hace 35 años?

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling -- almost unbelievable -- about these permissions is that they've remained virtually the _only_ real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

El corazón del problema radica en el supuesto que cualquier programa ejecutándose en el sistema a cuenta de un usuario debería tener las mismas habilidades y permisos que cualquier otro programa ejecutándose en el sistema a cuenta del mismo usuario. 1971 fue siete años antes que la primera red internacional (basada en packet-switch) existiese. Y la primera red de área amplia (wan - wide area network) usando TCP/IP, el estándar de la actual Internet, no fue creada sino hasta 1983, doce años después que Thompson y Ritchie diseñaran los permisos de archivos que ahora discutimos. En resumidas cuentas, en 1971 casi no existía la posibilidad que un programa "existiera" en una computadora excepto si el dueño de la cuenta—el usuario—lo transportaba físicamente a una máquina (por ejemplo, en cinta perforada), o lo ingresase manualmente. Y por ende, la aproximación a la seguridad del "todo o nada", donde los programas ejecutándose tienen el control total sobre la cuenta de su dueño, tenían sentido: cualquier código que el usuario ejecutáse, gozaba de su confianza ipso-facto en términos prácticos.

The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner -- the user -- physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.

Avancemos en el tiempo a la actualidad, y la situación no podría ser más diferente: el contraste máximo es quizás la Web, donde el navegador (browser) ejecuta código foráneo en prácticamente todas la páginas visitadas! Los navegadores utilizan mecanismos de areneros (sandbox) cada vez más complejos con la intención de restringir las capacidades para dicho código foráneo (scripts), pero aún los navegadores más modernos están corrigiendo errores en ellos. Y no nos olvidemos del e-mail: cualquiera puede enviarle a un usuario un programa ejecutable, y por muchos años, la reacción casi instintiva era abrirlo y ejecutarlo. El código foráneo no digno de confianza a priori se encuentra por todos lados, y la única defensa pareciera ser un tedioso entrenamiento del usuario y el software anti-virus—suponiendo que este último esté actualizado, y que sus fabricantes hayan tenido el tiempo suficiente para desconstruir cada virus nuevo y construir su correspondiente defensa.

Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and antivirus software -- the latter assuming it's fully updated, and assuming the antivirus makers have had time to deconstruct each latest virus and construct a defense for it.

La mayoría de las ideas y tecnologías que conforman la plataforma Bitfrost no son el resultado de nuevas investigaciones: han sido conocidas en la literatura pertinente durante años, algunas han sido probadas en situaciones reales, y otras en laboratorios. Lo que se destaca en la XO de la OLPC, es que representa la primera vez que estas medidas de seguridad han sido cuidadosamente ensambladas en un sistema a ser distribuido a decenas o centenas de millones de usuarios. Las laptops son probablemente la primvera vez que un producto de computación masiva ha decidido romper con su legado con tal de mejorar la seguridad. Por ejemplo, notarán que la discusión sobre anti-virus y anti-spyware no figura en la especificación de Bitfrost, principalmente porque la plataforma de seguridad torna dicho tema en algo irrelevante.

Most technologies and approaches mentioned in the rest of this document do not represent original research: they have been known in the security literature for years, some of them have been deployed in the field, and others are being tested in the lab. What makes the OLPC XO laptops radically different is that they represent the first time that all these security measures have been carefully put together on a system slated to be introduced to tens or hundreds of millions of users. The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security. As an example, you'll find that talk about anti-virus and anti-spyware technology is conspicuously absent from this document, because the Bitfrost security platform on the XO laptops largely renders these issues moot.

Nos hemos puesto como objetivo crear un sistema que sea drásticamente más seguro y usable que cualquier otro sistema masivo actualmente en el mercado. Un resultado de la dedicación a la usabilidad es que sólo existe una protección provista por Bitfrost que requiere una respuesta del usuario, y aún entonces, es una sencilla pregunta por 'si o no' comprehensible aún por un chico pequeño. El resto de la seguridad es provista tras bambalinas. El llevar al límite los aspectos de usabilidad y seguridad no es fácil, y es importante destacar que no hemos intentado crear, y no creemos que lo hayamos hecho, un sistema "perfectamente seguro". La idea de seguridad perfecta en el mundo real es vana, y negamos todo tipo de insinuacion que lo hayamos logrado.

We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and as we state in the concluding chapter of this document, we have neither tried to create, nor do we believe we have created, a "perfectly secure" system. Notions of perfect security are foolish, and we distance ourselves up front from any such claims.

La Seguridad y la OLPC

En términos de seguridad, la laptop XO de la OLPC es un ambiente muy particular. Su intención es introducir a chicos pequeños a la computación, muchos en ambientes que no han sido expuestos previamente a la computación o la Internet.

Aún más, la OLPC no tiene como objetivo una distribución reducida donde podría intervenir rápidamente de existir algún problema de seguridad con las máquinas o su uso; en vez, una vez distribuídas, cambios importantes en el modelo de seguridad podrían ser considerados difíciles o imposibles.

In terms of security, the OLPC XO laptops are a highly unique environment. They are slated to introduce computers to young children, many in environments that have had no prior exposure to computing or the Internet.

What's more, OLPC is not targeting small-scale local deployments where it could easily intervene in the case of security problems with the machines or their usage; instead, once the machines are released in the wild, drastic changes in the security model should be considered difficult or impossible.

Existe suficiente experiencia en bloquear las máquinas de los usuarios, usualmente en ambientes empresariales o académicos. Pero la OLPC tienen un requisito que invalida la mayor parte del conocimiento común: la OLPC es, por diseño, luchando para ser una plataforma inherentemente maleable, permitiendo a los chicos modificar, adaptar, o "hackear", sus propias máquinas como a ellos les plazca.

El resultado es que ninguna política de seguridad sobre la computadora puede satisfacer nuestros requerimientos. En su lugar, distribuiremos y activaremos una politica rigurosa de seguridad apropiada aún al más jóven de los usuarios, y que sea capaz de proveer la máxima seguridad disponible. Sin embargo, proveeremos una interfaz gráfica simple con tal que los usuarios interesados puedan deshabilitar cualquiera de las protecciones, permitiendo al usuario ajustar el nivel de seguridad acorde a su interes en hackear su máquina.

Plenty of experience exists in locking down user machines, often in corporate or academic settings. But OLPC has a final constraint that invalidates most of the current common wisdom: OLPC is, by design, striving to be an eminently malleable platform, allowing the children to modify, customize, or "hack", their own machines any way they see fit.

As a result, no one security policy on the computer will satisfy our requirements. Instead, we will ship and enable by default a stringent policy that's appropriate even for the youngest user, and which delivers the strongest available protections. However, we will provide a simple graphical interface for interested users to disable any of these protections, allowing the user to tailor the security level to match her interest in hacking her machine.

Este modo nos permite ser extremadamente seguros por defecto, y proteger aún al usuario que no tiene ningún concepto de la seguridad digital. Al mismo tiempo, evita el interponerse en el camino del usuario cada vez más sofisticado, e interesado en aumentar sus habilidades con la máquina.

Finalmente, y dado que suscribimos a las teorías de aprendizaje constructivistas, eventualmente queremos incitar a todos los chicos a progresar a un nivel de sofisticación mayor y así tomar mayores libertades con su máquina. Sin embargo, mientras exista el potencial de desastre (ej: tornar la máquina totalmente inoperable, o pérdida total de datos), dicho potencial es un gran obstáculo para el progreso. Y es por eso que además de focalizarse en la seguridad, nos enfocamos explícitamente en proveer mecanismos que logren la recuperación de un modo trivial y no intimidante, como podría ser la recuperación del sistema operativo de múltiples fuentes y copias de respaldo desde un servidor central.

This approach allows us to be highly secure by default, and protect even the user who has no conception of digital security. At the same time, it avoids getting in the way of any user who is becoming more sophisticated, and interested in increasing her abilities on the machine.

Finally, because we subscribe to constructionist learning theories, we want to encourage children to all eventually progress to this level of a more sophisticated user who takes greater liberties with her machine. However, as long as there exists potential for disaster (i.e. rendering a machine fully inoperable, or incurring total data loss), this potential serves as a strong deterrent to this progression. Because of this, in addition to focusing on security by default, we are explicitly focusing on providing mechanisms for trivial and unintimidating disaster recovery, such as operating system recovery from multiple sources and data backup to a central server.

Acerca de este documento

Este documento hace un seguimiento de la seguridad a lo largo del ciclo de vida de la laptop en si, comenzando cuando la laptop es producida en la fábrica, al momento en que llega la chico por primera vez, a lo largo del uso de la laptop por el chico, y finalmente el momento en que el chico se deshace o descarta la laptop. Todo esto es precedido por una breve sección sobre nuestras metas y principios, que sirven como fondo para algunas decisiones que han sido tomadas, y quizás no sean obvias si uno piensa sobre la seguridad en el contexto de una laptop o computadora de escritorio normal.

Este documento es completo en cuanto lo que se refiere al modelo de seguridad de la OLPC, pero es generalmente no-técnico. Un documento anexo se encuentra en preparación para complementar este con comentarios y descripciones técnicas completas.

This document follows security throughout the life-cycle of the laptop itself, starting from the moment a laptop is produced in the factory, to the moment it first reaches a child, throughout the child's use of the laptop, and finally stopping at the moment a child wishes to dispose of the laptop. All of this is preceded by a short section on our goals and principles, which serves to provide background to some of the decisions we made, and which might be non-obvious if one thinks of security in the context of normal laptop and desktop machines.

This document is complete with regard to the OLPC security model, but is generally non-technical. A separate document is being prepared that complements this one with fully technical descriptions and commentary.

Principios y objetivos

Principios

Diseño abierto

La seguridad de la laptop no puede depender de algun diseño secreto implantado en el hardware o software.

Sin bloqueos

A pesar que varios parametros por defecto, el sistema de seguridad de la laptop puede imponer varias prohibiciones a las acciones del usuario, debe existir la manera por la cual éstos sistemas de seguridad puedan ser deshabilitados. En dicho caso, la máquina le permitirá al usuario un control absoluto.

Sin lecturas requeridas

La seguridad no puede depender de la habilidad del usuario de leer un mensaje de la computadora y actuar de manera informada y razonable. Si bien el deshabilitar un mecanísmo particular puede requerir una lectura, la máquina debe ser segura desde la fábrica si es entregada a algún usuario que todavía no sabe leer.

Seguridad que no obstruya

Siempre que sea posible, la seguridad en las máquinas debe realizarse tras bambalinas, haciendose notar sólamente por medio de sutiles indicadores visuales o audio, y nunca interponiéndose en el camino del usuario. De existir un conflicto leve frente a la comodidad del usuario, la seguridad máxima toma precedencia, aunque cuidados extremos deben llevarse a cabo con el fin de asegurarse que dichos permisos no reduzcan seriamente o solapadamente la usabilidad de las máquinas.

Por ejemplo, si un programa es descubierto en el intento de violar una medida de seguridad, no se le preguntará al usuario para permitir dicha acción; que será simplemente negada. Si el usuario desea otorgar dicho permiso, ello puede ser hecho en la interfaz gráfica del centro de seguridad.

Open design

The laptop's security must not depend upon a secret design implemented in hardware or software.

No lockdown

Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control.

No reading required

Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism _may_ require reading, a machine must be secure out of the factory if given to a user who cannot yet read.

Unobtrusive security

Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines.

As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.

Objetivos

Sin claves de usuario

Con usuarios jóvenes (a partir de los cinco años), la seguridad de la laptop no puede depender del habilidad del usuario de recordar una clave. No se puede suponer que los usuarios elijan una clave cuando las reciban por primera vez.

Sin autentificación no-encriptada

La autentificación de las laptops o sus usuarios no dependerá de identificadores transmitidos sin encriptar en la red. Esto quiere decir que claves visibles de ningún tipo pueden ser usadas en los protocolos OLPC y que el MAC de Ethernet jamás serán usados como autentificación.

Seguridad desde la caja

La laptop deberá ser usable y segura desde la caja, sin necesidad de realizar o descargar actualizaciones de seguridad en la medidad de lo posible.

Uso limitado de PKI institucional

La laptop estará provista con llaves públicas de la OLPC y la autoridad del el país o región (ej: ministerio o departamento de educación), pero estas llaves no serán usadas para validar la identidad de los usuarios. El único propósito de estas llaves es verificar la integridad del software y contenido incluído en la laptop. Los usuarios serán identificados por medio de un sistema orgánico PKI sin una cadena de confianza certificada (without a certified chain of trust)—en otras palabras, nuestro enfoque a PKI es KCM (Key-Continuity Management).

Sin pérdida permanente de datos

La información en la laptop será replicada sobre algún almacenamiento centralizado de modo tal que el estudiante pueda recuperarla en el caso que la laptop se pierda, sea robada o destruida.

No user passwords

With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers.

No unencrypted authentication

Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication.

Out-of-the-box security

The laptop should be both usable and secure out-of-the-box, without the need to download security updates when at all possible.

Limited institutional PKI

The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust -- in other words, our approach to PKI is KCM, or key continuity management.

No permanent data loss

Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the even that the laptop is lost, stolen or destroyed.

Producción en planta

Como parte de su proceso de producción en la planta, ciertos datos relativos a su manufactura son grabados en un chip flash SPI embarcado. El chip es re-escribible, pero obviando la manipulación del hardware, solamente por un proceso de confianza que no dañará o modificará dicha información.

Los datos de manufactura incluyen dos identificadores únicos: NS, el número de serie (o SN - serial number) y U#, un UUID (universally unique identifier) generado al azar. Los números de serie no son asignados secuencialmente; sino que son elegidos al azar a partir de un conjunto de enteros. El proceso de manufactura mantiene la correspondencia entre numero de serie asignado al azar con el número de serie real secuencial que comenzó en 1 con la primera laptop producida. Esta correspondencia es confidencial pero no secreta, y es mantenida por la OLPC.

As part of factory production, certain manufacturing data is written to the built-in SPI flash chip. The chip is rewritable, but barring hardware tampering, only by a trusted process that will not damage or modify the manufacturing information.

Manufacturing data includes two unique identifiers: SN, the serial number, and U#, the randomly-generated UUID. Serial numbers are not assigned in order; instead, they are chosen randomly from a pool of integers. The manufacturing process maintains a mapping of the random serial number assigned, to the real, incremental serial number which was set to 1 for the first laptop produced. This mapping is confidential but not secret, and is kept by OLPC.

El único objetivo de esta correspondencia al azar es para desalentar cualquier intento de usar los números de series de las laptops entregadas en diferentes países para intentar analizar los volúmenes de compra de cada país.

El UUID de cada laptop, U#, es una secuencia al azar de 32 bytes ASCII imprimibles.

En una de las etapas de diagnósticos en la planta tras haber sido producida, la herramienta de diagnóstico enviará toda la información relacionada a su manufactura, incluyendo el U#, NS y la información de la planta a un servidor de la OLPC. Esta información será encolada en la planta ante cualquier problema de conectividad, y por lo tanto no se perderá bajo ninguna situación prevista.

Al salir de la linea de producción, la laptop se encuentra en modo "desactivada". Esto quiere decir que deberá pasar por el proceso de activación criptográfica cuando sea encendida, antes de poder ser usada por el usuario final.

The random mapping's sole purpose is to discourage attempts at using serial numbers of laptops delivered to different countries for attempting to analyze countries' purchase volumes.

A laptop's UUID, U#, is a random 32-byte printable ASCII identifier.

In one of the factory diagnostics stages after each laptop's production, the diagnostics tool will send the complete manufacturing information, including U#, SN, and factory information, to an OLPC server. This information will be queued at the factory in case of connectivity issues, and so won't be lost under any foreseeable circumstances.

At the end of the production line, the laptop is in the 'deactivated' state. This means it must undergo a cryptographic activation process when powered on, before it can be used by an end user.

Seguridad en la cadena de distribución

La OLPC solo se encarga del embarque de las laptops de su planta de origen al país comprador. El despacho y distribución dentro de cada país es totalmente organizado y responsabilidad de cada país.

Dados los volúmenes de producción de la OLPC, la cadena de distribución supone un vector de ataque atractivo para un ladrón emprendedor. El requerimiento para la activación torna el robo en la etapa de entrega inapetecible, requiriendo una intervención a nivel de hardware sobre cada laptop robada antes de su reventa. Damos una revista al proceso de activación más abajo.

OLPC arranges only the shipment of laptops from their origin factory to each purchasing country. Shipping and delivery within each country is organized fully by the country.

Given OLPC production volumes, the delivery chain poses an attractive attack vector for an enterprising thief. The activation requirement makes delivery theft highly unappealing, requiring hardware intervention to disable on each stolen laptop before resale. We give an overview of the activation process below.

Arribo a la escuela y activacion

Antes que una partida sea despachada a cada escuela, el país utiliza un software provisto por la OLPC para generar una partida de códigos de activación. Esta "lista de activación" posee la tupla (NS, UUID) y su correspondiente código de activación único para cada laptop referenciada. Las listas de activación son generadas por el mismo pais, a medida que las laptops son organizadas en partidas para ser entregadas a escuelas específicas. En otras palabras, no existe una lista maestra de activación.

La lista de activación para cada partida de laptops es cargada a un disco USB, y entregada al responsable de las entregas del proyecto en la escuela destinataria fuera del circuito de entrega efectivo de las laptops. Este responsable de las entregas será comunmente un maestro u otro funcionario administrativo de la escuela. La lista de activación enviada a una escuela no puede ser usada para activar ninguna otra partida.

Before a batch of laptops is shipped to each school, the country uses OLPC-provided software to generate a batch of activation codes. This "activation list" maps each (SN, UUID) tuple to a unique activation code for the referenced laptop. Activation lists are generated on-demand by the country for each laptop batch, as the laptops are partitioned into batches destined for specific schools. In other words, there is no master activation list.

The activation list for a laptop batch is loaded onto a USB drive, and delivered to a project handler in the target school out of band from the actual laptop shipment. The handler will be commonly a teacher or other school administrator. The activation list sent to one school cannot be used to activate any other laptop batch.

Cuando el la lista de activación en el disco USB es recibida, este será conectado al servidor provisto por la OLPC, u otro servidor que pueda ejecutar el software requerido y que se encuentre conectado a un punto de acceso inalámbrico. Cualquier servidor que tome este rol será referido como el 'servidor de activación'. Una laptop XO activada podría ser usada para este propósito de ser necesario.

Tras la recepción de la partida de laptops correspondiente, el responsable de distribución de la escuela tendrá la tarea de entregar a cada chico su laptop. Cuando un chico reciba una laptop, esta estará aún desactivada. Será el chico quien deberá encender la laptop dentro del alcance del punto de acceso inalámbrico del servidor de activación. Cuando esto ocurra, la laptop comunicará de forma segura su tupla (NS, UUID) al servidor, el cual retornará el código de activación en cuestión, suponiendo que la tupla se encuentra en la lista de activación, o un error de no ser así.

When the activation list USB drive is received, it is plugged into the OLPC-provided school server, or another server running the requisite software that is connected to a wireless access point. Whichever server takes on this role will be called the 'activation server'. An activated XO laptop can be used for this purpose, if necessary.

After receiving the matching laptop batch, the school's project handler will be tasked with giving a laptop to each child at the school. When a child receives a laptop, it is still disabled. The child must power on the laptop within wireless range of the school's activation server. When this happens, the laptop will securely communicate its (SN, UUID) tuple to the server, which will return the activation code for the laptop in question, provided the tuple is found in the activation list, or an error if it isn't.

Dado un código de activación inválido o un error, la laptop dormirá durante una hora antes de volver a intentar su activación. Si el código de activación es válido, la laptop esta 'activada', y procede a la primera pantalla de encendido. Un código de activación textual puede ser ingresado manualmente en la máquina, si no se activara automáticamente por alguna razón.

Given an invalid activation code or an error, the laptop will sleep for one hour before retrying activation. If the activation code is valid, the laptop becomes 'activated', and proceeds to boot to the first-boot screen. A textual activation code can be entered into the machine manually, if the machine is not activating automatically for any reason.

Primer encendido

La primera vez que se enciende, un programa se ejecuta preguntandole al chico su nombre, toma una foto, y genera el par de claves ECC en el interin. El par de claves no se encuentra inicialmente protegido por una frase de paso (passphrase) y es asi usada para firmar tanto el nombre como la foto del chico. Esta informacion y la firma son la 'identidad digital' del chico.

La laptop transmite la tupla (NS, UUID, identidad digital) al servidor de activación. La correspondencia entre la laptop y la identidad del usuario es mantenida por las autoridades regionales o nacionales con fines anti-robo, pero nunca llega a la OLPC.

Después de esto, la laptop se inicia normalmente, con toda la seguridad activada.

On first boot, a program is run that asks the child for their name, takes their picture, and in the background generates an ECC key pair. The key pair is initially not protected by a passphrase, and is then used to sign the child's name and picture. This information and the signature are the child's 'digital identity'.

The laptop transmits the (SN, UUID, digital identity) tuple to the activation server. The mapping between a laptop and the user's identity is maintained by the country or regional authority for anti-theft purposes, but never reaches OLPC.

After this, the laptop boots normally, with all security settings enabled.

Instalación de software

Hay una distinción importante entre dos amplios tipos de programas que se ejecutan en un sistema, y esta distinción no usualmente es mencionada en la literatura sobre seguridad. Existen programas que son intencionalmente maliciosos, implicando que son escritos con dichos fines desde un principio, como los virus y worms, y otros programas que son circunstancialmente maliciosos pero que de otro modo son benignos, tales como programas legítimos que han sido vulnerados por un atacante mientras se ejecutan, y son utilizados para ejecutar código para el atacante por medio de la inyección de código u otro mecanismo.

Esta diferenciación es crucial y no puede ser subestimada, pues es un supuesto razonable que la mayor parte del software ejecutandose en una máquina normal comienza como benigno. De hecho, hemos observado que es por medio de la usurpación del software benigno que la mayor parte del software maligno es _introducido_ por primera vez en muchas máquinas, por lo tanto, el proteger al software benigno se convierte en algo doblemente importante.

There is a very important distinction between two broad classes of programs that execute on a running system, and this distinction is not often mentioned in security literature. There are programs that are purposely malicious, which is to say that they were written with ill intent from the start, such as with viruses and worms, and there are programs which are circumstantially malicious but otherwise benign, such as legitimate programs that have been exploited by an attacker while they're running, and are now being instrumented to execute code on behalf of the attacker via code injection or some other method.

This difference is crucial and cannot be understated, because it's a reasonable assumption that most software running on a normal machine starts benign. In fact, we observe that it is through exploitation of benign software that most malicious software is first _introduced_ to many machines, so protecting benign software becomes a doubly worthy goal.

La protección del software benigno es una piedra fundamental en nuestro modelo de seguridad. Y lo utilizamos con la siguiente idea en mente: el software benigno no mentirá sobre sus propósitos durante su instalación.

Como ejemplo, tomemos el juego de Solitario distribuído con muchas versiones de Microsoft Windows. Dicho programa no necesita:

• ningún tipo de acceso a la red
• ninguna capacidad de lectura de los documentos del usuario
• ninguna capacidad para utilizar la cámara o micrófono embarcados
• ninguna capacidad para mirar, o modificar, otros programas

The protection of benign software is a keystone of our security model. We approach it with the following idea in mind: benign software will not lie about its purpose during installation.

To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:

• no network access whatsoever
• no ability to read the user's documents
• no ability to utilize the built-in camera or microphone
• no ability to look at, or modify, other programs

Y si de algún modo es vulnerado por un atacante, el Solitario es libre de hacer cualquier cosa que desee el atacante, incluyendo:

• leer, corromper o borrar documentos del usuario, planillas de cálculo, música, fotos, y cualquier otro archivo
• espiar al usuario via la cámara o micrófono
• remplazar el fondo de pantalla del usuario
• acceder a las palabras claves de los sitios del usuario
• infectar otros programas en disco rígido con un virus
• descargar archivos a la máquina del usuario
• recibir o enviar correo electrónico a nombre del usuario
• hacer ruidos fuertes o embarazosos con los parlantes

El punto crítico aca no es que el Solitario jamás debería ser permitido el realizar cualquiera de las acciones mencionadas (que claramente no debería), sino que sus creadores _saben_ que jamás debería hacerlas. De esto se deduce que si el sistema tuviera la capacidad por la cual el Solitario indicara esto al momento de su instalación, el Solitario podría renunciar irreversiblemente a ciertos privilegios cuando sea instalado, lo cual limita severamente o destruye totalmente su utilidad para cualquier atacante.

Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:

• read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files
• eavesdrop on the user via the camera or microphone
• replace the user's wallpaper
• access the user's website passwords
• infect other programs on the hard drive with a virus
• download files to the user's machine
• receive or send e-mail on behalf of the user
• play loud or embarassing sounds on the speakers

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators _know_ it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.

Las laptops XO de la OLPC proveen justamente dicha facilidad. La instalación de programas no pasa simplemente por la ejecución del instalador, que es a su vez otro programa, sino a traves de un servicio de instalación del sistema que sabe cómo instalar paquetes de programas XO. Durante la instalación, el servicio de instalación le preguntará al paquete por los permisos de seguridad deseados, y posteriormente notificará al Servicio de Seguridad apropiadamente. Una vez instalado, la lista de permisos por programa solamente será modificable por el usuario por medio de la interfaz gráfica.

Un programa benigno como el Solitario simplemente no solicitaría permisos especiales durante su instalación, y llegado su usurpación, sería incapaz de realizar algo particularmente dañino, como alguna de las acciones enumeradas en la lista arriba.

The OLPC XO laptops provide just such a facility. Program installation does not occur through the simple execution of the installer, which is yet another program, but through a system installation service which knows how to install XO program bundles. During installation, the installer service will query the bundle for the program's desired security permissions, and will notify the system Security Service accordingly. After installation, the per-program permission list is only modifiable by the user through a graphical interface.

A benign program such as Solitaire would simply not request any special permissions during installation, and if taken over, would not be able to perform anything particularly damaging, such as the actions from the above list.

Cabe resaltar que dicho sistema _solo_ protege al software benigno. El problema todavía existe con el software intencionalmente malicioso, que bien podría solicitar todos los permisos durante su instalación y abusarlos arbitrariamente cuando sea ejecutado. Para evitar eso es que hacemos ciertos permisos durante la instalación mutuamente excluyentes, lo cual de hecho torna difícil que un programa malicioso solicite un conjunto de permisos que le permitan facilmente realizar acciones maliciosas. Los detalles de dichos mecanismos se encuentra más adelante en este documento.

Como nota final, los programas con firmas criptográficas de la OLPC o de los países individuales pueden evitar los límites a la solicitud de permisos, y de hecho solicitar cualquier conjunto de permisos deseado al momento de su instalación.

It must be noted here that this system _only_ protects benign software. The problem still remains of intentionally malicious software, which might request all available permissions during installation in order to abuse them arbitrarily when run. We address this by making certain initially-requestable permissions mutually exclusive, in effect making it difficult for malicious software to request a set of permissions that easily allow malicious action. Details on this mechanism are provided later in this document.

As a final note, programs cryptographically signed by OLPC or the individual countries may bypass the permission request limits, and request any permissions they wish at installation time.

Ejecución de software: el problema

El modelo de riesgo que intentamos lograr mientras la máquina está corriendo es uno difícil: deseamos tener la capacidad de ejecutar código usualmente sin confianza, al mismo tiempo que limitamos severamente su capacidad de producir daño al sistema.

Muchos de los dispositivos digitales son más vistos o vendidos como embarcados o computadoras administradas que como laptops o máquinas de escritorio personales (un ejemplo es el comunicador PIC de AMD que esquiva el problema del código no confiable completamente, logrando una inmunidad a los virus, malware y spyware permitiendo solamente la ejecución exclusiva de código firmado criptográficamente por el vendedor. En la práctica, esto quiere decir que el usuario esta limitado a la utilización de un conjunto muy limitado de programas provistos por el vendedor, y que no puede desarrollar su propio software o utilizar el de terceros. Si bien esta aproximación a la seguridad limita definitivamente ciertos vectores de ataques, debe ser recalcado que no es una solución definitiva (o silver bullet). Una computadora que no puede ser libremente programada representa una disminución enorme en la utilidad a la cual la mayoría de los usuarios se han acostumbrado y esperan—pero aún si ignoramos esto y nos enfocamos solamente en las calificaciones técnicas de un tal sistema de seguridad, debemos resaltar que casi siempre, las firmas criptográficas de los binarios son revisadas al momento de carga, no continuamente durante su ejecución. Con lo cual, las vulnerabilidades existentes en los binarios provistos por el vendedor aún permiten dañar al sistema. De igual modo, el sistema falla al no proveer ninguna protección contra ataques macro.

The threat model that we are trying to address while the machine is running normally is a difficult one: we wish to have the ability to execute generally untrusted code, while severely limiting its ability to inflict harm to the system.

Many computer devices that are seen or marketed more as embedded or managed computers than personal laptops or desktops (one example is AMD's [[PIC communicator -> http://www.amdboard.com/pic.html]]) purport to dodge the issue of untrusted code entirely, while staving off viruses, malware and spyware by only permitting execution of code cryptographically signed by the vendor. In practice, this means the user is limited to executing a very restricted set of vendor-provided programs, and cannot develop her own software or use software from third party developers. While this approach to security certainly limits available attack vectors, it should be noted it is pointedly not a silver bullet. A computer that is not freely programmable represents a tremendous decrease in utility from what most consumers have come to expect from their computers -- but even if we ignore this and focus merely on the technical qualifications of such a security system, we must stress that almost always, cryptographic signatures for binaries are checked at load time, not continually during execution. Thus exploits for vendor-provided binaries are still able to execute and harm the system. Similarly, this system fails to provide any protection against macro attacks.

Como fue mencionado en la introducción, este modelo de ejecución restringido definitivamente no es una opción para las laptops XO. Aún más, queremos explícitamente incentivar y motivar a nuestros usuarios, los chicos, a participar en una situacion que sería una pesadilla para cualquier experto en seguridad: el compartir fácilmente código entre computadoras.

Como parte de nuestra misión educativa, estamos facilitando a los chicos la capacidad de ver el código del programa que esten corriendo—tanto es así que proveemos la tecla de Ver Código Fuente en el teclado con ese fin—y también estamos haciendoles igualmente fácil el escribir su propio código en Python, nuestro lenguaje de programación por elección. Dado nuestro continuo enfasis en la colaboración como una característica directamente integrada al sistema operativo, el escenario donde un chico desarrolla algún software y desea compartirlo con sus amigos se convierte en algo natural, y que debe ser bien soportado.

As we mention in the introduction, this severely restricted execution model is absolutely not an option for the XO laptops. What's more, we want to explicitly encourage our users, the children, to engage in a scenario certain to give nightmares to any security expert: easy code sharing between computers.

As part of our educational mission, we're making it very easy for children to see the code of the programs they're running -- we even provide a View Source key on the keyboard for this purpose -- and are making it similarly easy for children to write their own code in Python, our programming language of choice. Given our further emphasis on collaboration as a feature integrated directly into the operating system, the scenario where a child develops some software and wishes to share it with her friends becomes a natural one, and one that needs to be well-supported.

Desafortunadamente, el software recibido por medio de un amigo o conocido carece de toda confianza, dado que no existe una correspondencia de la confianza entre personas y software: confiar en un amigo no es, y no puede ser, lo mismo que confiar el código proveniente de dicho amigo. La máquina del amigo puede estar bajo el control de otro, y puede estar intentando enviar código malicioso a todos sus amigos, o el amigo puede querer estar tratando de hacer una jugarreta, o puede haber escrito—ya sea por ignorancia o malicia—software que a veces es malicioso.

Es con éste trasfondo que hemos construído las protecciones de seguridad en la laptop. Una oración capaz de resumir las intenciones de nuestro modelo de seguridad completamente es que "intenta prevenir que el software haga cosas malas". El siguiente capítulo explica las cinco categorías de 'cosas malas' que un software malicioso puede hacer, y el capítulo posterior las protecciones mismas. El capítulo 9 explica el rol de cada protección participa dentro del modelo de riesgos.

Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, or he might have written -- either out of ignorance or malice -- software that is sometimes malicious.

It is against this background that we've constructed security protections for software on the laptop. A one-sentence summary of the intent of our complete software security model is that it "tries to prevent software from doing bad things". The next chapter explains the five categories of 'bad things' that malicious software might do, and the chapter after that our protections themselves. Chapter 9 explains how each protection addresses the threat model.

Modelo de riesgo: las cosas malas que el software puede hacer

En el contexto y propósito de la discusión, existen cinco grandes categorías de "cosas malas" que la ejecución del software puede realizar. Sin un orden particular, el software puede intentar dañar la máquina, vulnerar la privacidad del usuario, dañar la información del usuario, hacer "cosas malas" a otras personas aparte del usuario de la máquina, y por último, suplantar al usuario.

There are five broad categories of "bad things" that running software could do, for the purposes of our discussion. In no particular order, software can attempt to damage the machine, compromise the user's privacy, damage the user's information, do "bad things" to people other than the machine's user, and lastly, impersonate the user.

Dañar la máquina

El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que—siendo un chip flash—tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (re-imaged) y activada para su recuperación.

Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de performance y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo).

Software wishing to render a laptop inoperable has at least five attack vectors. It may try to ruin the machine's BIOS, preventing it from booting. It may attempt to run down the NAND chip used for primary storage, which -- being a flash chip -- has a limited number of write/erase cycles before ceasing to function properly and requiring replacement. Successful attacks on the BIOS or NAND cause hard damage to the machine, meaning such laptops require trained hardware intervention, including part replacement, to restore to operation. The third vector, deleting or damaging the operating system, is an annoyance that would require the machine to be re-imaged and reactivated to run.

Two other means of damaging the machine cause soft damage: they significantly reduce its utility. These attacks are performance degradation and battery drainage (with the side note that variants of the former can certainly cause the latter.)

Cuando nos referimos a la degradación de performance, nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la performance (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la performance general; esta sección será actualizada reflejando dicha información.

When we say performance degradation, we are referring to the over-utilization of any system resource such as RAM, the CPU or the networking chip, in a way that makes the system too slow or unresponsive to use for other purposes. Battery drainage might be a side-effect of such a malicious performance degradation (e.g. because of bypassing normal power saving measures and over-utilization of power-hungry hardware components), or it might be accomplished through some other means. Once we can obtain complete power measurements for our hardware system, we will be aware of whether side channels exist for consuming large amounts of battery power without general performance degradation; this section will be updated to reflect that information.

Vulnerar la privacidad

Prevemos dos modos principales del software vulnerando la privacidad del usuario: el envio no autorizado de información perteneciente al usuario como documentos e imagenes por la red, y el espiar al usuario por medio de la cámara y el micrófono incorporado.

We see two primary means of software compromising user privacy: the unauthorized sending of user-owned information such as documents and images over the network, and eavesdropping on the user via the laptops' built-in camera and microphone.

Dañar los datos del usuario

Un programa malicioso puede intentar borrar o corromper los documentos del usuario, crear una gran cantidad de documentos falsos o llenos de basura que le harían difícil al usuario el encontrar los suyos propios, o atacar a otros servicios del sistema que manipulan datos, como el servicio de búsqueda. De hecho, el atacar al servicio de indexación global puede convertirse en un nuevo canal para el spam, que aparecería constantemente cada vez que el usuario buscase algo en su sistema. Seguramente existen otros vectores de ataque.

A malicious program can attempt to delete or corrupt the user's documents, create large numbers of fake or garbage-filled documents to make it difficult for the user to find her legitimate ones, or attack other system services that deal with data, such as the search service. Indeed, attacking the global indexing service might well become a new venue for spam, that would thus show up every time the user searched for anything on her system. Other attack vectors undoubtedly exist.

Hacer cosas malas a otras personas

El software puede ser malicioso de manera tal que no afecta de un modo directo o importante al usuario u operador de la máquina. Algunos ejemplos incluyen el realizar ataques de denegación de servicio (Denial of Service attack) contra la red inalámbrica o cableada actual (un logro particularmente fácil sobre redes IPv6, sobre las cuales nuestras laptops operarán por defecto), convirtiendose en un relay de spam, uniéndose a un floodnet o algún otro botnet.

Software might be malicious in ways that do not directly or strongly affect the machine's owner or operator. Examples include performing Denial of Service attacks against the current wireless or wired network (a feat particularly easy on IPv6 networks, which our laptops will operate on by default), becoming a spam relay, or joining a floodnet or other botnet.

Suplantar al usuario

Un software malicioso puede intentar abusar de las primitivas de identidad digital del sistema, tales como la firma digital, para enviar mensajes que parecerían provenir del usuario, o abusar de sesiones previamente autenticadas que el usuario puede haber creado hacia recursos privilegiados, tales como el servidor escolar.

Malicious software might attempt to abuse the digital identity primitives on the system, such as digital signing, to send messages appearing to come from the user, or to abuse previously authenticated sessions that the user might have created to privileged resources, such as the school server.

Protecciones

Aquí explicamos el conjunto de protecciones que forman el grueso de la plataforma de seguridad Bitfrost, nuestro nombre para la suma total de los sistemas de seguridad de la laptop. Cada protección enumerada a continuación tiene una etiqueta textual concisa que comienza con la letra P. Dicha etiqueta es puramente una conveniencia para su fácil referencia, y significa tanto la política como el mecanismo de un dado sistema de protección.

Casi todas las protecciones mencionadas pueden ser deshabilitadas por el usuario por medio de una interfaz gráfica. Mientras las protecciones de la laptop se encuentren activas, dicha interfaz no puede ser manipulada por los programas del sistema de ningún modo, ya sea por medio de eventos sintéticos del teclado o el ratón, o la modificación directa del archivo de configuración.

Here, we explain the set of protections that make up the bulk of the Bitfrost security platform, our name for the sum total of the laptop's security systems. Each protection listed below is given a concise uppercase textual label beginning with the letter P. This label is simply a convenience for easy reference, and stands for both the policy and mechanism of a given protection system.

Almost all of the protections we discuss can be disabled by the user through a graphical interface. While the laptop's protections are active, this interface cannot be manipulated by the programs on the system through any means, be it synthetic keyboard and mouse events or direct configuration file modification.

P_BIOS_CORE: proteccion del nucleo de la BIOS

La BIOS de una laptop XO reside en un chip flash SPI de 1MiB, mencionado en la seccion 1.1. Su propósito es el de guardar la información de manufactura acerca de la máquina incluyendo su tupla (NS, UUID), la BIOS propia y su firmware. El reflasheo (reflashing) de la BIOS almacenada esta estrictamente controlado, de modo tal que solamente una imagen BIOS firmada criptográficamente por la OLPC pueda flasheada' al chip. El firmware no realizará el reflasheo si el nivel de la batería es bajo, evitando así que la máquina se apague mientras la operación es llevada a cabo.

Un chico puede solicitar una llave o clave conocida como clave de desarrollador a la OLPC. Esta llave, ligada a la tupla (NS, UUID) de la laptop del chico, le permite al chico flashear cualquier BIOS que desee, de modo tal de permitir a aquellos chicos que se conviertan en desarrolladores avanzados modificar su propio firmware.

The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in Section 1.1. This chip's purpose is to hold manufacturing information about the machine including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the stored BIOS is strictly controlled, in such a way that only a BIOS image cryptographically signed by OLPC can be flashed to the chip. The firmware will not perform a BIOS reflashing if the battery level is detected as low, to avoid the machine powering off while the operation is in progress.

A child may request a so-called developer key from OLPC. This key, bound to the child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she wishes, to accommodate the use case of those children who progress to be very advanced developers and wish to modify their own firmware.

P_BIOS_COPY: Protección de BIOS secundaria

La inclusión de esta protección aún es incierta, y dependerá del tamaño final de la BIOS y el firmware una vez que toda la funcionalidad deseada este incluída. El chip flash SPI provee 1MiB de capacidad; si la BIOS y el firmware pueden ser acomodados en menos de 512KiB, una segunda copia puede ser almacenada en el SPI. Esta copia secundaria sería inmutable (imposible de reflashear) y sería usada para arrancar al sistema en el caso que la BIOS primaria sea inutilizable. Varios factores pueden resultar en dicho estado, principalmente la perdida de energía violenta durante el proceso de flasheo, como ocurriría en el caso de retirar la batería de la máquina, o simplemente un chip SPI defectuoso que no reflashea correctamente. Esta sección será actualizada una vez que se determine la inclusión o no de dicha protección.

The inclusion of this protection is uncertain, and depends on the final size of the BIOS and firmware after all the desired functionality is included. The SPI flash offers 1MB of storage space; if the BIOS and firmware can be made to fit in less than 512KB, a second copy of the bundle will be stored in the SPI. This secondary copy would be immutable (cannot be reflashed) and used to boot the machine in case of the primary BIOS being unbootable. Various factors might lead to such a state, primarily hard power loss during flashing, such as through the removal of the battery from the machine, or simply a malfunctioning SPI chip which does not reflash correctly. This section will be updated once it becomes clear whether this protection can be included.

P_SF_CORE: Protección de archivos del núcleo del sistema

La protección de los archivos del núcleo del sistema impide las modificaciones del sistema almacenado en la memoria flash NAND de la laptop, que es usado como su almacenamiento primario. Cuando se encuentra activa, esta protección controla que ningún proceso altere de cualquier modo los archivos del sistema distribuídos como parte del SO OLPC.

Esta protección no puede ser deshabilitada sin una llave de desarrollador (developer key), mencionada en la Sección 8.1.

The core system file protection disallows modification of the stored system image on a laptop's NAND flash, which OLPC laptops use as primary storage. While engaged, this protection keeps any process on the machine from altering in any way the system files shipped as part of the OLPC OS build.

This protection may not be disabled without a developer key, explained in Section 8.1.

P_SF_RUN: Protección de archivos del sistema ejecutandose

Si bien P_SF_CORE protege a los archivos del sistema *almacenados*, P_SF_RUN protege los archivos del sistema en *ejecución* de ser modificados. Siempre que P_SF_RUN se encuentre activo, en cada inicio, el sistema a ejecutar es cargado directamente de los archivos almacenados, los cuales son marcados como de solo-lectura.

Cuando P_SF_RUN se encuentra desactivado, el procesos de cargado de los archivos del sistema al inicio cambia. En vez de cargar los archivos directamente, una imagen COW (copy-on-write - copia si escribe) es construída a partir de ellos, y los archivos de _esa_ imagen son inicializados como el sistema en ejecución. La imagen COW virtualmente no requiere espacio de almacenamiento adicional en la memoria flash NAND hasta que el usuario realiza modificaciones a los archivos del sistema en ejecución, lo que produce un copiado de los archivos antes de ser cambiados. Estas modificaciones son persistentes entre inicios (booteos), pero sólo se aplica a las copias COW: los archivos del sistema iniciales permanecen intactos.

Whereas P_SF_CORE protects the *stored* system files, P_SF_RUN protects the *running* system files from modification. As long as P_SF_RUN is engaged, at every boot, the running system is loaded directly from the stored system files, which are then marked read-only.

When P_SF_RUN is disengaged, the system file loading process at boot changes. Instead of loading the stored files directly, a COW (copy on write) image is constructed from them, and system files from _that_ image are initialized as the running system. The COW image uses virtually no additional storage space on the NAND flash until the user makes modifications to her running system files, which causes the affected files to be copied before being changed. These modifications persist between boots, but only apply to the COW copies: the underlying system files remain untouched.

Si se reactiva el P_SF_RUN tras su deshabilitación, los archivos utilizados para el inicio del sistema cambian nuevamente; los archivos son cargados a la memoria sin su imagen COW intermedia, y marcados como de solo lectura.

No hay interdependencia entre P_SF_CORE y P_SF_RUN. Si P_SF_CORE está deshabilitado y los archivos del sistema son modificados, pero P_SF_RUN está habilitado, despues del reinicio ninguna modificación al sistema en ejecución sera permitidos, más allá del hecho que los archivos iniciales hayan sido cambiados de la versión original del OS de la OLPC.

If P_SF_RUN is re-engaged after being disabled, the boot-time loading of system files changes again; the system files are loaded into memory directly with no intermediate COW image, and marked read-only.

P_SF_CORE and P_SF_RUN do not inter-depend. If P_SF_CORE is disengaged and the stored system files are modified, but P_SF_RUN is engaged, after reboot no modification of the running system will be permitted, despite the fact that the underlying system files have changed from their original version in the OLPC OS build.

P_NET: Política de protección de red

La utilización de la red por parte de un programa puede estar limitado de las siguientes maneras:

• Restricción Booleana (si/no) de uso de red
• Utilización del ancho de banda por medio de token-bucket y ráfagas
• Límite a la velocidad de transmisión
• Restricciones sobre el destino de los paquetes por nombre, IP y puerto(s)
• Horarios de acceso a la red
• Límite de velocidad por horarios o días
• Restricción como servidor (apertura y escucha de un socket), Booleano y por puerto

Por defecto, se aplicarán límites razonables de velocidad y volúmen de descarga a todos los programas carentes de firmas. De ser necesario, se pueden aplicar diferentes políticas al tráfico dirigido a la malla o los puntos de acceso (access points). Restricciones adicionales podrían ser agregadas a esta lista a medida que completemos la evaluación de los requerimientos de política de red.

Each program's network utilization can be constrained in the following ways:

• Boolean network on/off restriction
• token-bucketed bandwidth throttling with burst allowance
• connection rate limiting
• packet destination restrictions by host name, IP and port(s)
• time-of-day restrictions on network use
• data transfer limit by hour or day
• server restriction (can bind and listen on a socket), Boolean and per-port

Reasonable default rate and transfer limits will be imposed on all non-signed programs. If necessary, different policies can apply to mesh and access point traffic. Additional restrictions might be added to this list as we complete our evaluation of network policy requirements.

P_NAND_RL: Protección de escritura/borrado de la NAND

Un acelerador tipo token-bucket con límites de ráfagas será usado por el sistema de archivos JFF2 sobre la memoria flash NAND, que simplemente comenzará a demorar las operaciones de escritura/borrado generadas por un programa en particular después que su balde (bucket) se haya agotado. Actualmente se encuentra bajo consideración si una demora tal produzca un impacto exponencial, aunque no se ha tomado ninguna decisión y se esperan resultados de pruebas reales.

Una interface con el núcleo (kernel) permitirá el acceso a los niveles de llenado de los baldes (buckets) por programa hacia el espacio del usuario, permitiendo así la creación de más políticas aplicables sobre el espacio de usuario, tales como el cerrado de programas cuyos baldes permanezcan agotados durante mucho tiempo. Estas políticas serán mantenidas y ejecutadas por el Servicio de Seguridad del sistema, un programa en el espacio del usuario privilegiado.

A token-bucketed throttle with burst allowance will be in effect for the JFFS2 filesystem used on the NAND flash, which will simply start delaying write/erase operations caused by a particular program after its bucket is drained. It is currently being considered that such a delay behaves as an exponential backoff, though no decision has yet been made, pending some field testing.

A kernel interface will expose the per-program bucket fill levels to userspace, allowing the implementation of further userspace policies, such as shutting down programs whose buckets remain drained for too long. These policies will be maintained and enforced by the system Security Service, a privileged userspace program.

P_NAND_QUOTA: Cuota de NAND

Con el objeto de prevenir ataques de agotamiento de disco, a los programas se les otorga un espacio de borrador (scratch) limitado para guardar su configuración y archivos temporales, asi como varios caches. Actualmente, el límite es de 5MiB. Adicionalmente, se impondrán límites sobre los inodes y dirents dentro del espacio de borrador (scratch), con valores a determinar.

Esto no incluye el espacio para los documentos de usuario creados o manipulados por el programa, que son almacenados por medio del almacén de archivos (file store). Dicho almacén de archivos (file store) será explicado más adelante.

To prevent disk exhaustion attacks, programs are given a limited scratch space in which they can store their configuration and temporary files, such as various caches. Currently, that limit is 5MB. Additionally, limits will be imposed on inodes and dirents within that scratch space, with values to be determined.

This does not include space for user documents created or manipulated by the program, which are stored through the file store. The file store is explained in a later section.

P_MIC_CAM: Protección de cámara y micrófono

En un primer nivel, la cámara y micrófono incorporados se encuentran protegidos por el hardware: existe un LED al costado de cada uno, que se encenderá (vía hardware, sin control de software) cuando dicho elemento se encuentre activo. Esto provee un indicador simple y obvio de cuando son usados. Su encendido inesperado será una señal ante cualquier intento de espionaje.

El segundo nivel es que el uso de la cámara y el micrófono requieren la solicitud por parte del programa de un permiso especial al momento de instalación como fue descripto en el Capítulo 5. Este permiso sin embargo no le permite a un programa acceder y prender instantáneamente la cámara o el micrófono. Solamente le permite al programa _preguntarle_ al usuario si puede encender la cámara, el micrófono o ambos.

At the first level, our built-in camera and microphone are protected by hardware: an LED is present next to each, and is lit (in hardware, without software control) when the respective component is engaged. This provides a very simple and obvious indication of the two being used. The LEDs turning on unexpectedly will immediately tip off the user to potential eavesdropping.

Secondly, the use of the camera and microphone require a special permission, requested at install-time as described in Chapter 5, for each program wishing to do so. This permission does not, however, allow a program to instantly turn on the camera and microphone. Instead, it merely lets the program _ask_ the user to allow the camera or microphone (or both) to be turned on.

Esto quiere decir que cualquier programa benigno que haya sido subvertido pero que no se haya declarado como utilizador de la cámara o el micrófono no puede ser utilizado para activarlos, NI para solicitarle al usuario que lo haga!

Los programas que se hayan declarado a sí mismos como requeridores de dichos privilegios (ej: una aplicación de videoconferencia o VoIP) pueden instruir al sistema para que le solicite al usuario su permiso de activar la cámara o el micrófono, y si la solicitud es otorgada, el programa tendrá permiso de manipular el componente por un tiempo limitado, ej: 30 minutos. Transcurrido dicho plazo de tiempo, se le deberá solicitar nuevamente al usuario su permiso.

This means that any benign programs which are taken over but haven't declared themselves as needing the camera or microphone cannot be used neither to turn on either, NOR to ask the user to do so!

Programs which have declared themselves as requiring those privileges (e.g. a VOIP or videoconferencing app) can instruct the system to ask the user for permission to enable the camera and microphone components, and if the request is granted, the program is granted a timed capability to manipulate the components, e.g. for 30 minutes. After that, the user will be asked for permission again.

Como fue mencionado en el Capítulo 5, los programas firmados criptográficamente por una autoridad de confianza estarán exentos de necesitar el pedir permiso para manipular los componentes, pero dada la presencia de los LEDs indicadores de su estado, el potencial para su abuso es bastante bajo.

As mentioned in Chapter 5, programs cryptographically signed by a trusted authority will be exempt from having to ask permission to manipulate the components, but because of the LEDs which indicate their status, the potential for abuse is rather low.

P_CPU_RL: Limitando la CPU

Los programas activos en primera plana (foreground) pueden utilizar toda la potencia de la CPU. Sin embargo, los programas en el fondo (background), no pueden usar mas que una cantidad fija—actualmente estamos pensando en usar un 10%—a no ser que tengan un permiso especial por parte del usuario.

La IU de Sugar en las laptops XO no soportan ventanas superpuestas: solo ventanas de aplicaciones maximizadas son soportadas. Cuando nos referimos a la ejecución en primer plano o fondo, nos estamos refiriendo a los programas que estan, o no, mostrando ventanas en la pantalla en un dado momento.

Foreground programs may use all of the machine's CPU power. Background programs, however, may use no more than a fixed amount -- currently we're looking to use 10% -- unless given a special permission by the user.

The Sugar UI environment on the XO laptops does not support overlapping windows: only maximized application windows are supported. When we talk about foreground and background execution, we are referring to programs that are, or are not, currently displaying windows on the screen.

P_RTC: Protección del reloj de tiempo real

Un desplazamiento de tiempo relativo al RTC (real time clock - reloj de tiempo real) es mantenido para cada programa en ejecución, y se le permite al programa cambiar dicho desplazamiento de forma arbitraria. Esto satisface las necesidades de ciertos programas de cambiar el reloj del sistema que usan (ya tenemos un programa de música que debe sincronizarse con un margen de 10ms con cualquier otra máquina con la cual esten tocando música) evitando impactar en otros programas del sistema.

A time offset from the RTC is maintained for each running program, and the program is allowed to change the offset arbitrarily. This fulfills the need of certain programs to change the system time they use (we already have a music program that must synchronize to within 10ms with any machines with which it co-plays a tune) while not impacting other programs on the system.

P_DSP_BG: Permiso de sonido de fondo

Este es un permiso, solicitable al momento de instalación, que habilita al programa a generar audio cuando no se encuentra en primer plano (foreground). Su objetivo es permitir que los programas benignos sean inmunes a ser utilizados para generar sonidos molestos o embarazosos en el caso de ser subvertidos.

This is a permission, requestable at install-time, which lets the program play audio while it isn't in the foreground. Its purpose is to make benign programs immune to being used to play annoying or embarrassing loud sounds if taken over.

P_X: Protección del sistema de ventanas X

Cuando es asignado manualmente a un programa por medio de la interfaz gráfica de seguridad, éste permiso habilita a un programa a enviar eventos de ratón sintéticos a otro programa. Su objetivo es permitir el uso de software de accesibilidad como un teclado-en-pantalla. Este permiso NO es solicitable al momento de instalación, y por lo tanto deber ser manualmente otorgado por el usuario por medio de la interz gráfica, a no ser que el software que quiera usarlo este firmado criptográficamente por una autoridad de confianza.

Sin este permiso, los programas no pueden espiar o simular los eventos de otros, lo cual inhabilita software de grabado de teclado (key logging) o ataques basados en una manipulación sofisticada de eventos sintéticos, donde un software malicioso actúa como un control remoto para algún otro programa.

When manually assigned to a program by the user through a graphical security interface, this permission lets a program send synthetic mouse X events to another program. Its purpose is to enable the use of accessibility software such as an on-screen keyboard. The permission is NOT requestable at install-time, and thus must be manually assigned by the user through a graphical interface, unless the software wishing to use it is cryptographically signed by a trusted authority.

Without this permission, programs cannot eavesdrop on or fake one another's events, which disables key logging software or sophisticated synthetic event manipulation attacks, where malicious software acts as a remote control for some other running program.

P_IDENT: Servicio de identidad

El servicio de identidad es el responsable de generar el par de llaves ECC durante el primer inicio, mantener al par seguro, y responder a los pedidos de inicio de sesiones firmadas o encriptadas con otras máquinas en la red.

Con el uso del servicio de identidad, todas las interacciones o comunicaciones entre pares (e-mails, mensajes instantáneos, y similares) pueden ser firmados criptográficamente para mantener su integridad aún si son ruteados a través de pares potencialmente maliciosos en la malla, y también puede ser encriptado en aquellos países que no represente un problema legal.

The identity service is responsible for generating an ECC key pair at first boot, keeping the key pair secure, and responding to requests to initiate signed or encrypted sessions with other networked machines.

With the use of the identity service, all digital peer interactions or communication (e-mails, instant messages, and so forth) can be cryptographically signed to maintain integrity even as they're routed through potentially malicious peers on the mesh, and may also be encrypted in countries where this does not present a legal problem.

P_SANDBOX: Cárceles de programas

Un programa en la XO comienza en un chroot fortificado, similar a una cárcel BSD, donde la raíz visible del sistema de archivos es el su propio espacio de borrador (scratch). Usualmente no tiene acceso a las rutas de acceso del sistema tales como /proc o /sys, no puede ver otros programas en el sistema o sus espacios de borrador (scratch). No puede acceder a los documentos del usuario directamente, sino a traves del servicio de almacén de archivos (file store service), explicado en la siguiente sección.

El espacio de borrador (scratch) de cada programa posee tres directorios escribibles, llamados 'tmp', 'conf', y 'data'. El programa es libre de usarlos para archivos temporales, de configuración, y datos (recursos) respectivamente. El resto del espacio de borrador (scratch) es inmutable; el programa no puede modificar sus binarios o archivos de recursos principales. Este modelo asegura que un programa pueda ser restaurado a su instalación de base por medio de la eliminación del contenido de esos tres directorios escribibles, y que pueda ser desinstalado en su totalidad eliminando su directorio.

A program on the XO starts in a fortified chroot, akin to a BSD jail, where its visible filesystem root is only its own constrained scratch space. It normally has no access to system paths such as /proc or /sys, cannot see other programs on the system or their scratch spaces, and only the libraries it needs are mapped into its scratch space. It cannot access user documents directly, but only through the file store service, explained in the next section.

Every program scratch space has three writable directories, called 'tmp', 'conf', and 'data'. The program is free to use these for temporary, configuration, and data (resource) files, respectively. The rest of the scratch space is immutable; the program may not modify its binaries or core resource files. This model ensures that a program may be restored to its base installation state by emptying the contents of the three writable directories, and that it can be completely uninstalled by removing its bundle (scratch space) directory.

P_DOCUMENT: Servicio de almacenamiento de archivos

A diferencia de las máquinas tradicionales, los documentos del usuario en las laptops XO no son guardados directamente en el sistema de archivos. En su lugar, son leídos y guardados por medio de un servicio de almacenamiento de archivos, que provee una interfaz orientada-a-objetos a los documentos del usuario. El diseño, en términos amplios y generales, es similar a WinFS de Microsoft, ya que el almacén permite una rica asociación de metadata manteniendo la semántica de lectura y escritura (read()/write()) tradicionales de UNIX para la manipulación del contenido del archivo.

Los programas en la XO no pueden hacer uso de la función open() (abrir) para abrir arbitrariamente un documento del usuario en el sistema, ni inspeccionar la lista de documentos disponibles, ej: examinando los contenidos de un directorio. En su lugar, cuando un programa desea abrir un documento del usuario, debe solicitarle al sistema que le presente al usuario un dialogo de 'apertura de archivo'. Una versión copia-si-escribe (copy-on-write) del archivo así seleccionado simplemente "aparecerá" en el espacio de borrador (scratch) del programa junto con un mensaje informandole de su ruta de acceso dentro de dicho espacio de borrador (scratch).

Unlike with traditional machines, user documents on the XO laptop are not stored directly on the filesystem. Instead, they are read and stored through the file store service, which provides an object-oriented interface to user documents. Similar in very broad terms to the Microsoft WinFS design, the file store allows rich metadata association while maintaining traditional UNIX read()/write() semantics for actual file content manipulation.

Programs on the XO may not use the open() call to arbitrarily open user documents in the system, nor can they introspect the list of available documents, e.g. through listing directory contents. Instead, when a program wishes to open a user document, it asks the system to present the user with a 'file open' dialog. A copy-on-write version of the file that the user selects is also mapped into this scratch space -- in effect, the file just "appears", along with a message informing the program of the file's path within the scratch space.

Unix permite el pasaje de descriptores de archivos (fds - file descriptors) a traves de domain sockets de Unix, con lo cual una alternativa de P_DOCUMENT sería pasar el descriptor (fd) de dicho archivo. Hemos decidido no usar dicha alternativa ya que la comunicación con el almacén de archivos no se lleva a cabo directamente sobre domain sockets de Unix, sino por medio de los mecanismos del D-BUS IPC, y porque la manipulación directa de los descriptores (fds) puede ser complicada en lenguajes de alto nivel.

Los programas benignos no son afectados negativamente por esta necesidad de usar al almacén de archivos para acceder a los documentos, particularmente porque en general no les interesa mostrar sus propios diálogos de apertura de archivos (con la rara excepción de aquellos que los especializan ej: permitir una vista en miniatura; por el momento, no esta siendo considerado este caso de uso).

Sin embargo, los programas malignos, pierden una importante capacidad de violar la privacidad del usuario o dañar sus datos, ya que todo acceso a los documentos requiere del consentimiento explícito por parte del usuario.

Unix supports the passing of file descriptors (fds) through Unix domain sockets, so an alternative implementation of P_DOCUMENT would merely pass in the fd of the file in question to the calling program. We have elected not to pursue this approach because communication with the file store service does not take place directly over Unix domain sockets, but over the D-BUS IPC mechanism, and because dealing with raw fds can be a hassle in higher-level languages.

Benign programs are not adversely impacted by the need to use the file store for document access, because they generally do not care about rendering their own file open dialogs (with the rare exception of programs which create custom dialogs to e.g. offer built-in file previews; for the time being, we are not going to support this use case).

Malicious programs, however, lose a tremendous amount of ability to violate the user's privacy or damage her data, because all document access requires explicit assent by the user.

P_DOCUMENT_RO

Ciertos tipos de software, como un programa de visualizacion de fotos, necesita el acceso a todos los documentos de un cierto tipo (ej: imágenes) con el fin de cumplir su función. Esto entra en conflicto directo con la protección P_DOCUMENT que requiere el consentimiento del usuario para cada documento a abrir—en este caso, cada foto.

Para resolver este dilema, nos debemos preguntar: "de que estamos tratando de proteger al usuario?" La respuesta, en este caso, es de un programa malicioso que solicita el permiso de leer todas las imagenes, o todos los archivos de texto, o todos los e-mails, y despues enviar dichos documentos por la red a un atacante o su publicación, vulnerando seriamente la privacidad del usuario.

Certain kinds of software, such as photo viewing programs, need access to all documents of a certain kind (e.g. images) to fulfill their desired function. This is in direct opposition with the P_DOCUMENT protection which requires user consent for each document being opened -- in this case, each photo.

To resolve the quandary, we must ask ourselves: "from what are we trying to protect the user?". The answer, here, is a malicious program which requests permission to read all images, or all text files, or all e-mails, and then sends those documents over the network to an attacker or posts them publicly, seriously breaching the user's privacy.

Resolvemos esto permitiendo que un programa solicite permisos de solo-lectura para un tipo de documento (ej: imagen, audio, texto, e-mail) durante el proceso de instalación, pero haciendo dicho permiso (P_DOCUMENT_RO) mutuamente excluyente con el solicitar cualquier tipo de acceso a la red. En otras palabras, un programa de visualización de fotos, normalmente no tiene ninguna necesidad o interés en conectarse a Internet.

Como con otros permisos, el usuario puede habilitar el permiso de red a un dado programa que haya solicitado P_DOCUMENT_RO durante su instalación, evitando así la exclusión mutua.

We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet.

As with other permissions, the user may assign the network permission to a program which requested P_DOCUMENT_RO at install, bypassing the mutual exclusion.

P_DOCUMENT_RL: Limitando el ritmo de almacenamiento de archivos

El almacén de archivos (file store) no permite a los programas guardar nuevos archivos o nuevas versiones de archivos viejos con una frecuencia mayor a un dado valor, ej: una vez cada 30 segundos.

The file store does not permit programs to store new files or new versions of old files with a frequency higher than a certain preset, e.g. once every 30 seconds.

P_DOCUMENT_BACKUP: Servicio de respaldo de archivos

Cuando se este dentro del alcance de servidores que se anuncien a sí mismos como oferentes del servicio de respaldo (backup), la laptop realizará automáticamente las copias de respaldo incrementales de los documentos del usuario que podrán ser recuperados con posterioridad. Dado el deseo de evitar que un chico tenga que generar una nueva identidad digital si alguna vez su laptop es extraviada, robada o destruida, por defecto el par de llaves ECC del chico tambien son copiadas al servidor de respaldo. Dado que la llave privada de un chico normalmente no está protegida con una palabra clave (password), robando el servidor primario de respaldo (normalmente el servidor escolar) le ofrece al ladrón la habilidad de suplantar a cualquier chico en el sistema.

Por el momento, consideramos que esto es un riesgo aceptable. Aunque debería ser mencionado que la llave privada sólo será copiada al servidor de respaldo primario—usualmente en la escuela—y no a cualquier servidor que se anuncia como proveedor del servicio de respaldo. Aún más, en cualquiera de los servidores de respaldo no-primarios, solamente se guardarán versiones incrementales encriptadas.

When in range of servers that advertise themselves as offering a backup service, the laptop will automatically perform incremental backups of user documents which it can later retrieve. Because of the desire to avoid having to ask children to generate a new digital identity if their laptop is ever lost, stolen or broken, by default the child's ECC keypair is also backed up to the server. Given that a child's private key normally has no password protection, stealing the primary backup server (normally the school server) offers the thief the ability to impersonate any child in the system.

For now, we deem this an acceptable risk. We should also mention that the private key will only be backed up to the primary backup server -- usually in the school -- and not any server that advertises itself as providing backup service. Furthermore, for all non-primary backup servers, only encrypted version of the incremental backups will be stored.

P_THEFT: Protección anti-robo

El proyecto de la OLPC ha recibido solicitudes muy firmes por parte de algunos países considerando unirse al programa para la inclusión de un poderoso servicio anti-robo a fin de disuadir a la mayoría de los ladrones.

Proveemos dicho servicio para que los países interesados puedan habilitarlo en sus laptops. Funciona por medio de la ejecución de un proceso privilegiado que no puede ser deshabilitado o finalizado aún por el administrador (root), un demonio (daemon) anti-robo que al detectar un acceso a Internet, realiza una llamada-a-casa (call-home)—no más de una vez al día—a los servidores anti-robo nacionales. Al hacerlo, es capaz de usar al NTP (network time protocol—protocolo de tiempo de red) de manera segura para ajustar el reloj de tiempo real (RTC - real time clock) de la máquina a la hora actual, y despues obtener un plazo criptográfico para seguir corriendo durante una dada cantidad de tiempo, ej: 21 días. La duración del plazo es controlada por cada país.

The OLPC project has received very strong requests from certain countries considering joining the program to provide a powerful anti-theft service that would act as a theft deterrent against most thieves.

We provide such a service for interested countries to enable on the laptops. It works by running, as a privileged process that cannot be disabled or terminated even by the root user, an anti-theft daemon which detects Internet access, and performs a call-home request -- no more than once a day -- to the country's anti-theft servers. In so doing, it is able to securely use NTP to set the machine RTC to the current time, and then obtain a cryptographic lease to keep running for some amount of time, e.g. 21 days. The lease duration is controlled by each country.

La tupla (NS, UUID) de una laptop robada será reportada al cuerpo responsable del servicio anti-robo encargado del proyecto de la OLPC en el país. La laptop será así marcada como robada en la base de datos central nacional.

Un ladrón puede intentar varias cosas con la laptop: usarla para conectarse a la Internet, aislarla de cualquier red e utilizarla de modo aislado, o usar sus componentes como piezas.

A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC oversight body in charge of the anti-theft service. The laptop will be marked stolen in the country's master database.

A thief might do several things with a laptop: use it to connect to the Internet, remove it from any networks and attempt to use it as a standalone machine, or take it apart for parts.

En el primer caso, el daemon anti-robo se enteraría que la laptop ha sido robada tan pronto como se conecte a Internet, y llevará a cabo un apagado 'duro' (hard shutdown) y bloqueará la máquina de modo tal de necesitar una activación, mencionada anteriormente, para volver a funcionar.

No esperamos que las máquinas sean un blanco apetecible para la reventa de partes. Exceptuando la pantalla especial, todas las otras partes de las laptops XO se encuentran soldadas a la placa madre (motherboard).

In the former case, the anti-theft daemon would learn that the laptop is stolen as soon as it's connected to the Internet, and would perform a hard shutdown and lock the machine such that it requires activation, described previously, to function.

We do not expect the machines will be an appealing target for part resale. Save for the custom display, all valuable parts of the XO laptops are soldered onto the motherboard.

Considerando el caso donde una máquina robada es usada como una computadora personal pero sin estar conectada a Internet, el daemon anti-robo procederá a apagar y bloquear la máquina si su plazo criptográfico alguna vez expirase. En otras palabras, si el país opera con plazos de 21 días, una laptop normal, no-robada, tendrá su plazo renovado por 21 días cada día que se conecte a Internet. Pero si la máquina no se conecta a Internet durante 21 días, se apagará y bloqueará.

Dado que esto podría representar ciertos problemas en algunos países con un acceso intermitente a Internet, los plazos pueden ser bastante largos (siguen siendo una disuasión efectiva aún con una duración de tres meses), o pueden ser prolongados por medio de la conexion de un disco USB al servidor de activación. Por ejemplo, un país puede otorgar plazos de tres semanas, pero si una escuela sufriese un desperfecto en su antena satelital, el cuerpo responsable del país de la OLPC puede enviar por correo un disco USB al responsable de la distribución en la escuela, el cual una vez conectado al servidor escolar, y de un modo transparente, extiende el plazo para cada laptop referenciada por un dado período de tiempo.

To address the case where a stolen machine is used as a personal computer but not connected to the Internet, the anti-theft daemon will shut down and lock the machine if its cryptographic lease ever expires. In other words, if the country operates with 21-day leases, a normal, non-stolen laptop will get the lease extended by 21 days each day it connects to the Internet. But if the machine does not connect to the Internet for 21 days, it will shut down and lock.

Since this might present a problem in some countries due to intermittent Internet access, the leases can either be made to last rather long (they're still an effective theft deterrent even with a 3 month duration), or they can be manually extended by connecting a USB drive to the activation server. For instance, a country may issue 3-week leases, but if a school has a satellite dish failure, the country's OLPC oversight body may mail a USB drive to the school handler, which when connected to the school server, transparently extends the lease of each referenced laptop for some period of time.

El sistema anti-robo no puede ser evitado mientras el P_SF_CORE este habilitado (y su deshabilitación requiere de una llave de desarrollador). Esto, de hecho, quiere decir que un chico es libre de realizar cualquier modificación sobre su espacio de usuario en su máquina (por medio de la desactivación del P_SF_RUN sin necesidad de la llave de desarrollador), pero no puede cambiar el núcleo (kernel) en ejecución sin solicitar la llave. El proceso de entrega de llaves tiene incorporado una demora de 14 días con el objeto de permitir demoras en el reporte de robos a traves del sistema, y sólo es emitida si la máquina no ha sido reportada como robada al finalizar dicho periodo de tiempo.

The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and disabling it requires a developer key). This, in effect, means that a child is free to do any modification to her machine's userspace (by disabling P_SF_RUN without a developer key), but cannot change the running kernel without requesting the key. The key-issuing process incorporates a 14-day delay to allow for a slow theft report to percolate up through the system, and is only issued if the machine is not reported stolen at the end of that period of time.

P_SERVER_AUTH: Autentificación transparente y segura a un servidor autorizado

Cuando se este dentro del alcance de un servidor autorizado (ej: uno provisto por la OLPC o el país), la laptop puede responder de manera segura a un desafío de autentificación (authentication challenge) con su tupla (NS, UUID). Además de servirle a la escuela como un mecanismo de control de acceso a la red—sabemos de ciertas escuelas, por ejemplo, no desean proveer acceso a Internet a sus ex-alumnos, solamente a los actuales—esta autentificación puede desbloquear ciertos servicios extras como copias de respaldo y el acceso servicios de identidad digital descentralizados tales como OpenID.

OpenID es particularmente interesante para la OLPC, dado que puede ser usado para perpetuar un acceso sin palabras claves aún con sitios que normalmente requieren autentificación, siempre y cuando soporte OpenID. El modo de uso actualmente más común entre los proveedores del servicio de OpenID es el de requerir una autentificación al usuario por medio de una palabra clave. Con un proveedor de servicio OpenID corriendo en el servidor escolar (o algún otro servidor de confianza), los logins a sitios que funcionan con OpenID simplemente ocurrirán de modo transparente, dado que la máquina del chico ya ha sido autenticada en el fondo por P_SERVER_AUTH.

When in wireless range of a trusted server (e.g. one provided by OLPC or the country), the laptop can securely respond to an authentication challenge with its (SN, UUID) tuple. In addition to serving as a means for the school to exercise network access control -- we know about some schools, for instance, that do not wish to provide Internet access to alumni, but only current students -- this authentication can unlock extra services like backup and access to a decentralized digital identity system such as OpenID.

[[OpenID -> http://en.wikipedia.org/wiki/OpenID]] is particularly appealing to OLPC, because it can be used to perpetuate passwordless access even on sites that normally require authentication, as long as they support OpenID. The most common mode of operation for current OpenID identity providers is to request password authentication from the user. With an OpenID provider service running on the school server (or other trusted servers), logins to OpenID-enabled sites will simply succeed transparently, because the child's machine has been authenticated in the background by P_SERVER_AUTH.

(A futuro) P_PASSWORD: Proteccion con clave

Todavía no ha sido definido si esta protección entrará en la generación 1 de las laptops XO. Cuando sea instrumentada, sin embargo, le permitirá al usuario determinar un palabra clave (password) para ser usada con su identidad digital, iniciar la máquina y el acceso a algunos de sus archivos.

It is unclear whether this protection will make it in to generation 1 of the XO laptops. When implemented, however, it will allow the user to set a password to be used for her digital identity, booting the machine, and accessing some of her files.

Considerando el modelo de riesgos

Aquí examinamos las cinco categorías de "cosas malas" que el software puede hacer segun el Capítulo 7, y explicamos como las protecciones enumeradas en el Capítulo 8 ayudan. Las siguientes secciones son dadas en el mismo orden que en el modelo de riesgos del Capítulo 7.

We look at the five categories of "bad things" software can do as listed in Chapter 7, and explain how protections listed in Chapter 8 help. The following sections are given in the same order as software threat model entries in Chapter 7.

Dañando la máquina

P_BIOS_CORE se asegura que la BIOS solo pueda ser actualizada por imagenes BIOS provenientes de fuentes confiables. Un chico con una llave de desarrollador puede flashear cualquier BIOS deseada, aunque si somos capaces de instrumentar P_BIOS_COPY, la máquina permanecerá operacional aun si el chico flashea una BIOS rota o inservible. Los programas que buscan dañar al SO no lo pueden hacer a causa de P_SANDBOX y P_SF_RUN. Llegado el caso en el que usuario con P_SF_RUN deshabilitado fuese engañado para dañar su SO o lo hace accidentalmente, P_SF_CORE le permite restaurar al estado inicial (activación) al momento de re-iniciar o arrancar.

Los programas que intentan arruinar la NAND consumiendo los ciclos de escritura/borrado son controlados por medio de P_NAND_RL, y los ataques de agotamiento de disco en el espacio de borrador (scratch) son mantenidos bajo control por P_NAND_QUOTA. Los ataques de agotamiento del disco con documentos del usuario son mucho mas difíciles por P_DOCUMENT_RL.

Los programas que sobrecargan la CPU son mantenidos en linea con P_CPU_RL. Y los de redes son controlados por medio de politicas P_NET.

P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from trusted sources. A child with a developer key may flash whichever BIOS she pleases, though if we are able to implement P_BIOS_COPY, the machine will remain operational even if the child flashes a broken or garbage BIOS. Programs looking to damage the OS cannot do so because of P_SANDBOX and P_SF_RUN. Should a user with P_SF_RUN disabled be tricked into damaging her OS or do so accidentally, P_SF_CORE enables her to restore her OS to its initial (activated) state at boot time.

Programs trying to trash the NAND by exhausting write/erase cycles are controlled through P_NAND_RL, and disk exhaustion attacks in the scratch space are curbed by P_NAND_QUOTA. Disk exhaustion attacks with user documents are made much more difficult by P_DOCUMENT_RL.

CPU-hogging programs are reined in with P_CPU_RL. Network-hogging programs are controlled by policy via P_NET.

Vulnerando la privacidad

La lectura arbitraria y/o el envío de los documentos del usuario por la red es controlado por P_DOCUMENT, mientras que el marcar los documentos con el programa que los creó permite controlar el escenario en el cual un programa malicioso intenta hacer spam en el servicio de búsqueda. Los resultados de un único programa en las búsquedas puede ser ocultado (permanentemente), o eliminados del índice completamente.

P_DOCUMENT_RO protege al usuario en forma adicional al evitar una violación a la privacidad en gran escala por software que pretende ser un "visualizador" de un amplio grupo de documentos.

P_MIC_CAM hace que el espiar al usuario sea difícil, y P_X hace extremadamente difícil el robar palabras claves u otro tipo de información sensible, o monitorear el ingreso de texto desde otros programas en ejecución.

Arbitrary reading and/or sending of the user's documents over the network is curbed by P_DOCUMENT, while tagging documents with the program that created them addresses the scenario in which a malicious program attempts to spam the search service. Search results from a single program can simply be hidden (permanently), or removed from the index completely.

P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches by software that purports to be a "viewer" of some broad class of documents.

P_MIC_CAM makes eavesdropping on the user difficult, and P_X makes it very hard to steal passwords or other sensitive information, or monitor text entry from other running programs.

Dañando los datos del usuario

El almacén de archivos (file store) no permite a los programas sobre-escribir objetos tales como e-mail y texto que no sean blobs binarios opacos. En vez de ello, una nueva versión es guardada, y el almacén de archivos (file store) presenta una lista completa con el histórico de versiones. Esto permite una amplia protección de los documentos contra borrado o corrupción a manos de programas maliciosos—que, por supuesto, tuvieron que obtener el permiso del usuario para mirar el archivo en cuestion para comenzar, como es explicado por P_DOCUMENT.

En el caso de los blobs—videos, música, imagenes—un programa malicioso con el cual el usuario específicamente abra un archivo dado posee la capacidad de corromperlo o borrarlo. Sin embargo, no podemos proteger al usuario de si mismo. Vale la pena destacar que el borrado esta limitado _únicamente_ a los archivos que el usuario ha abierto explícitamente. Más aún, P_DOCUMENT_BACKUP permite una salida aún en dicha situación, suponiendo que la máquina haya tenido la oportunidad de cruzarse con un servidor de respaldo (backup) (los servidores escolares de la OLPC se anuncian como tales).

File store does not permit programs to overwrite objects such as e-mail and text which aren't opaque binary blobs. Instead, only a new version is stored, and the file store exposes a list of the full version history. This affords a large class of documents protection against deletion or corruption at the hands of a malicious program -- which, of course, had to obtain the user's permission to look at the file in question in the first place, as explained in P_DOCUMENT.

For binary blobs -- videos, music, images -- a malicious program in which the user specifically opens a certain file does have the ability to corrupt or delete the file. However, we cannot protect the user from herself. We point out that such deletion is constrained to _only_ those files which the user explicitly opened. Furthermore, P_DOCUMENT_BACKUP allows a final way out even in such situations, assuming the machine came across a backup server (OLPC school servers advertise themselves as such).

Haciendo cosas malas a otros

Las laptops XO serán poco apetecibles como relays de spam o clientes de floodnet dado los límites impuestos a todos los programas carentes de firmas digitales por el P_NET. A pesar del atractivo que supone la escala de distribución de las XOs para spamming o flooding, suponemos que la restricción de bajo uso de la red para software carentes de confianza—junto a la gran dificultad de escribir gusanos (worms) o software auto-propagante para las máquinas XO—reducirá drásticamente esta preocupación.

XO laptops will be quite unattractive as spam relays or floodnet clients due to network rate and transfer limits imposed on all non-signed programs by P_NET. Despite the appeal of the XO deployment scale for spamming or flooding, we expect that a restriction to generally low-volume network usage for untrusted software -- coupled with the great difficulty in writing worms or self-propagating software for XO machines -- will drastically reduce this concern.

Suplantando al usuario

El diseño del servicio de identidad, P_IDENT, no permite a los programas entrar jamás en contacto con el par de llaves o claves criptográficas del usuario, ni inyectar información en sesiones ya abiertas que esten usando el servicio de identidad para firmar o encriptarlas.

The design of the identity service, P_IDENT, does not allow programs to ever come in direct contact with the user's cryptographic key pair, nor to inject information into currently-open sessions which are using the identity service for signing or encryption.

Varios

Además de las protecciones ya mencionadas que contemplan distintas partes del modelo de riesgos, los permisos P_RTC y P_THEFT se combinan para ofrecer un sistema anti-robo que requiere de un grado de sofisticación importante (manipulación del hardware) para ser eliminado, y el P_DSP_BG provee una protección contra ciertos tipos de malware impertinentes, tales como el infame virus Yankee Doodle de 1989.

In addition to the protections listed above which each address some part of the threat model, permissions P_RTC and P_THEFT combine to offer an anti-theft system that requires non-trivial sophistication (ability to tamper with on-board hardware) to defeat, and P_DSP_BG provides protection against certain types of annoying malware, such as the infamous 1989 Yankee Doodle virus.

Faltantes a la lista

Por lo menos dos problemas, comúnmente asociados con laptops y chicos como usuarios de computadoras respectivamente, no son discutidos en nuestro modelo de riesgo o sistemas de protección: la encriptación del disco rígido y el filtrado / control parental de contenido cuestionable.

At least two problems, commonly associated with laptops and child computer users respectively, are not discussed by our threat model or protection systems: hard drive encryption and objectionable content filtering / parental controls.

Encriptación del sistema de archivos

Si bien las laptops XO no poseen un disco rígido técnicamente hablando, la pregunta sobre la encriptación de datos es perfectamente aplicable al almacenamiento primario de memoria flash. La respuesta consiste de dos partes: primero, la encriptación del sistema de archivos sería demasiado lenta para nuestro hardware. Las laptops XO pueden encriptar 2-4MiB/s usando el algoritmo AES-128 en modo CBC, usando 100% de la CPU. Esto es aproximadamente 1/10 de la velocidad de transferencia del chip flash NAND. Cambiando a un algoritmo más rápido como el RC4 permitiría aumentar la velocidad de encriptación a unos 15MiB/s usando bloques grandes y una utilización del 100% de la CPU, y por lo tanto sigue siendo demasiado lento para un uso generalizado, y provee una seguridad cuestionable. En segundo lugar, dada la edad de nuestros usuarios, hemos diseñado la plataforma Bitfrost explícitamente para que no requiera del usuario el uso de palabras claves para controlar el acceso a su computadora. Pero sin palabras claves, la encriptación de datos del usuario tendría que recaer sobre identificadores únicos de la laptop misma, lo cual no brindaría ninguna protección a los datos en el caso de ser robada.

Una vez que la plataforma Bitfrost soporte la protección P_PASSWORD, posiblemente no antes de la segunda generación de laptops XO, proveeremos el soporte para que el usuario encripte archivos individuales si es que la protección es activada y configurada con una palabra clave por el usuario.

While the XO laptops have no hard drive to speak of, the data encryption question applies just as well to our flash primary storage. The answer consists of two parts: firstly, filesystem encryption is too slow given our hardware. The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC mode, using 100% of the available CPU power. This is about ten times less than the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4 increases encryption throughput to about 15 MB/s with large blocks at 100% CPU utilization, and is hence still too slow for general use, and provides questionable security. Secondly, because of the age of our users, we have explicitly designed the Bitfrost platform not to rely on the user setting passwords to control access to her computer. But without passwords, user data encryption would have to be keyed based on unique identifiers of the laptop itself, which lends no protection to the user's documents in case the laptop is stolen.

Once the Bitfrost platform supports the P_PASSWORD protection, which might not be until the second generation of the XO laptops, we will provide support for the user to individually encrypt files if she enabled the protection and set a password for herself.

Filtrado de contenido cuestionable

La plataforma Bitfrost es el gobernante del sistema de seguridad de las laptops XO. Dado que el término "contenido cuestionable" carece de toda definición técnica, siendo algo puramente social, el filtrado de dicho contenido cae fuera de los alcances de la plataforma de seguridad y este documento.

The Bitfrost platform governs system security on the XO laptops. Given that "objectionable content" lacks any kind of technical definition, and is instead a purely social construct, filtering such content lies wholly outside of the scope of the security platform and this document.

Descarte de la laptop y seguridad de transferencia

El tiempo de vida pensado para una laptop XO es de cinco años. Una vez transcurrido dicho tiempo, el propietario de la laptop puede querer deshacerse de ella. De modo similar, y por razones logísticas, una laptop puede cambiar de manos, de un dueño a otro.

Un programa de re-inicialización de la laptop será provisto para borrar de manera segura la identidad digital del usuario y todos sus documentos de la laptop. De ser ejecutado en modo "descarte", el programa también podría deshabilitar permanentemente a la laptop, aunque no esta muy claro que dicha funcionalidad sea de hecho necesaria, y por lo tanto no hay planes para proveerla.

The target lifetime of an XO laptop is five years. After this time elapses, the laptop's owner might wish to dispose of the laptop. Similarly, for logistical reasons, a laptop may change hands, going from one owner to another.

A laptop re-initialization program will be provided which securely erases the user's digital identity and all user documents from a laptop. When running in "disposal" mode, that program could also be made to permanently disable the laptop, but it is unclear whether such functionality is actually necessary, so there are no current plans for providing it.

Comentarios finales

En la mitología Nórdica, Bifröst es el puente que impide a los mortales, habitantes de Midgard, aventurarse en Asgard, el dominio de los dioses. De hecho, Bifröst es un poderosos sistema de seguridad diseñdo para mantener alejados a intrusos no deseados.

Esta no es la razón detrás del porque el nombre de la plataforma de seguridad de la OLPC es un juego sobre el mítico puente. Lo que es particularmente interesante de Bifröst es una historia que el historiador y poeta islandés Snorri Sturlson del siglo XII cuenta en su manual poético llamado Edda prosaica. He aquí un extracto relevante:

In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of the realm of Midgard, from venturing into Asgard, the realm of the gods. In effect, Bifröst is a powerful security system designed to keep out unwanted intruders.

This is not why the OLPC security platform's name is a play on the name of the mythical bridge, however. What's particularly interesting about Bifröst is a story that 12th century Icelandic historian and poet Snorri Sturluson tells in the first part of his poetics manual called the Prose Edda. Here is the relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:

Nota: esta es una traducción ad-hoc al castellano de la traducción al inglés por Arthur Gilchrist Brodeur de 1916.

Y entonces Gangleri dijo: "Cual es el camino al cielo desde a la tierra?"

Y entonces Hárr contestó, riéndose: "Vaya, no es preguntado de manera sabia; acaso no se le ha dicho, que los dioses han hecho un puente desde la tierra, al cielo, llamado Bifröst? Seguramente lo habrá visto; podría ser que lo conozca como arcoiris. Es de tres colores, y muy fuerte, hecho con ingenio y más artes mágicas que otros trabajos de manufactura. Pero fuerte como es, debe aún ser roto, cuando los hijos de Múspell avancen cargando y lo atraviesen, y naden con sus caballos sobre los grandes ríos; así será."

Y entonces Gangleri dijo: "A mi parecer los dioses no construyeron el puente honestamente, sabiendo que puede ser roto, y siendo capaces de hacerlo como quisieran."

Y entonces Hárr respondió: "Los dioses no merecen ser recriminados por este trabajo habilidoso, un buen puente es Bifröst, pero nada en este mundo es de naturaleza tal de ser confiado cuando los hijos de Múspell cargan."

Then said Gangleri: "What is the way to heaven from earth?"

Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has it not been told thee, that the gods made a bridge from earth, to heaven, called Bifröst? Thou must have seen it; it may be that ye call it rainbow.' It is of three colors, and very strong, and made with cunning and with more magic art than other works of craftsmanship. But strong as it is, yet must it be broken, when the sons of Múspell shall go forth harrying and ride it, and swim their horses over great rivers; thus they shall proceed."

Then said Gangleri: "To my thinking the gods did not build the bridge honestly, seeing that it could be broken, and they able to make it as they would."

Then Hárr replied: "The gods are not deserving of reproof because of this work of skill: a good bridge is Bifröst, but nothing in this world is of such nature that it may be relied on when the sons of Múspell go a-harrying."

Esta historia es notable, ya que en suma es el reconocimiento que desde el siglo XIII existe la idea de que no existe un sistema de seguridad perfecto.

Usando los terminos de Sturluson, creemos haber imbuído al sistema de seguridad de la OLPC con ingenio y más artes mágicas que otros trabajos de manufactura—pero ni por un segundo creemos que hemos diseñado algo que no pueda ser roto cuando talentosos, determinados e ingeniosos atacantes carguen. De hecho, esa no era la meta. La meta era elevar significativamente la barrera del actual y profundamente insatisfactorio estado de la seguridad del escritorio (desktop). Creemos que Bitfrost cumple con ello, aunque solamente cuando las laptops esten en el campo seremos capaces de determinar con algún grado de certitud si lo hemos logrado.

Si el tema les interesa, por favor unanse a la lista de seguridad de la OLPC, comparta sus ideas, y unase al debate.

FIN

This story is quite remarkable, as it amounts to a 13th century recognition of the idea that there's no such thing as a perfect security system.

To borrow Sturluson's terms, we believe we've imbued the OLPC security system with cunning and more magic art than other similar works of craftmanship -- but not for a second do we believe we've designed something that cannot be broken when talented, determined and resourceful attackers go forth harrying. Indeed, this was not the goal. The goal was to significantly raise the bar from the current, deeply unsatisfactory, state of desktop security. We believe Bitfrost accomplishes this, though only once the laptops are deployed in the field will we be able to tell with some degree of certainty whether we have succeeded.

If the subject matter interests you, please join the OLPC security mailing list, share your thoughts, and join the discussion.

END

Créditos

Autor

Ivan Krstić

ivan EN laptop.org

One Laptop Per Child

http://laptop.org

   5 :Author
   6     Ivan Krstić
   7     ivan AT laptop.org
   8     One Laptop Per Child
   9     http://laptop.org

Agradecimientos

Simson Garfinkel, un consultor de seguridad para la OLPC, contribuyó a este documento. Este documento también se basa sobre un área en crecimiento conocido como "HCI-SEC", el campo de recientes avances de la Interacción Humano Computadora con el importante objetivo de la seguridad informática. Para más informacion sobre HCI-SEC referirse a "Security and Usability", por Lorrie Cranor y Simson Garfinkel (O'Reilly, 2005), y en la tésis PhD de Garfinkel, "Design Principles and Patterns for Computer Systems that are Simultaneously Secure and Usable" (MIT, 2005).

Reconocemos también al panel de reviewers que prefieren permanecer anónimos, y que proveyeron comentarios y observaciones valiosos sobre las versiones previas de este documento.

  11 :Acknowledgments
  12     Simson Garfinkel, a security consultant for OLPC, contributed to this
  13     document.  This document also builds upon a growing body known as
  14     "HCI-SEC," the application of recent advances in the field of Human
  15     Computer Interaction to the important goals of computer security. More
  16     information about HCI-SEC can be found in the book "Security and
  17     Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in
  18     Garfinkel's PhD thesis, "Design Principles and Patterns for Computer
  19     Systems that are Simultaneously Secure and Usable" (MIT, 2005).
  20 
  21     We acknowledge also a panel of reviewers that prefer to stay anonymous, who
  22     provided insightful comments and feedback on previous drafts of this
  23     document.

Metadata

Revisión: Borrador-19 - distribución 1

Fecha y hora: Wed Feb 7 00:50:57 UTC 2007

URL comentarios: http://mailman.laptop.org/mailman/listinfo/security

Versión de referencia para este documento: http://wiki.laptop.org/go/Bitfrost

Todo comentario sobre este documento será bienvenido, preferentemente en la lista pública de la OLPC sobre seguridad, a la cual se pueden suscribir por medio del URL ya mencionado. Si prefiere mantener sus comentarios privados, puede enviar un email al autor de este documento a su dirección arriba mencionada.

Esta versión de la especificación NO es la definitiva. Sus contenidos reflejan exactamente el pensamiento de la OLPC en materia de seguridad al momento de ser redactado, pero ciertos aspectos del modelo de seguridad pueden cambiar antes de la producción. Este documento será actualizado para reflejar dichos cambios. La versión más reciente se puede encontrar en el URL de referencia.

  25 :Metadata
  26     Revision: Draft-19 - release 1
  27     Timestamp: Wed Feb  7 00:50:57 UTC 2007
  28     Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
  29     Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost
  30 
  31     We welcome feedback on this document, preferably to the public OLPC
  32     security mailing list, for which you can sign up at the feedback URL given
  33     above. If you strongly prefer to keep your comments private, you may mail
  34     the author of the document at the provided e-mail address.
  35 
  36     This is NOT the final version of the specification. The contents of this
  37     document accurately reflect OLPC's thinking about security at the time of
  38     writing, but certain aspects of the security model may change before
  39     production. This document will be updated to reflect any such changes. The
  40     latest version of this document may be found at the authoritative version
  41     URL.